On Thursday 19 April 2012 09:02:56 Vincent Untz wrote:
> Hi,
> 
> Le mercredi 18 avril 2012, à 22:50 +0100, Jerome Leclanche a écrit :
> > On Thu, Apr 5, 2012 at 7:42 AM, Jerome Leclanche <[email protected]> 
wrote:
> > > On Thu, Apr 5, 2012 at 7:33 AM, David Faure <[email protected]> wrote:
> > >> On Tuesday 03 April 2012 18:40:04 Jerome Leclanche wrote:
> > >> > Writing the intents spec, I found out that according to the desktop
> > >> 
> > >> entry
> > >> 
> > >> > spec:
> > >> http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-
> > >> lates> >> 
> > >> > t.html Desktop Actions do not support a MimeType key. Is there a
> > >> > solid
> > >> > reason why?
> > >> 
> > >> I can't think of another reason than "the need for it never popped up
> > >> before".
> > >> 
> > >> > My use case:
> > >> > I have an image viewer and editor which supports viewing jpg and png,
> > >> > however it can only *edit* png files. The "Edit" action would then
> > >> > only
> > >> > support image/png while the main entry would support image/jpeg and
> > >> > image/png.
> > >> > 
> > >> > One of the issues raised by supporting it is associating a mime type
> > >> > to
> > >> 
> > >> an
> > >> 
> > >> > action (rather than a desktop file altogether).
> > >> > I propose the following syntax for mimeapps.list
> > >> > 
> > >> > image/jpeg=myapp.desktop;
> > >> > image/png=myapp.desktop;myapp.desktop[Edit];
> > >> 
> > >> OK, but this also needs a fix in the desktop entry spec, right?
> > >> For the case where the developer already knows in the first place that
> > >> the app
> > >> can only edit PNGs.
> > > 
> > > Not sure I understand what you mean. But yes, the desktop entry spec
> > > would
> > > need an update... The MimeType key needs to be added to Table 3. Action
> > > Specific Keys. I also propose updating the example desktop entry file to
> > > display that behaviour.
> > > The syntax itself for mimeapps.list would not require an update as it's
> > > just a "list of strings", although I don't think mimeapps.list actually
> > > has
> > > a spec anywhere.
> > > 
> > >> --
> > >> David Faure, [email protected], http://www.davidfaure.fr
> > >> Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
> > > 
> > > J. Leclanche
> > 
> > Is there any more feedback on this? Where/how can I submit changes/get
> > them
> > accepted?
> 
> The following would be nice:
> 
>  + a patch for the spec (living in xdg/xdg-specs in git.freedesktop.org)
>  + a patch for desktop-file-utils (to update update-desktop-database)
>  + possibly patches for Qt (I assume) and glib to handle the changes in
>    the format of mimeinfo.cache/mimeapps.list

There's no code in Qt yet, at this point it would be
kdelibs/kded/kmimeassociations.cpp
in git://anongit.kde.org/kdelibs

> It's a bit unclear to me how the old stacks will react to something
> like:
>   image/png=myapp.desktop[Edit];
> Will they just fail gracefully?

Yep, the KDE implementation will just output a warning saying
KMimeAssociations::parseAddedAssociations: ".../mimeapps.list" specifies 
unknown service "myapp.desktop[Edit]" in "Added Associations".

But that's for mimeapps.list. I'm not sure what the suggested change for 
application .desktop files actually is. Ah, we're not talking about changing 
the way apps are associated with mimetypes, only about "desktop actions", i.e. 
typically contextual menu stuff? I wonder how the GUI is supposed to look like, 
to distinguish Open from Edit?

I'm confused over all, because mimeapps.list is about application desktop 
files, not just about desktop files that define desktop actions. So, what 
should 
happen when writing image/png=myapp.desktop[Edit];
and myapp.desktop simply says Exec=gimp ? Nothing new, right?

-- 
David Faure, [email protected], http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5

_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg

Reply via email to