Re: Proposal: an addition to glib for getting the absolute path of the current binary.
- From: Tor Lillqvist <tml iki fi>
- To: weigelt metux de
- Cc: gtk-devel-list gnome org
- Subject: Re: Proposal: an addition to glib for getting the absolute path of the current binary.
- Date: Tue, 13 Apr 2004 05:52:33 +0000
Enrico Weigelt writes:
> > > What exactly is the problem ?
> > Typically loading data files.
> Where could the binary location help here ?
He is talking about data files belonging to the application, not the
user's random data files. Typically (unless you specify otherwise when
running the configure script) the executable's location is
$prefix/bin, and its data files are somewhere in $prefix/share, or
$prefix/lib in case of platform-specific data like loadable modules.
> perhaps some kind of global config file.
Right, and how do you know the location of this global (application-
or library-specific) config file? In GTK, Pango and GIMP on Win32, its
location is determined from the location of the binary, as it is
assumed that the stuff is installed so that the binary is in
wherever/bin, and configuration file(s) in wherever/etc/blabla.
> Did I say anything about where the compilation process runs ?!
> The Admin just says what packages he wants and which feature should
> be enabled in them.
What admin?
> Fetching the data location from the binary location is in general a very
> bad idea. Yes, some windows applications tend to install themselves under
> some directy, which the user has to type in before installation, and also
> stores user-data under this directory. But this is principle mis-design
> and should not be supported by toolkits like glib.
Well sure, most of Windows is a misdesign, but it's there, and doesn't
seem to be going away. If your point is that you don't want to know
anything about Windows, or have anything to do with it, just say so...
That's how software is supposed to work on Windows. One can't assume
anything about what drives exist, or the names of folders, on the
end-user's machine. My home machine, for instance, doesn't have a C:
drive. I would consider some software that would insist on installing
itself on the C: drive as badly broken. Non-English Windows
installations don't have any "Program Files" folder. Etc.
--tml
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]