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, [email protected], sponsored by Qt Software @ Nokia to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
