Re: Associating bundle directories with app

[Richard Frith-Macdonald]

On 20 Jan 2011, at 09:08, Sebastian Reitenbach wrote:

> On Thursday, January 20, 2011 09:27:34 am Richard Frith-Macdonald wrote:
>> On 20 Jan 2011, at 00:45, Gregory Casamento wrote:
>>> You're correct, it's not done like that today.
>>> 
>>> On NEXTSTEP and OPENSTEP systems there was a process called
>>> make_services... This is why GNUstep has this executable.
>> 
>> Yes ... run when you log in, so any updates are done automatically when you
>> log in. The NSWorkspace class also runs make_services the first time it is
>> used ... but an app which doesn't use it won't automatically update
>> things.
>> 
>>> Your suggestion, though, make sense.  The make_services program should be
>>> run periodically so that registration of application associations is
>>> automatic.
>> 
>> I would think it's highly likely that Apple, when they added support for
>> monitoring the filesystem on their OS (ie for the OS to notify
>> applications which have registered an interest in filesystem updates),
>> modified the workspace application to update associations at the point
>> when an application is added to, or modified in, any of the standard
>> directories.
>> 
>> This would be the ideal way to do things (much, much more efficient than
>> scanning all the directories periodically), but we don't have any way to
>> do that yet as we don't have a cross-platform api for gettting filesystem
>> update notifications :-(
>> 
>> Perhaps someone could write something to use inotify (linux), kqueue (bsd),
>> change notifications (windows NTFS) to perform real-time updates, and run
>> make_services occasionally to catch cases that the filesystem
>> notifications miss? 
> With the make_services available right_now, it has to be run as the user, 
> since the cache used is stored in the users GNUstep directory in the 
> .GNUstepServices file.

Yes.  It has to be done on a per-user basis, since the locations that 
applications/services live in vary from user to user.

> Maybe it would make sense to have a global services cache, in some shared 
> accessible directory. So for me as a packager, I could run make_services as a 
> post (un)install script, when installing a package. So it would update the 
> services database everytime a gnustep application is (un)installed.

If (and only if) you control the system and no users are going to have private 
installations of GNUstep, it would make sense to have a common shared database.
 
> Since make_services always accounts all available applications, for me it 
> would make sense to remove the burden to remember to run make_services, from 
> each user of the system, but move it to the admin/packager...

Well, make_services is supposed to be run by the user's login script (ie the 
installation HOWTO documentation, last time I looked, said that you should do 
that) ... but if you are making a system-wide package you could run it in 
/etc/profile or equivalent.  However, it's really not the case that the user 
has any 'burden' to do it ... applications run it automatically (as soon as the 
NSWorkspace class is instantiated in the app).
However, I think it would be good if gnustep-make also ran it automatically 
when doing a make-install (perhaps it already does ... I haven't checked).

> But maybe I miss sth. here...?

I think the issue is that, if you copy an app into your Apps folder, the 
information about that app doesn't become available immediately ... it has to 
wait for some app to start up and (automatically) run make_services.