GNOME Bugzilla – Bug 156506
[PATCH] Add Open With menu
Last modified: 2006-02-08 23:10:11 UTC
Jakub Steiner asked for an open with menu on the mailing list It should use gnome-vfs to figure out what can be used to open it features were to include creating a new version before opening
Created attachment 33087 [details] [review] Basic Implementation This is a bare bones implementation. Outstanding: AFAICT gnome-vfs hasn't been ported to c# yet, so I did a bit of it by hand. I can't find a standard way to open a file with an application using gnome-vfs. I'm sure there ought to be one somewhere. I just shell off a process, which is a bit blunt. This only adds to the right click context menu. It should go on edit too There was mention of create a new version before opening. Not sure how this would work in general, although it obviously makes sense for the gimp. The context menu could be cached, gnome vfs will tell us about changes (I think) Could make it easier to pick the default action. I don't think I shutdown gnome-vfs properly (I don't see the destructor being called). It doesn't support multiple selections very sanely.
Created attachment 33088 [details] [review] Fixed patch Sorry, I had got two patch stuck together, trying again...
Just heard from tberman that the offical gnomevfs-sharp stuff is being merged to HEAD at the moment.
Looking through the official stuff, I stumbled on the gnome_vfs_mime_application_launch function, which is exactly what I couldn't find yesterday.
Created attachment 33358 [details] [review] Improved patch This patch uses the gnome-vfs bindings that are now on HEAD in cvs. It also needs a small patch to the bindings to add the Mime.GetAllApplications function. I've sent it to Jeroen for inclusion. The main thing it does is add a bit of memory management. I'd like to find a way to reduce the scope of the menu a bit. The problem is finding a place where it safe to free the mime_applications list. I guess there is an event when the menu is dismissed somewhere.
Ok, some updates. Jeroen's vfs bindings have now be directly imported into f-spot for local use. this clearly sucks but was needed because it was decided we can't depend on anything but gtk-sharp 1.0 for the near future and some of the new export stuff required the vfs bindings. The second issue is that I'm not clear how we should deal with the distinction between open and edit here. With programs we know may modify the image we definitely want to create a new version of the image before we fire off the other program. Any thoughts?
The only things I can think that can be done with the current gnome-vfs infrastructure are: 1. Always version 2. Never version 3. Version if its the original 4. Have two menus, open with and open new version with If we go for always version, then we'll probably need a flatten command, that strips identical versions. The trouble with programs that can edit versus programs that can't is that there is nothing to stop a non editable program also having an open with command. Maybe throw this up for some HIG love?
Well for now people can always just delete the version if they don't way it so we should probably just always create the version and name the menu item something like "Edit With" we might be able to do something smarter about versioning later. It would be nice if we could always count on the program to remove and replace the file it edits rather than writting in place so that we could do something like using a symlink but i don't think we can reply on that.
I'm not sure we can even rely on the filesystem having symlinks. I, for one, have my photos on a FAT filesystem.
Created attachment 36579 [details] [review] Rename menu item to edit with, create new version every time. I still think this is too intrusive, Is it OK to keep references to things allocated in gnome-vfs lying around to be garbage collected? Can we copy (I feel the word marshall should be here somewhere) them so we can just let the GC deal with them when it is good and ready. Am I just worrying about nothing?
Doh, I also just realised that my old patches, just using cvs diff, didn't include any new files.
*** Bug 322609 has been marked as a duplicate of this bug. ***
*** Bug 323074 has been marked as a duplicate of this bug. ***
Fixed in CVS, thanks for the work Loz, the end fix was based on your patch.