Re: File actions (was: Device icon action)
On Tue, 2005-08-09 at 15:11 -0400, Joe Shaw wrote: > Hi, > > I am going to steer this thread in my own direction. :) > > On Tue, 2005-08-09 at 01:53 -0700, Jeff Waugh wrote: > > > Maybe a View Audio Files or View Video Files option in the right click > > > context menu? > > > > Default context menu item == "Play" (or whatever action makes sense), with > > the "Open" item still there, but not default. > > We need a solution for describing actions other than "Open" for many > file types. In Beagle, for files we want to have "Open" and also > "Reveal in file manager" that would cause the file to be selected in a > new Nautilus window. For media files, "Open" and "Enqueue." For IMs, > open the log and also IM the individual. And so on... Right now we're > hard coding a lot of these items, but that's not a tenable solution. > > We could perhaps overload the MIME system for this, but that makes me > feel a little dirty. How do other people feel about the problem? Any > other suggestions? I was talking to Colin about this. While it is geared more towards devices we were thinking instead of overloading the mime system for devices HAL exports capabilities - why not register applications that can handle certain capabilities? This way in the UI of gnome-volume-manager (it really should be renamed to gnome-device-manager now) there is no free form text entry but a nice drop-down of applications that can handle audio burning capabilities for example. We could expand this to "virtual devices" such as your IM example (not saying we use HAL for this BTW). So there would be a contact file that would export an im-contact capability if it contained im contact data or e-mail-contact, etc. Just an idea. -- John (J5) Palmieri <[EMAIL PROTECTED]> ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: File actions (was: Device icon action)
Joe Shaw wrote: > We could perhaps overload the MIME system for this, but that makes me > feel a little dirty. How do other people feel about the problem? Any > other suggestions? As I wrote elsewhere: I am sending you a random ideas, what can be included to new specification. Define a way to define actions. Default actions (Open, Edit, Send) should be part of standard action set, additional actions should be definable via additional files. Actions can have subtype (e. g. Send/Bluetooth, maybe even Send/Bluetooth/MobilePhone). Application should associate actions with application/desktop/command A special action is Convert. Application can associate a matrix of MIME types and its possible conversion. MimeType=class/type;class/anothertype; MimeType/Edit=class/type MimeTypeConvert(class/anothertype)=class/type MimeTypeConvertExec(*/*,class/anothertype)=myconvert %s -t %M %S MimeTypeConvertExec=myconvert -f %m %s -t %M %S File manager could take an advance of such database - while renaming file suffix it can offer conversion to another format or it can create menu items "Edit/Convert to" without much effort from application author. Other problems of current MIME type specification: Translations. "Internationalised descriptions of applications should not be repeated (Gimp should not have to specify translations of "Edit in Gimp" for every MIME type it supports)." This is not so easy in some languages. In Czech (diacritics removed) there is a problem of inflexion and proposal should take care of it. Image editor = Editor obrazku Open with image editor = Otevrit v editoru obrazku Convert with image editor = Konvertovat editorem obrazku Virtual MIME types. Some programs (eog) inherits its MIME types from lower level libraries and its plugins. It means, that eog has no real idea, which MIME types it can open. Proposal: Define virtual MIME type, which is expanded to actual state. eog.desktop MimeType=virtual/gdk-pixbuf-2.0 gdk-pixbuf-2.0 will define this MIME type and its expansion. MIME types added by plugin. Some programs (gimp) MIME type list can be extended by plugins (e. g. rawphoto adds image/x-dcraw MIME type). But GIMP list is fixed. How to fix it? I am not sure, but we should have a way, how plugin can propagate its MIME type to main application without editing its desktop file. P. S.: Is there any way to join http://freedesktop.org/wiki/Standards_2fmime_2dactions_2dspec discussion? -- Best Regards / S pozdravem, Stanislav Brabec software developer - SuSE CR, s. r. o. e-mail: [EMAIL PROTECTED] Drahobejlova 27 tel: +420 296 542 382 190 00 Praha 9fax: +420 296 542 374 Czech Republichttp://www.suse.cz/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: File actions (was: Device icon action)
> ObCurmudgeon: MC handled MIME actions just fine, back in 1999... ... and with /etc/mailcap! - Jeff -- GNOME Summit: October 8th-10th http://live.gnome.org/Boston2005 "You know, the crunchy, folk-singer part of me wants to believe that a performance is a dialogue, but I can't hear a fucking thing you're saying." - Ani DiFranco ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: File actions (was: Device icon action)
On Tue, 2005-08-09 at 15:11 -0400, Joe Shaw wrote: > We need a solution for describing actions other than "Open" for many > file types. In Beagle, for files we want to have "Open" and also > "Reveal in file manager" that would cause the file to be selected in a > new Nautilus window. For media files, "Open" and "Enqueue." For IMs, > open the log and also IM the individual. And so on... Right now we're > hard coding a lot of these items, but that's not a tenable solution. > > We could perhaps overload the MIME system for this, but that makes me > feel a little dirty. How do other people feel about the problem? Any > other suggestions? Ed is right; use the MIME actions for this. You'll still need to special-case gaim log files, if gaim doesn't define a MIME-type for them. You know you can special-case them because you are hardcoding the gaim logs directory anyway :) For media files: users won't know what "enqueue" means. Using "add to play list" or something like that is probably better. ObCurmudgeon: MC handled MIME actions just fine, back in 1999... Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: File actions (was: Device icon action)
> We could perhaps overload the MIME system for this, but that makes me > feel a little dirty. How do other people feel about the problem? Any > other suggestions? Not quite the MIME system, surely the .desktop structure is right for applications to register an interest in handling media? This seems in the right direction: http://freedesktop.org/wiki/Standards_2fmime_2dactions_2dspec Ed ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
File actions (was: Device icon action)
Hi, I am going to steer this thread in my own direction. :) On Tue, 2005-08-09 at 01:53 -0700, Jeff Waugh wrote: > > Maybe a View Audio Files or View Video Files option in the right click > > context menu? > > Default context menu item == "Play" (or whatever action makes sense), with > the "Open" item still there, but not default. We need a solution for describing actions other than "Open" for many file types. In Beagle, for files we want to have "Open" and also "Reveal in file manager" that would cause the file to be selected in a new Nautilus window. For media files, "Open" and "Enqueue." For IMs, open the log and also IM the individual. And so on... Right now we're hard coding a lot of these items, but that's not a tenable solution. We could perhaps overload the MIME system for this, but that makes me feel a little dirty. How do other people feel about the problem? Any other suggestions? Joe ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
