Re: Associating bundle directories with app

[Ivan Vučica]

2011/1/20 Ivan Vučica <ivucica@gmail.com>

On Thu, Jan 20, 2011 at 16:02, Richard Frith-Macdonald <richard@tiptree.demon.co.uk> wrote:

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

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

So, upon instantiation of NSWorkspace, the registration is automatically done, already? 

--
Regards,

Ivan Vučica

The thread is moving in various directions so I'll simply go back to the original purpose of my posting :-)

I just took a look at NSWorkspace's source, and indeed, it is loading some relevant associations and reading some service-related files. I do not see that it is, however, reading current app's plist, and setting any associations in some global cache. It's not running make_services or anything during +initialize nor during -init.  This is done in -findApplications.

Zcode specified that it wants to be associated with .xcodeproj bundles. Upon launch, it should get associated. I don't think there is a need for smart filesystem monitoring.

I've checked it out right now, it looks like Finder is a bit dumb. While OS X does seem to monitor the file system, Finder does not track the changes in filesystem associations. 

1. Building Zcode under Cocoa, .xcodeprojs are still openable with Xcode only.

2. Relaunching Finder (option+click on dock icon, and choosing relaunch), Zcode appears in "open with" menu.

3. Deleting Zcode.app, it still appears in the menu. If it's in Trash, I get info that I cannot open Zcode.app since it's in Trash. If I empty trash, I get "error -35".

4. Relaunching Finder once more, Zcode is gone from list of programs that can open .xcodeproj.

Still, I really don't think there is much need to actively monitor the filesystem. Simply registering in NSWorkspace's +initialize or -init, or in NSApplication's +initialize or -init (which does not seem to happen at the moment, at my first glance in in the source code last updated a few days ago) would greatly improve the user experience when apps are distributed as bundles.

Now, I could perhaps throw together a patch to do this. GWorkspace.app or NSFileManager should probably be updated as well to clean the list of associations after .app deletion. Upon first attempt to list apps that support opening that file format, each listed app could be verified and, in case it doesn't exist anymore (or is updated), the app could then be deleted.

Filesystem monitoring, while neat, would require a background service -- and this might be a good thing to avoid since GNUstep is not a desktop environment and shouldn't count on any services to exist, right? :-)

--
Regards,

Ivan Vučica