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: Richard Frith-Macdonald
Subject: Re: Associating bundle directories with app
Date: Thu, 20 Jan 2011 19:28:12 +0000

On 20 Jan 2011, at 18:15, Sebastian Reitenbach wrote:
>> 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.

Yes ... in practice that's basically whenever a gui app starts up ... and since 
these associations are practically only ever  used by gui apps (and in 
particular extension:app associations are usually only by the workspace app), 
that means that make_services is run automatically before any app needs the 
info.

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

Sure, that could be good in principle, but I can't see much benefit in practice 
for now since we have to generate the user domain info and merge in the 
local/system domain info anyway.
If we had a *lot* of apps in the local/system domains then caching information 
about them separately and merging it with the user domain stuff would improve 
performance, but for now I can't see the additional coding being worth the 
effort.




reply via email to

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