Unifying file managers' right-click menu interfaces

[Eugene Gorodinsky]

As it currently stands nautilus has one way of adding an entry to the
right-click menu and konqueror has another (and I'm not sure about
other file managers). I believe it would be very beneficial for
everyone to have some standard way of accessing the menu (e.g. adding,
modifying or deleting an entry). Thus an application could add itself
to the file manager's context menu without worrying what filemanager
the user is using.
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Sunday 16 August 2009, Eugene Gorodinsky wrote:
> As it currently stands nautilus has one way of adding an entry to the
> right-click menu and konqueror has another (and I'm not sure about
> other file managers). I believe it would be very beneficial for
> everyone to have some standard way of accessing the menu (e.g. adding,
> modifying or deleting an entry). Thus an application could add itself
> to the file manager's context menu without worrying what filemanager
> the user is using.

Are you talking about Open With... or (what is in kde called) Actions / ...?

The first one is almost-standardized already, since it comes from the app-mime
associations (except that from what I heard gnome sorts alphabetically while
kde sorts by user preference).

The second one is indeed not standardized yet. KDE uses the previously-standardized
(and removed from the spec, but should be re-added IMHO) support for actions
defined in .desktop files.
http://techbase.kde.org/Development/Tutorials/Creating_Konqueror_Service_Menus
Note that even though the "format" is a former standard, the location of the files
and necessary ServiceTypes entry is not cross-platform. But I'm ok with
switching that to a different solution (different location and/or way to identify
the relevant desktop files). I think it makes a lot of sense to use the Actions=
"former-spec" though.

How do other environments do it?

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

[PCMan-2]

This one is good enough. I'm also thinking about how to implement this
in PCManFM, the core file manager of LXDE. However, once there are
many services installed, you'll get an over-crowded popup menu.
Besides, you cannot create a submenu to group related tasks by using
this former-spec. In addition, I think we don't only need mime type
globs like image/*, but we also need filename globs.
In addition, an extension enabling checking the content of the folder
and then generate a popup menu will be great.

For example:
When a folder contains many image files, it make sense to have an
entry for an album manager like Picasa or gthumb in the popup menu of
the folder item.
When a folder contains many ogg files, it make sense to have an entry
"Play in XXXX" for music player or something like EasyTag, which
manages music files.
When you have a folder contains .svn, you should have a submenu
contains frequently-used svn commands.
Popup menu, or context menu, should be changed according to current
context. Having different menu items for different mime-types is not
enough. For folders having quite different contents, it make sense to
provide different popup menus to the users.
This are my ideas for future file managers and I want to do it in LXDE.

If this can be standardized, then nautilus scripts and services used
by KDE can be unified.

On Mon, Aug 17, 2009 at 5:54 PM, David Faure<faure@...> wrote:

> On Sunday 16 August 2009, Eugene Gorodinsky wrote:
>> As it currently stands nautilus has one way of adding an entry to the
>> right-click menu and konqueror has another (and I'm not sure about
>> other file managers). I believe it would be very beneficial for
>> everyone to have some standard way of accessing the menu (e.g. adding,
>> modifying or deleting an entry). Thus an application could add itself
>> to the file manager's context menu without worrying what filemanager
>> the user is using.
>
> Are you talking about Open With... or (what is in kde called) Actions / ...?
>
> The first one is almost-standardized already, since it comes from the app-mime
> associations (except that from what I heard gnome sorts alphabetically while
> kde sorts by user preference).
>
> The second one is indeed not standardized yet. KDE uses the previously-standardized
> (and removed from the spec, but should be re-added IMHO) support for actions
> defined in .desktop files.
> http://techbase.kde.org/Development/Tutorials/Creating_Konqueror_Service_Menus
> Note that even though the "format" is a former standard, the location of the files
> and necessary ServiceTypes entry is not cross-platform. But I'm ok with
> switching that to a different solution (different location and/or way to identify
> the relevant desktop files). I think it makes a lot of sense to use the Actions=
> "former-spec" though.
>
> How do other environments do it?
>
> --
> David Faure, faure@..., sponsored by Qt Software @ Nokia to work on KDE,
> Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
> _______________________________________________
> xdg mailing list
> xdg@...
> http://lists.freedesktop.org/mailman/listinfo/xdg
>

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[PCMan-2]

On Mon, Aug 17, 2009 at 10:15 PM, PCMan<pcman.tw@...> wrote:
> This one is good enough. I'm also thinking about how to implement this
> in PCManFM, the core file manager of LXDE. However, once there are
> many services installed, you'll get an over-crowded popup menu.
> Besides, you cannot create a submenu to group related tasks by using
> this former-spec.
Sorry that I didn't see X-KDE-Submenu part of the doc. Now I see it.
So creating submenus are possible. Then I think this spec is good enough.
If those key names can be standardized, such as rename X-KDE-Submenu
to a standard one, I'll happily support the spec and implement this in
LXDE. So this won't be a KDE-only spec any more.
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[PCMan-2]

Of course, there should also be OnlyShowIn and NotShowIn, too.
Otherwise KDE services like changing the wallpaper won't be useful to
other DEs sometimes.

On Mon, Aug 17, 2009 at 10:25 PM, PCMan<pcman.tw@...> wrote:

> On Mon, Aug 17, 2009 at 10:15 PM, PCMan<pcman.tw@...> wrote:
>> This one is good enough. I'm also thinking about how to implement this
>> in PCManFM, the core file manager of LXDE. However, once there are
>> many services installed, you'll get an over-crowded popup menu.
>> Besides, you cannot create a submenu to group related tasks by using
>> this former-spec.
> Sorry that I didn't see X-KDE-Submenu part of the doc. Now I see it.
> So creating submenus are possible. Then I think this spec is good enough.
> If those key names can be standardized, such as rename X-KDE-Submenu
> to a standard one, I'll happily support the spec and implement this in
> LXDE. So this won't be a KDE-only spec any more.
>

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[PCMan-2]

Sorry, I have another idea:
[Desktop Action] groups should also allow the X-KDE-Submenu key, so
creating submenu for submenus is possible. Although there is no real
use case now, this might be useful in the future once someone needs
it.

Also, there might be a new key named Dynamic.
The key contains a command line which can generate menu content dynamically.
After calling the command, its stdout should be inserted to current
desktop entry file.
So we can support dynamic menu items generated with scripts.
This partially solves my preceding question, how to generate menu
according to different context for files of the same mime-type.

Example of its usage:
1.you can use a shell script to examine the content of the folder, and
then generate the menu according to its content.
2.this can be used to develop integration with version control systems.
3.and more....
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Jannis Pohlmann-3]

On Mon, 17 Aug 2009 11:54:03 +0200
David Faure <faure@...> wrote:

> On Sunday 16 August 2009, Eugene Gorodinsky wrote:
> > As it currently stands nautilus has one way of adding an entry to
> > the right-click menu and konqueror has another (and I'm not sure
> > about other file managers). I believe it would be very beneficial
> > for everyone to have some standard way of accessing the menu (e.g.
> > adding, modifying or deleting an entry). Thus an application could
> > add itself to the file manager's context menu without worrying what
> > filemanager the user is using.
>
> Are you talking about Open With... or (what is in kde called)
> Actions / ...?
>
> The first one is almost-standardized already, since it comes from the
> app-mime associations (except that from what I heard gnome sorts
> alphabetically while kde sorts by user preference).
>
> The second one is indeed not standardized yet. KDE uses the
> previously-standardized (and removed from the spec, but should be
> re-added IMHO) support for actions defined in .desktop files.
> http://techbase.kde.org/Development/Tutorials/Creating_Konqueror_Service_Menus
> Note that even though the "format" is a former standard, the location
> of the files and necessary ServiceTypes entry is not cross-platform.
> But I'm ok with switching that to a different solution (different
> location and/or way to identify the relevant desktop files). I think
> it makes a lot of sense to use the Actions= "former-spec" though.
>
> How do other environments do it?

Personally, I'd be very happy to have Desktop Actions back. Really.

In addition to that, Thunar has its own extension for custom actions. It
uses the XML format defined here:

  http://git.xfce.org/xfce/thunar/tree/plugins/thunar-uca/uca.xml.in

Actions can be defined using filename patterns and/or most popular MIME
types (e.g. text files or image files). Actions usually have a name,
description, icon and a shell command with variable support
(http://git.xfce.org/xfce/thunar/tree/plugins/thunar-uca/README).

  - Jannis


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[PCMan-2]

I read that part in source code of thunar. The design is clever and
Benny is a genius. I, however, prefer the use of desktop entry files
instead of xml ones since it's much simple and doesn't require
complicated implementations or merging rules. Besides, it's easier to
maintain since the readability of xml files sometimes decreases when
its size is growing.

A unified way defined with desktop entry spec will be fairly good
since the format can be easily understand, maintained, and it's
already widely used.

On Mon, Aug 17, 2009 at 10:43 PM, Jannis Pohlmann<jannis@...> wrote:

> On Mon, 17 Aug 2009 11:54:03 +0200
> David Faure <faure@...> wrote:
>
>> On Sunday 16 August 2009, Eugene Gorodinsky wrote:
>> > As it currently stands nautilus has one way of adding an entry to
>> > the right-click menu and konqueror has another (and I'm not sure
>> > about other file managers). I believe it would be very beneficial
>> > for everyone to have some standard way of accessing the menu (e.g.
>> > adding, modifying or deleting an entry). Thus an application could
>> > add itself to the file manager's context menu without worrying what
>> > filemanager the user is using.
>>
>> Are you talking about Open With... or (what is in kde called)
>> Actions / ...?
>>
>> The first one is almost-standardized already, since it comes from the
>> app-mime associations (except that from what I heard gnome sorts
>> alphabetically while kde sorts by user preference).
>>
>> The second one is indeed not standardized yet. KDE uses the
>> previously-standardized (and removed from the spec, but should be
>> re-added IMHO) support for actions defined in .desktop files.
>> http://techbase.kde.org/Development/Tutorials/Creating_Konqueror_Service_Menus
>> Note that even though the "format" is a former standard, the location
>> of the files and necessary ServiceTypes entry is not cross-platform.
>> But I'm ok with switching that to a different solution (different
>> location and/or way to identify the relevant desktop files). I think
>> it makes a lot of sense to use the Actions= "former-spec" though.
>>
>> How do other environments do it?
>
> Personally, I'd be very happy to have Desktop Actions back. Really.
>
> In addition to that, Thunar has its own extension for custom actions. It
> uses the XML format defined here:
>
>  http://git.xfce.org/xfce/thunar/tree/plugins/thunar-uca/uca.xml.in
>
> Actions can be defined using filename patterns and/or most popular MIME
> types (e.g. text files or image files). Actions usually have a name,
> description, icon and a shell command with variable support
> (http://git.xfce.org/xfce/thunar/tree/plugins/thunar-uca/README).
>
>  - Jannis
>
> _______________________________________________
> xdg mailing list
> xdg@...
> http://lists.freedesktop.org/mailman/listinfo/xdg
>
>

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Michael Pyne]

On Monday 17 August 2009 10:34:34 PCMan wrote:

> Sorry, I have another idea:
> [Desktop Action] groups should also allow the X-KDE-Submenu key, so
> creating submenu for submenus is possible. Although there is no real
> use case now, this might be useful in the future once someone needs
> it.
>
> Also, there might be a new key named Dynamic.
> The key contains a command line which can generate menu content
>  dynamically. After calling the command, its stdout should be inserted to
>  current desktop entry file.
> So we can support dynamic menu items generated with scripts.
> This partially solves my preceding question, how to generate menu
> according to different context for files of the same mime-type.
>
> Example of its usage:
> 1.you can use a shell script to examine the content of the folder, and
> then generate the menu according to its content.
> 2.this can be used to develop integration with version control systems.
> 3.and more....

If we were to support something like this I think it would be best if we
required the .desktop file to be marked as executable as well, to avoid
opening a silly security hole that GNOME and KDE both recently fixed.

Regards,
 - Michael Pyne


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Eugene Gorodinsky]

It's not just the Open With menu entries/submenu. It's much more. Here
are a few examples: there are scripts for both konqueror/dolphin (?)
and nautilus that allow the user to open a terminal window in a
specific folder by rightclicking and choosing a specific menu item.
There is also a send-to menu, which could be used by programs as well.
Moreover these things can be either system-wide or user-specific (not
every user needs to have an open-terminal menu entry)


[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

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). 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. 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. It seems to me
that the only way to not run into this sort of problems is by using a
common set of API.


2009/8/17 David Faure <faure@...>:

> On Sunday 16 August 2009, Eugene Gorodinsky wrote:
>> As it currently stands nautilus has one way of adding an entry to the
>> right-click menu and konqueror has another (and I'm not sure about
>> other file managers). I believe it would be very beneficial for
>> everyone to have some standard way of accessing the menu (e.g. adding,
>> modifying or deleting an entry). Thus an application could add itself
>> to the file manager's context menu without worrying what filemanager
>> the user is using.
>
> Are you talking about Open With... or (what is in kde called) Actions / ...?
>
> The first one is almost-standardized already, since it comes from the app-mime
> associations (except that from what I heard gnome sorts alphabetically while
> kde sorts by user preference).
>
> The second one is indeed not standardized yet. KDE uses the previously-standardized
> (and removed from the spec, but should be re-added IMHO) support for actions
> defined in .desktop files.
> http://techbase.kde.org/Development/Tutorials/Creating_Konqueror_Service_Menus
> Note that even though the "format" is a former standard, the location of the files
> and necessary ServiceTypes entry is not cross-platform. But I'm ok with
> switching that to a different solution (different location and/or way to identify
> the relevant desktop files). I think it makes a lot of sense to use the Actions=
> "former-spec" though.
>
> How do other environments do it?
>
> --
> David Faure, faure@..., sponsored by Qt Software @ Nokia to work on KDE,
> Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
>

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Eugene Gorodinsky]

2009/8/18 David Faure <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?
>

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

[Eugene Gorodinsky]

By the way...

2009/8/18 David Faure <faure@...>:

> 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.
Actually I would prefer to have some standard API for adding things to
the main menu too. For the reasons I specified in the previous message
and now for this reason too :)

> 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=...
I think this is actually quite a good field for these files.

>
> 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?
We can ask the user if we have a simple program that takes care of
creating menu entries. Such a program could be used to open the menu
entry installation files for example. Also if we have an API we're
working with, we can let the administrator control wether or not the
user can add anything to the popup menu or control what items the user
can change and which she cannot change.

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