----- "PCMan" <[email protected]> a écrit : > After trying to implement this spec, I have some suggestions. > Actions (desktop entries with Type="Action") and menus (desktop > entries with Type="Menu") are actually very similar. > The only difference is that an action takes "Profiles" and a menu > reads a "ItemList". > Why not just merge them? For example: > > [Desktop Entry] > Type=Action or Menu > Name=name > Icon=icon-name > Tooltip=tooltip > Profiles=profile1;profile2; <--- applies to both action or menu. > # ItemList is defined in profiles, not here. > > [X-Action-Profile profile1] > OnlyShowIn=LXDE;GNOME;XFCE; > Exec=command line # This is only valid when Type=Action > ItemList=item1;item2;item3; # This is only valid when Type=Menu > > [X-Action-Profile profile2] > TryExec=try_exec > Exec=command line # This is only valid when Type=Action > ItemList=item1;item2;item3; # This is only valid when Type=Menu > > In this way, both of the actions and menus can be validated against > different conditions and have different profiles. > In your original spec, menus don't have profiles. However, after > trying to implement this spec, I think this is a required feature. > With these modifications, menu and action become the same object. The > only difference is in "Type" and their profiles. > Profiles of "Action" defines Exec and that of "Menu" defines ItemList > instead. > > This greatly simplify the spec while make it more featureful at the > same time. > Please consider this. If a patch for this spec is needed, I can create > one. > Since I don't have the source file of your spec, I cannot do it now. > Hope you can understand what I'm talking about. > > Cheers!
Hi, I understand that you are proposing to extend the 'profile' notion to menus, so that a menu may have several profiles, each profile having its own set of conditions, along with its own set of subitems. I suppose that, as for actions, only the first valid profile, regarding the currently selected files, will be considered, thus determining the current list of subitems. I am not really convinced that this would simplify the spec (after all, we are adding here another level of somewhat as an indirection), nor the implementation itself (but this is rather a point of detail). If I agree that this seems bring up more potential to the spec, the only benefit I see is having different menu order in different conditions. Not sure this will be a great benefit for users (and I thought that dynamically changing order of items in a menu was almost always forbidden by human- machine interface specifications ?) Do you have envisaged another sort of use case ? Contrarily, I am afraid this will not help us for debugging when a user will complain that "my action does not appear in the menu"...;-) From my point of view, trying to make action and menu the same object is just useless. They _are_ different because they have different behaviors. From an implementation point of view, they are similar enough to share a common base class. However I am not willing to spend any effort just to do them more similar... There are pros and cons. For me, these are rather pro and cons ;-) And, finally, I am not sure at all that this pro is worth the added complexity.. Regards Pierre _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
