>
> applications should be detecting capabilities, not doing string
> comparisons on desktop environment names.
>
> a desktop environment UX can change without its name changing; or new
> desktop environments, with similar UX can appear.
I have to admit I do not understand this position vs. the
- Original Message -
>
> Slightly off topic, is there any consensus on how to detect current
> desktop environment?
> Previously a proposed environment variable XDG_CURRENT_DESKTOP was
> mentioned on the ML, but there was no conclusion.
> Can we start a discussion on this issue again?
>
>
> What specification are you referring to?
> In case of DES-EMA (http://www.nautilus-actions.org/?q=node/377), I
> don't think that's deprecated. In fact, nautilus-actions still
> exists, even if it's not in the default package set.
Humm.. Yes, I do confirm: Nautilus-Actions still exists ;)
And no
>
> Sorry I am late to the party here and may be off thread. This was
> discussed back in 2009 with the proposal at that time being
> XDG_CURRENT_DESKTOP.
>
> The shipping versions of LXDE have been using this to control how the
> menu processor matches OnlyShowIn and NotShowIn. It also uses
> XD
> That being said, I think it might be worth a standard environment
> variable to get that. There isn't one that I know of today.
>
I agree.
May I propose XDG_DESKTOP ?
Regards
Pierre
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedes
- Original Message -
> On Mon, Feb 21, 2011 at 10:31 PM, Pierre Wieser
> wrote:
> > Well, I used to believe that autotools were rather useful at compile
> > time. What I am searching for here is a runtime check, and I thought
> > this was the meaning of the Deskt
- Original Message -
> On Sun, 2011-02-20 at 14:56 +0100, Pierre Wieser wrote:
> >
> > At least, xdg-open will give me a start point for most popular
> > desktops.
>
> I think its a wrong direction to head, and xdg-open shows exactly why.
> You end up with
- Original Message -
> Dnia niedziela, 20 lutego 2011 o 14:56:53 Pierre Wieser napisał(a):
> > May I suggest to the list that adding a desktop to a XDG spec
> > (e.g. Registered OnlyShowIn Environments of menu spec) requires
> > to also specify how to iden
- Original Message -
> Dnia sobota, 19 lutego 2011 o 23:59:21 Pierre Wieser napisał(a):
> >
> > While talking about Desktop Actions, this remind me that I do not
> > know how to determine what is the currently running desktop :(
> >
> > Does anyone could
Hi,
In my small application, desktop actions are supposed to be displayed
depending of the mimetype of files currently selected in the file-manager.
I am able to find the mimetype of the file, but I feel it is not enough.
I understand that mimetypes are organized as some sort of hierarchy, so
I
> The use that pushed me to write the patch/email was with the Desktop
> Actions that we're putting in desktop file for static actions on the
> Launcher. Unfortunately, it's still an X- thing but I intend to update
> it to the current version of the Desktop Actions spec soon (because of
> release
- "Pierre Wieser" wrote:
>
> I'd so like propose an optional 'noop' parameter (say %o/%O),
> which would be relevant regarding of this multiple execution
> feature.
Hi all,
I have updated the DES-EMA specification [1] to add '%o' and &#x
Hi guys,
I have release a few days ago Nautilus-Actions 3.0 [1] which
(almost) fully implements the DES-EMA specification [2] in
its 0.14 version.
As a side effect, the Nautilus-Actions Configuration Tool may
be used to also create KDE, XFCE, and so on, actions :)
While I was writing some sort o
Hi all,
I just updated our specification for action extensions in file manager
[1] to the version 0.14 of its draft.
These are just small modifications in the comments themselves:
- Remove the (non-sense) states added in the previous version,
about the value to be used in parameter expansions
Hi all,
I just updated our specification for action extensions in file manager [1]
to the version 0.13 of its draft.
Among some typo fixes, other modifications are:
- Restates in relevant chapters that actions and menus may have their own set
of conditions.
- Add a "Building the whole hierarchy"
for different mime-types.
> If this parameter is supported, its use should be limited to Exec,
> and %M should be used in conjunction with %F or %U while %m should
> only be used with %f and %u. Otherwise this looks ok to me.
>
> On Tue, Aug 3, 2010 at 5:41 PM, Pierre Wieser
>
Hi all,
I would suggest to add %m/%M parameters to the DES-EMA specification [1]
in order to get mimetypes of items selected in the file manager.
What do you think about that ?
Thanks in advance for your answer.
Regards
Pierre
[1] http://www.nautilus-actions.org/?q=node/377
- "PCMan" wrote:
> This have important use case but only if the spec supports showing
> menu items in submenus only.
> For example, if you want to create a "Subversion" support for
> currently selected files, it's reasonable that you want to put all
> supported subversion operations in a sub
- "PCMan" wrote:
> This have important use case but only if the spec supports showing
> menu items in submenus only.
> For example, if you want to create a "Subversion" support for
> currently selected files, it's reasonable that you want to put all
> supported subversion operations in a sub
- "PCMan" a écrit :
> After trying to implement this spec, I have some suggestions.
> Actions (desktop entries with Type="Action") and menus (desktop
> entries with Type="Menu") are actually very similar.
> The only difference is that an action takes "Profiles" and a menu
> reads a "ItemList
- "PCMan" a écrit :
> Another potential problem of this spec.
> When we validate all actions against currently selected files, we can
> get a list of valid actions.
> However, if an action is also in ItemList of another menu, should we
> only show it in that menu and remove it from the conte
Hi,
I just updated the DES-EMA draft [1] to its version 0.12.
There are three changes:
- in the writing, "Same as DES" words have been replaced by the
corresponding excerpt from DES;
- Capabilities default value changes from "*;" to an empty list
(do not care of any capabilities);
- Capabilities
ssible actions.
And maintainer of an action has just to update its own .desktop file.
What sort of headache are you afraid of ?
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
Hi
I just updated the DES-EMA draft [1] to its version 0.11.
Because simpler is often better, following changes are made:
- Change back the Type of actions (resp. menus) to "Action" (resp. "Menu")
- Change the keyword "_SEPARATOR_" to "SEPARATOR"
- Add Appendix D with an example of a menu
- Rena
- "PCMan" a écrit :
> 1. Action is an installed desktop entry file. It can contain a group
> of different profiles.
> 2. Profiles are basically condition/exec pairs used to decide what
> command should be executed when what criteria are met.
> 3. menus? How to define this?
Menu is just anot
Hi
I just updated the DES-EMA draft [1] to its version 0.10:
- Move Hidden and NoDisplay keys to [Desktop Entry] group.
All your comments are more than welcome.
Regards
Pierre
[1] http://www.nautilus-actions.org/?q=node/377
___
xdg mailing list
xdg@l
sorry: wrong sender address :(
- "Pierre Wieser" a écrit :
> Hi
>
> I just updated the DES-EMA draft [1] to its version 0.9:
> - define a new TargetLocation key.
>
> All your comments are more than welcome.
>
> Regards
> Pierre
>
> [1]
Hi all,
After many thoughts (and some holidays), I propose you the version 0.8
of the extension for menus and actions in desktop files [1].
This extension to DES aims to be able to share actions between
file managers of different desktops.
This version add some precisions on how deal with multip
- "PCMan" wrote:
> Maybe we can make it better defined by adding this sentence:
> If the value of this key is a number, it shuld be treated as the
> numeric id of the user (uid). Otherwise, it is treated as username.
This seems better, yes.
Joined is a second version of the patch (plus a fi
Hi
Work currently done on a shared specification about file manager actions
extensions (a definitive name is always to be found) has led us to define
an 'ExecuteAs' key.
Goal of this key is to let the action creator specify with which user/uid
the command must be ran.
We think that this key has
> De: "David Faure"
> Envoyé: Vendredi 26 Février 2010 11:51:23
>
> > - what should we do when we have e.g. 'echo %d %X' ?
>
> Good question, but I don't think this example makes sense :-)
> Either you want one invocation per selected file, or you want one invocation
> with all selected files..
Hi all
The draft has been updated to take into account last comments
from contributors.
- ExecutionMode:
No more propose Minimized/Maximized modes
(typo: remove fallback from Terminal mode)
- ForEach key is removed
- Profiles and ItemsList keys become dynamic; the behavior for found
thou
- "PCMan" a écrit :
> > On Fri, Feb 26, 2010 at 6:51 PM, David Faure wrote:
> >
> > My fear is just that at the time of adoption into DES, a different
> > name ends up being chosen, and then the code would have to cater for
> > both the "Actions extensions" name and the DES name for the sam
- "David Faure" a écrit :
> A new value for Type sounds good to me. Type=Action is maybe too
> generic (the "associating mimetypes to apps" was also called
> "action spec" at some point); maybe Type=ContextAction?
Why not, indeed ?
We should so also have Type=ContextMenu, for consistency.
- "David Faure" a écrit :
>
> Two things:
> * in KDE we can implement this using kstart
> * the application itself can use NETWM to do this kind of things
> better, but then of course it's not the user's choice anymore.
> But this means the problem we're potentially trying to solve here
> i
- "PCMan" a écrit :
> Some more comments on this spec.
>
> On Thu, Feb 11, 2010 at 1:43 AM, Pierre Wieser
> wrote:
> >
> > - "PCMan" a écrit :
> >
> >> 1. ExecutionMode seems to be weird.
> >> Terminal is
- "Damjan Jovanovic" a écrit :
> Hi
>
> I like this spec, and I am willing to implement and support it in the
> Wine project when it becomes official.
>
> It's also about time we got an actions spec. Nice work.
>
> Regards
> Damjan Jovanovic
Hi Damjan,
Thanks for your support.
It is alw
- "PCMan" a écrit :
> 1. ExecutionMode seems to be weird.
> Terminal is already defined in DES by the key 'Terminal'.
> Minimized or Maximized state of applications cannot be controlled
> by us.
> It's controlled by window managers. So I don't see any way to
> implement this corr
- "Pierre Wieser" a écrit :
> I believe we have now covered almost if not all all aspects of such a
> specification, don't we ?
It appears there were some lacks anyway ;)
I just made the following adds:
- Add Type key for distinguishing Actions from Menus.
- Spec
- "Liam R E Quin" a écrit :
> So, "the place where the user happens to click" is not random.
> It's either (1) a mistake, or (2) deliberate, and in either case
> what's wanted is predictable behaviour.
>
> It seems to me perfectly sensible to pass on the user's choice to
> applications.
Yo
- "Jonas Bähr" wrote:
> Hi,
>
> Am 07.01.2010 um 15:22 schrieb Pierre Wieser:
> > ...
> > - "Jonas Bähr" a écrit :
> >>
> >> "Path" should not be unspecified by default but rather default to
> >> "%d&
Hi all,
First, I wish you all a happy new year, lot of great things and so on.
After some days away from computers, I've updated our draft, taking
into account last Jonas's remarks. We have so a v 0.4 available at [1].
What is new here:
- "ToolbarSameLabel" action property removed
- "ExecuteAs"
Hi,
After remarks and comments of the week, I've updated our draft.
We have so a v 0.3 available at [1].
What is new there:
- I think most of parameters should be defined
- I think most of conditions should be defined
- most of string values accept parameters, not only the command arguments
- Sel
- "Ted Gould" 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
r
- "Jonas Bähr" a écrit :
>>
>> - ExecutionMode: a mode to be choosen among some predefined ones:
>>'CollectOutput'
>
> For Krusader we have the output in a dialog window, together with a
> button to kill the process (if still running), switch between fixed/
> variable width front, and
- "Jonas Bähr" a écrit :
>
> We from the Krusader file manager [1] also have our own format for
> user actions [2,3]. Based on their features I have some suggestions
> too:
> - What do you think about adding a default keyboard shortcut to the
> actions? If it's already in use by the appli
Hi David,
I've rewritten most of the first version of draft to take into account
your (welcome) remarks. So the v 0.2 is ready at [1].
Though I've not really tried to mimic the KDE Services Menus, I've yet
tried to put all required functionalities, possibly extending some of
them, taking advantag
Sorry for double post, due to wrong mail address.
- "David Faure" wrote:
> I don't think it makes sense to confuse "the main desktop menu"
> (as covered by the menu spec), and the popup menus of file managers.
Humm.. Why not ? These are just menus, don't they ?
Though I'd rather agree with
- "PCMan" wrote:
> How do you handle menu items which have submenus?
I agree that, for now, actions are just an unordered flat list of
items. IMHO, a menu item which handle a submenu is just a menu:
a label, an icon, and an ordered list of items (actions or menus).
So I think this should be
Hi all,
I've eventually written my own draft of a desktop entry specification
extension ; it is available at [1].
I don't have found a real consensus in the discussions which have
already taken place here (see e.g. [2], [3], [4]).
I have so preferred to go with a different approach which could be
- "Pierre Wieser" a écrit :
>
> I understand that there is a sort of consensus about the
> 'Desktop Action ' group in the desktop file, which should
> so be reintroduced in the spec, though I'm not sure about the
> exact function of 'Actions=
- "Vincent Untz" a écrit :
> Le vendredi 27 novembre 2009, à 12:59 +0100, Kevin Krammer a écrit :
> > On Friday, 2009-11-27, Ted Gould wrote:
> > > On Thu, 2009-11-26 at 14:30 +0100, Pierre Wieser wrote:
> > > > However, these two threads refer
- "Eugene Gorodinsky" a écrit :
> Similar discussion here:
> http://lists.freedesktop.org/archives/xdg/2009-August/010914.html
>
Hi Eugene,
Indeed, a very similar discussion, yes :)
I just didn't found the conclusion of it ?
Last message I find is those of Michael which points out a
pot
- "David Faure" wrote:
>
> Why not use "Desktop Action", even if it's not in the spec anymore?
Well, this was my first thought also. But I do worry about the
reasons behind the removal:
- if authors (hey, are you here ?) believed this group won't be
used, it could make sense to not overload
- "Ted Gould" wrote:
> On Thu, 2009-11-26 at 14:30 +0100, Pierre Wieser wrote:
> > However, these two threads refer to a 'Desktop Action' which
> > was present in current 0.9.4 spec, but has disappeared from
> > latest 1.1. Does this mean the
- "Kevin Krammer" a écrit :
>
> While this might not entirely be the same thing, a quick check of my
> local
> archive of this list found two related sounding threads:
>
> http://lists.freedesktop.org/archives/xdg/2006-February/006094.html
> http://lists.freedesktop.org/archives/xdg/2006-J
Hi guys,
I'm the Nautilus-Actions (N-A) maintainer.
N-A is an extension to Nautilus, the Gnome file manager,
which allows (advanced) users to add their own actions
in the context menu.
This is so very similar to Konqueror Service Menus and
thunar-actions-plugin.
While N-A actions used to be stor
57 matches
Mail list logo
