Unifying file managers' right-click menu interfaces

[David Faure]

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?

> 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?

> 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?

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