discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Associating bundle directories with app


From: Sebastian Reitenbach
Subject: Re: Associating bundle directories with app
Date: Thu, 20 Jan 2011 10:08:55 +0100
User-agent: KMail/1.13.5 (Linux/2.6.34.7-0.7-xen; KDE/4.4.4; x86_64; ; )

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.

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.

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...

But maybe I miss sth. here...?

Well, people installing from source, would then still need to run 
make_services, but since they are able to install from source, I don't think 
that this would be a great hurdle.

cheers,
Sebastian

> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep



reply via email to

[Prev in Thread] Current Thread [Next in Thread]