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 19:15:51 +0100
User-agent: Thunderbird 2.0.0.22 (X11/20090701)

Richard Frith-Macdonald wrote:
> 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.
>   
as administrator, you usually try to install packages, in a central
place, and actually don't want your users to install software on their
own, however you try to prevent this. Therefore kind of central location
for the cache would not be too bad. Other packages on OpenBSD do the
same, i.e. updating the mime database, or run gtk-update-icon-cache, or
run update-desktop-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).
>   
Yes, for now, its recommended in the README that gets installed with
GNUstep on OpenBSD that make_services should be added to a kind of login
script. And its not really a "burden", but users tend to not read
documentation, and start complaining ;)

I wasn't aware that the NSWorkspace class instantiation does this
automatically at some point in time for me.


> 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.
>
>   
Don't know whether it would make sense to add a parameter to
make_services, to run in a given domain, i.e. USER, LOCAL, SYSTEM, and
then having for each domain a cache. When NSWorkspace initializes
itself, it looks up the information in each domain, and merges them
together. But maybe its too much hassle for this little problem.


cheers,
Sebastian



reply via email to

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