Wed Feb 10 09:12:24 PST 2010
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
> 8. Folders:
> Folders needs to support ! to negate specific folders, too.
> 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
> 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
> 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-
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 :)
More information about the xdg