Re: Proposal: an addition to glib for getting the absolute path of the current binary.

* Sven Neumann <sven gimp org> [2004-04-13 17:45:35 +0200]:

> We are talking about a single function here. I work for a company that
> uses glib/gtk+ on embedded devices and I am thus interested to keep
> useless stuff out of these libraries. But I don't see why this
> function should not go into glib (provided it turns out that there is
> a reasonable solution).

For the same reason, I'd also refuse other similar functions.

Who'd really benefit from these function ? 

Normally just some gnome'ish applications or gimp. These packages
are either already big or have huge dependencies. Why should another
lib, which then would also really solves the problem - which is 
config/data-and not binary location!

Since the fundamental question is not, where the binary is, but instead
where to get the config and data files, much more code is involved that
a g_get_binary_location() function. By the current draft, that will not
be provided by some common API, just the only little snipped which is 
not platform-neutral. So every application will have implement it by 
its own. Much redundant work and code for one simple job.
Someday their will come voices, which want to get all this into glib,
and so it will grow again.

The relocation is not the only problem people ask glib to solve.  
Its just a very small job, one of thousands. And if we do not set
clear and strict borders NOW, the glib will grow and grow and soon
degenerate to a codesnipped collection like NSPWL or becomes a
cancer monster like Qt.

 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:
  fax:       +49 36207 519932         email:     contact metux de
  cellphone: +49 174 7066481
   -- DSL-Zugang ab 0 Euro. -- statische IP -- UUCP -- Hosting --

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]