----- "Ted Gould" <[email protected]> a écrit : > I'm a bit confused about this, it seems that you're proposing a few > ways of doing it in that document. Shouldn't we choose one? > I personally like storing everything in a single .desktop file.
This is probably because (maybe wrongly) I mix in the draft some rationales, try to describe existing and possible solutions. Actually I do propose the alternate way of creating a hierarchy of actions. About storing everything in a single .desktop, I understand that this make easyer to package and distribute. Is there any other advantage ? Contrarily, I see some drawbacks: - this create a new notion, a group of action - in a UI management, when creating a new action, the user is required to decide if this action should be saved in its own .desktop file or in an already existing one. - actions written in a same .desktop are not individually adressable (but specifying a compound id which would be <desktop_file_id>-<action_id>) - we have to specify in the [Desktop Entry], not only the ordered list of actions, but also if they should be gathered in a menu or not - last, if actions have profiles (see below), the .desktop file will be much more complex > I'm also a little confused by the name "Profile" -- why was it > changed from "Action" in the previous versions of the desktop spec. > That made more sense to me. Actions do not have been renamed to Profiles. Instead, I have distinguished in the action: - an invariant: label, icon, tooltip - some conditions, the command and its parameters, which I've called 'profile' Then I say that one to several profiles may be defined for an action, but, at runtime, one the first profile whose conditions are met will be selected as candidate for the context menu. Most of actions/services menus I've seen has only one profile. Say, for example, an action 'Open terminal here', with following three profiles: - if selection is a directory, open a terminal in that directory - if selection is a file, open a terminal in base directory of the file - if selection is the desktop, open a terminal in ~/Desktop We could also have three actions 'Open terminal here', each with ad-hoc conditions so that only one action may be candidate at one time. But in the management UI, these three actions with the same label would be a bit disturbing. We could also have three actions, with slightly different labels, say 'open terminal in this directory', 'open terminal if parent directory' and 'open terminal on desktop', but this appears as just a work-around for this issue. At last, it appears that we have one conceptual action, and several ways of doing it depending of runtime conditions. > > --Ted Regards Pierre _______________________________________________ Thunar-dev mailing list [email protected] http://foo-projects.org/mailman/listinfo/thunar-dev
