Re: Tool with Resources

[Nicola Pero]

> >   then its associated bundle will automatically be installed into
> > 
> > xxx/Tools/Resources/Frederic/
> > 
> > gnustep-base can move backwards from the tool executable location to the
> > tool resource bundle dir and find it - it does so when you ask for
> > [NSBundle +mainBundle].
> > 
> > So basically you can access your bundle using gnustep-base's [NSBundle
> > +mainBundle] method.  For an application, it returns the applciation main
> > bundle; for a tool, by extension it returns the 'tool main bundle', which
> > is the bundle we've been talking about.  NB: the gnustep-base code should
> > find the bundle both before you install the tool (it will then find the
> > non-installed ./Resources/Frederic dir; of course it will find it assuming
> > you've not moved the tool around :-), and after you install the tool (it
> > will then find the installed xxx/Tools/Resources/Frederic dir).
> > 
> 
> That is great to hear.
> I was thinking about something like .tool bundles similar to .app bundles. 
> This will make the tool installation much easier, one we will be able to
> widely use binary distributions. Just like .app an user will copy the
> .tool bundle somewhere, say .../Tools. To be able to find the tool,
> without having to add to PATH the user runs something like update_tools
> after installing/removing the tool. Tool update_tools will create
> symlinks in that /Tools directory containing .tool bundle.
> 
> for example you install mytool.tool into Local/Tools where you have:
>   Local/Tools/mytool.tool/ARCH_DIRS/mytool
> and the update_tools will create
>   Local/Tools/ARCH_DIRS/mytool -> ../../mytool.tool/ARCH_DIRS/mytool
> 
> After removing the .tool bundle all invalid links will be removed by 
> update_tools.
> 
> Users do not like installers (and I do not speak about scary thing: building 
> from sources) and this seems to be quite easy solution.
> 
> What do you think?

Yes - it's interesting - the main reason I'd not implement it is that I
think we want to make a lot of a difference between tools and gui
applications.

Gui applications are targeted at a 'real users' 'unix haters' audience,
where you have a pretty gui file browser, you download your .app file from
the net, put it anywhere in your home dir, and run the app by just
double-clicking on it.  No command line ever.  It's best to keep it simple
for the common real user/unix hater.

Tools are targeted at a 'developers', 'unix users' audience, where your
main interface is via the command line.  Tools are also used/invoked by
other software.  It's something more low level and then, I'd feel the best
way to do it is to keep it simple and easy for the common developer/unix
user.  The common unix user knows about shells and PATHs and tools, and to
keep things simple for him, I'd say the best we can do is keep tools to
work like standard unix tools.  We just put the executable in the path;
the tool when running will search for its resources in a system dir keyed
under its name.  That's what all other unix tools do.  It would be
annoying for a common developer/unix user to have to learn about an
additional update_tools tool to be used just in order to use gnustep tools
... Symlinks are also a dangerous portability trap ... the less we have
them, the better.  I also see a common unix user much more in love with
rpm or apt-get or whatever his preferite package manager is :-) so trivial
packaging and distributing is less of an issue with such an audience.

And still ... thanks for the suggestion!