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 <sebas...@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 _______________________________________________ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep