Re: Associating bundle directories with app

[Ivan Vučica]

I'm pretty sure it would be enough to update file associations for the
file when the app is opened (or its plist read by openapp/workspace).
No need to update every app's registered types every time. Also, when
an app is deleted, just remove it from cache.

If I remember correctly, OSX doesn't detect association:
A) until app is opened from finder (maybe copied!)
B) unless app is removed from finder

I would have to play when I get back to OS X, but either way, I don't
see a reason why it couldn't work that way.

Regards,

Ivan Vučica
via phone

On 20. sij. 2011., at 10:10, Sebastian Reitenbach
<sebastia@l00-bugdead-prods.de
 > 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.
>
> 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
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep