No subject

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...

> 8. Folders:
>     Folders needs to support ! to negate specific folders, too.

Yes

> 9. Parameters:
>     Please explain the use case of %w and %W.
>     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 ?

>     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:
>     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=20
"all 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:
    - get a flat list of items
    - update an item
    - write a new item
    - delete an item
- one to deal with data at runtime:
    - giving the current selection on one hand,=20
      and an ordered tree of actions and menus in the other hand,
      get 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=20
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 the
selection has changed.=20

This was long! I hope this will be readable :)

Regards
Pierre