Hi
I've thought a bit about this one, and perhaps we could go for a more
sophisticated solution, so that when we compile an application, it
generates a shell script that is designed to start the application and
is placed in a "normal" FHS directory e.g. /usr/bin or /usr/local/bin.
For example, if we were compiling an application called GNUMail it would
generated a "GNUMail" shell script, and this would be installed in
/usr/local/bin when I run "make install" (or "gmake install").
It would initialize the GNUstep environment if necessary, and then start
up the application. Not exactly speedy, but perhaps more system
integrated. AFAIK several other multi-platform applications such as
OpenOffice.org and Azereus use this approach due to their internal
filesystem layouts. The debian packagers use a similar approach for
GNUstep apps.
It might even be worth putting the openapp style scripts in a system bin
directory as well, something like "gsopenapp" and "gsdebugapp" to save
messing around with
". /usr/local/GNUstep/System/Library/Makefiles/GNUstep.sh"
for the 90% of cases we don't want to source the GNUstep init scripts.
Not that such a solution is a replacement for this script, but rather a
complement.
On Windows for example, I think that we should create a simple loader
application that sets up the environment to locate the various framework
and tool paths to locate relevant DLL's using registry settings for the
GNUstep location, and then spawn the application. Much like a binary or
script form of openapp. We could then create shortcuts to these and put
them in the start menu. An alternative approach is a full-blown Explorer
shell addin (caution needed as it requires COM and a MS compiler).
Cheers
Chris
P.S. And yes, the symlinks are VERY heretical ;-)
Nicola Pero wrote:
This might sound heretical, but I'd like to make our FHS integration more tight
by
symlinking app binaries from the Tools directory. :-)
In other words, when you install GNUMail.app I'd like to create the symlink
GNUSTEP_LOCAL_TOOLS/GNUMail --> GNUSTEP_LOCAL_APPS/GNUMail.app/{...}/GNUMail
(in the non-flattened case we'd put the symlink in the appropriate subdir).
(eg, in FHS that would mean
/usr/bin/GNUMail --> /usr/lib/GNUstep/Apps/GNUMail.app/{...}/GNUMail)
That way, if you want to start GNUMail.app (for example) you can just type
$> GNUMail
instead of having to go through
$> openapp GNUMail.app
(openapp would still be there and work with all its advanced options for you
power users!). ;-)
I think that makes a difference. Not only would the application start faster,
but if you know nothing about GNUstep, you could probably guess how to start it
without having to read
the instructions (real users don't read the instructions)! ;-)
Otherwise I feel we'll lose a lot of potential users who do 'apt-get install
GNUMail.app', then try to start the app but can't figure out how to do it
because it's installed in the uncommon /usr/lib/GNUstep/Apps/ directory and
it's not even an executable but needs 'openapp' to start ... so after spending
about 30 seconds trying to figure that out the average end user would just give
up and
try something else.
Any objections to me adding this symlink ?
Presumably if symlinks are not available or not good (eg, on Windows) we'd not
create the symlink.
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
