No subject

1. When the user select multiple files and select one action, he or
she actually want to apply this action to all files he/she selected.
Otherwise he or she will only select one file, right?

2. If you only acts on the fist file, how do you determine which one
is the first file?

3. Maybe you will use the item that currenty has focus or the first
one in the list, but from the view of the user, the item is just like
choosen randomly by N-A and the result is not predictable. This cause
poor user experience and is a design should generally be avoided.

4. Existing N-A can be ported to the new spec by simple converting scripts.

5. If you try to keep complete backward compatibility with Nautilus
and N-A, this might be too nautilus-specific and it won't be as
suitable for others. The possible improvements might be restricted by
backward compatibility. Then wide adoptation by other projects is not
very possible.

6. Because of 5, there must be some backward incompatibility if you
want to make this a better spec suitable for all of other DE/FMs. So a
converting script for old N-A scripts might be needed.

>> 4. ItemsList:
>> =A0 =A0 For me, ItemsList=3D`command to execute`; is more readable than
>> GetItemsList=3Dcommand.
>> =A0 =A0 An even more powerful syntax is:
>> =A0 =A0 ItemsList=3Ditem1.desktop;item2.desktop;`command1
>> arg1`;item4.desktop;`command2 arg2`;
>> =A0 =A0 So part of the list is static, and part of it is generated
>> dynamically.
>
> This would suppose that each part of the ItemsList is to be
> evaluated at run time, at least to see if it is a fixed string or
> a command to be evaluated.
> If we are willing to support the inherent cost of such a behavior
> (which eventually may be a user choice), I'm afraid that at least
> N-A is stucked to GLib and its =A0g_shell_parse_argv() restrictions.
> To not let the user suppose an actual shell is run, I'd prefer a
> special syntax, as [..] or something like that.
>
> Also note that the actual syntax in your example would be:
> ItemsList=3Ditem1;item2;`command1 arg1`;item4;`command2 arg2`;
>
>> 5. ShowIfRegistered, ShowIfTrue, ShowIfRunning:
>> =A0 =A0 What will happen is all of them are defined in the action, but
>> each of them gives opposite result?
>> =A0 =A0 Are those keys mutual-exclusive, or should be combined with 'OR'=
?
>> =A0 =A0 The default state of action should be visible to the user if
>> NoDisplay or Hidden are not true.
>> =A0 =A0 But when ShowIfTrue is defined, it implies that if this returns
>> false, the item should be hidden. I guess when those three keys are
>> defined together, there results should be combined with boolean OR.
>> If
>> the combined result returns false, the item should be hidden. This
>> should be addressed in the spec.
>
> Actually I implicitely supposed that all specified conditions were AND-ed=
.
> If we need OR conditions, then profiles are here for that.

If this is your purpose, the key name I think should be:
OnlyShowIfRegistered, OnlyShowIfTrue, and OnlyShowIfRunning.
For me, OR might be more useful in realworld apps.
Is there any real use case for AND?

>> 6. SelectionCount:
>> =A0 =A0 When will we have a condition that SelectionCount=3D0?
>> =A0 =A0 Aren't those actions applies to selected files only?
>
> Well Nautilus has an extension API which applies when there is no
> selection (get_background_items). So when SelectionCount=3D0, then
> the actions apply on the current folder.
>
>> 7. Schemes:
>> =A0 =A0 We need to initiate another "Desktop Schemes" spec to define som=
e
>> standard schemes.
>> =A0 =A0 Non-standard schemes like computer:///, trash:/// or smb:///
>> should be well-documented in specs.
>
> From my point of view, scheme is only a string I pass to GIO, or
> I compare to the relevant part of an URI. I'm far to being involved
> enough in schemes, protocols and so to be able to initiate such
> a spec...
Not everyone is using gio. At least KDE and GIO should use the same schemes=
.
Otherwise things are hard to be cross-desktop and this will make it a
GIO-only spec.

>> 8. Folders:
>> =A0 =A0 Folders needs to support ! to negate specific folders, too.
>
> Yes
>
>> 9. Parameters:
>> =A0 =A0 Please explain the use case of %w and %W.
>> =A0 =A0 I doubt this is rarely needed.
>
> I agree with you. But this is a request of some users to be able
> to get names without extensions. When making them enjoy is so easy,
> why do I go without it ?
>
>> =A0 =A0 Besides, those parameters should apply to any key in this spec
>> requiring a command line, not only the Exec key. This should be
>> addressed in the spec.
>
> But, they do. In most keys if not all (Name, Tooltip, Icon, etc.).
>
>> 10. Special case:
>> =A0 =A0 When an action desktop file only contains one profile, most of
>> the
>> keys in [Desktop Entrty] and X-Action-Profile profile_id] are
>> duplicated. For example, a simple action used to open a folder in
>> terminal emulator. IMHO, the values in profile should direcly be
>> defined in [Desktop Entry] instead. In this way, the desktop file
>> only
>> requires half of its original size, but can still contain all the
>> required data.
>
> I don't understand what you mean here about duplicated keys ?
> Of what keys do you are talking about ?
>
>> In my opinion, this spec is quite complete, but it's a little bit too
>> complicated to implement.
>> Is there anyway to make it simpler?
>
> Here also, I agree with you. It is much complicated to understand and
> it will also be to implement ;)
> I have seen this spec rather as a long-time target, rather than a
> "all must be done now" !

I view this as a "must be done now". :)

> Most probably, I will personally first implement .desktop files to
> have the same subset of conditions/parameters that N-A current actions.
> Only, then, I will add conditions/parameters one at a time, trying
> to keep each storage subsystems equivalent.
>
>> In addition, since both of us plan to implement this, is it possible
>> for us to write a library for the spec together? (A library based on
>> glib only in order to be used in projects other than nautilus)
>
> N-A architecture is so that desktop files are just another I/O provider,
> i.e. another storage subsystem for actions and menus. Each provider is
> implemented as a loadable module, and returns a flat list of GObject-
> derived objects.
>
> All that to say that there would actually be two libraries:
> - one to read from/write to desktop files:
> =A0 =A0- get a flat list of items
> =A0 =A0- update an item
> =A0 =A0- write a new item
> =A0 =A0- delete an item
> - one to deal with data at runtime:
> =A0 =A0- giving the current selection on one hand,
> =A0 =A0 =A0and an ordered tree of actions and menus in the other hand,
> =A0 =A0 =A0get a tree of menus to be displayed
>
>> As more and more desktop files are installed for those actions,
>> parsing requires more and more time. Is there any better way to cache
>> the parsed result to speed up loading, just like what
>> desktop-file-utils does?
>
> I'm not sure to well understand what you mean.
> Desktop files are not supposed to be parsed each time we have to display
> a context menu. We surely have a list of objects in memory, don't we ?
> Contrarily, each condition, each parameter must be re-evaluated each time
> we want display a context menu (because it depends of context ;-)) and th=
e
> selection has changed.
>
> This was long! I hope this will be readable :)
>
> Regards
> Pierre
>