Actions extensions in File Managers - Draft 0.11

[PCMan]

On Sat, Apr 17, 2010 at 4:31 AM, Pierre Wieser <pwieser at trychlos.org> wrote:
>
> ----- "PCMan" <pcman.tw at gmail.com> wrote:
>
>> 1. If Profiles are named 'Conditions' instead, its purpose will be
>> more clear.
>
> Conditions are not profiles.
> Profiles are subject to conditions, as actions and menus are.
Since profiles actually define what the action can provide under
different conditions, I think it's ok to just call them condition
instead. Anyways, this is only a naming issue.

Besides, for the name "X-Action-Profile", why is the "X-" needed?
Since you're now writing a formal xdg spec for it, it's ok to add new
names. You already added many new key names such as Tooltip,
TargetContext, ...etc.

BTW, I don't think it's a good idea to rename NoDisplay to Enabled
although I agree that NoDisplay is a bad name. Keeping this is for
consistency with the desktop entry spec.

> For example, one may decide that a whole menu, and, therefore, all its
> subitems, are only dedicated to subversion management. We so may have :
>
>    [Desktop Entry]
>    Type = Menu
>    Name = Subversion management
>    ShowIfTrue = [ -r %d/.svn/entries ] && echo "true"
>    ItemsList = checkout; commit;
>
> This is a sort of "factorization" of the 'svn' condition to the
> upper level.
>
> In the other hand, profiles may be seen as an implementation of
> different use cases for a same action.
>
> The only case where it makes sense for a profile to not have any
> condition is when the action has only one profile. It so makes no
> difference if conditions are described at action level or at profile
> level.
>
>> 2. I'd suggest use *.menu instead of *.desktop for menu definition
>> files. This can ease the implementation and also better for
>> maintainace since you can know it's a menu without examing its
>> content.
>
> DES only defines .desktop and .directory files.
DES never defines .directory files. They are defined in menu spec as
an 'extension' to DES. So it's ok to have different filenames in DES
extension. There is no benefit to force the *.desktop name since file
managers won't load it in other cases. GAppInfo in glib/gio only
handles Type=Application and ignore all the others. So even if you
have *.desktop as filenames, this will only result in errors in some
file managers since they are treated as normal desktop entry file bug
glib cannot load them at all.
> If we choose .menu for menus, it would make sense imho to have
> .action for actions.
Yes, it makes sense.
> We are moving here a bit more away from DES, don't we ?
I don't think so. If I want to customize the order of some menu items,
I only need to find the related *.menu file and edit ItemList. If it's
not named *.menu, it could be hard to find. Of course you have GUI
editors, but I think apart from manual editing, there will be other
possible use cases. Otherwise, why the guys writing the menu spec name
the directory files as *.directory instead of just call them
*.desktop? I don't find a use case for this need, either.

> I don't have seen in my own experience the case where I needed to
> know I have a menu (resp. an action), but wasn't interested to its
> content. As in the runtime plugin as in the UI management, I do load
> all in memory, and do my work there.
This is only one way to implement the spec. Other implementations
don't necessarily work this way.

>> 3. In this way defining a menu with several items and submenus
>> requires many *.desktop files. This makes things a little bit
>> complicated and also this can create a headache for maintainers of
>> those actions. I'll try to propose a more consolidated and simpler
>> file format later.
>
> Don't really agree. This seems more simpler for a packager to drop
> a new .desktop file, that to have to update a single file which would
> contain all possible actions.
>
> And maintainer of an action has just to update its own .desktop file.
> What sort of headache are you afraid of ?
If you have a menu, aren't the menu items in ItemList defined in many
different desktop entry action files? This seems to be inconvinient
for the package maintainer.

> On another point, I'm a bit surprised that nobody has an opinion on
> the XDG path I've choosen: XDG_DATA_DIRS/file-manager/actions.
> Is this OK for all ?
I agree with the path. Originally I want to use this path to implement
our own custom action, too. Now since you write a spec, we'll try to
implement this one instead if it meets all our needs.

>> On Fri, Apr 16, 2010 at 6:16 AM, Pierre Wieser <pwieser at trychlos.org>
>> wrote:
>> > I just updated the DES-EMA draft [1] to its version 0.11.
>> > [1] http://www.nautilus-actions.org/?q=node/377
>
> Regards
> Pierre
>