Unifying file managers' right-click menu interfaces

[Eugene Gorodinsky]

2009/8/18 David Faure <faure at kde.org>:
> On Tuesday 18 August 2009, Eugene Gorodinsky wrote:
>> [Desktop Entry]
>> Type=Service
>> ServiceTypes=KonqPopupMenu/Plugin
>> MimeType=image/*;
>> Actions=setAsWallpaper
>>
>> [Desktop Action setAsWallpaper]
>> Name=Use As Wallpaper
>> Icon=background
>> Exec=dcop kdesktop KBackgroundIface setWallpaper %U 6
>
> That's quite an old example, we don't use dcop anymore ;)
>
>> The konqueror service menus format looks nice, however I don't
>> understand the need for a SeviceTypes entry (the desktop file spec
>> clearly states, that desktop files of type other than Link,
>> Application or Directory should be ignored, so that field could have
>> been reused for service menus by adding a type like KonqServiceMenu or
>> something).
>
> ServiceTypes is a generalization of the concept of mimetypes.
> Just like you can query for "give me all apps associated with text/plain",
> you can query for "give me all services associated with KonqPopupMenu/Plugin".
> This is how we can quickly get the list of desktop files that contain the
> definition of a "servicemenu", without having to iterate through all the
> installed files.
> I know that this notion is kde-specific, I'm not pushing for it to be
> standardized (even though I of course wouldn't mind that ;), I just wonder how
> else you can separate the apps desktop files from the servicemenus desktop
> files. Any ideas?
>
What's wrong with using paths and/or filename extensions?

>> One other thing that I find strange is having several
>> actions in one file - this way in order to get rid of the actions the
>> user doesn't need, she has to manually edit these files, rather than
>> just delete the file.
>
> True. Makes things a bit easier for the developer though, who can bundle
> actions into a single file. A GUI for editing servicemenus would solve the
> problem of manual edition, but I agree, that's just more work ;)
>
>> Another problem comes up when two applications
>> want to add the same action for the same mimetype(s). For example two
>> archivers might want to add an "Extract..." action to
>> application/x-bzip mimetype, or two editors might want to add an
>> "Edit" action for text files. If both are added, it will look ugly and
>> annoy the user, since it's hard to tell which entry opens which
>> program, if one replaces the other, that will also annoy the user if
>> the previous application is what she wanted to have.
>
> Well, yes, just like two menu entries called "Web Browser" are annoying
> and confusing ;-) But ok, in the real apps menu we show more details,
> while we don't have room for that in a right-click context menu.
> This is actually the one reason why I'm reluctant to standardize something
> on this issue: we'll get 2 or 3 times more mess in those menus, because
> the actions from other environments will pop up as well :-)
> Of course the solution is to play nice with OnlyShowIn=...
> We're not doing this for the core desktop-environment apps
> (e.g. ark should only appear in kde and gnome's archive program should
> only appear in gnome), we're doing this for ISVs who want a rather
> desktop-independent program to show up everywhere -- right?
>
Exactly :)

>> It seems to me
>> that the only way to not run into this sort of problems is by using a
>> common set of API.
>
> I don't see how that would help. We can't read the user's mind and know
> if he/she wants both to be there (with a different name), or prefers app A or
> app B.
> Only an editor application would allow to do this, not a programmatic API,
> no?
>
Common API is the first step to implementing an editor, or rather
multiple editors. Since KDE and GNOME have different HIG and since
historically everything in the gnome project is developed using
GLib/GTK, and everything in KDE using QT, I imagine there will be at
the very least two editors doing basically the same things, and in
reality probably more. Having a library would achieve two things: less
code will have to be written from scratch and if in the future the
standard is changed it's easier and quicker to just change the code in
the library rather than change the code in all of the programs that
use the standard.

> --
> David Faure, faure at kde.org, sponsored by Qt Software @ Nokia to work on KDE,
> Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>