More about "intents": Several improvements to desktop files and caches

[Jerome Leclanche]

I recently brought up "intents" on this list and several people didn't
know what they actually were, and I didn't want to talk about them too
much until I had a clear idea of it all.

To be clear: This is about more than just intents, and some of what
I'm going to be talking about can be taken care of separately. This is
about a set of backwards-compatible improvements to desktop files that
will allow for much improved integration and interoperation of various
apps.


Problem #1
Apps cannot enumerate other apps of a specific type. A couple of
common use cases:
- A system settings app wants to know about every window manager,
terminal emulator, ... so it can show them in a dropdown to the user.
- An email client wants to open a contact manager.
- A volume control wants to open a volume mixer.

There is groundwork to solve this problem with Categories. What's
missing is a category cache, and more categories.
GNOME uses X-GNOME-Provides for windowmanager and panel. This is
something that could be solved with these changes, imo.
PCMan wrote a patch to desktop-file-utils to generate a [Category
Cache] in mimeinfo.cache. I will talk later in this email about the
mimeinfo.cache file.
https://github.com/PCMan/desktop-file-utils/commit/9d543f9090b96854606e70bc1f43b1bc98132c9e


Problem #2
Apps cannot set a default app of a specific category. Eg "default
terminal emulator", "default window manager". This is an evolution of
problem #1, as those same system settings apps would want to actually
set the default app.
defaults.list (or was it mimeapps.list now?) can be reused for this.
So we can do eg:
[Default Applications Category]
TerminalEmulator=qterminal.desktop

Now, none of this takes into account having a different default for
two different desktop environments (eg. konsole on kde and qterminal
on lxqt). I don't know whether that's a good thing or not. As a
desktop environment, I would *like* to integrate with whatever was set
as default in a previously-used DE. I also don't really think xdg
specs should be dictating actual differences between DEs, the whole
point is common functionality. If there is to be DE-specific behaviour
to be implemented, it probably should be implemented at the DE level.
I'd also like to think with improved app integration, users are not
going to *want* different defaults in different DEs but simply run
whatever is installed. Hey, I can dream, right?


Problem #3
XDG makes no conceptual difference between "View" and "Edit".
Currently, the only defined action is "open".
Common use cases:
- I want to *view* an HTML file in a web browser. I want to *edit* an
HTML file in a text editor.
- I want to *view* an image in an image viewer (like feh). I want to
*edit* an image in the GIMP.
- I don't want to *edit* a PDF in the GIMP, even though it can *open* it.
- I really don't like the GIMP.

There was talk about generic intents for View and Edit but this just
makes things a lot more confusing than it should. I think the best
solution is a set of two new keys: "View" and "Edit" (or MimeTypeView
and MimeTypeEdit, doesn't matter the name). These two keys will be
like the MimeType key except the given mime types will be associated
with a more specific action of viewing or editing a file.
The MimeType key will then be the more generic "Open" action, which
will still be the default unless the app chooses otherwise. For
example, xdg-open can gain an --edit or --view flag. A File Manager
will probably want to use the action "View" by default (and this could
be configured further).

Implementation proposal: In the mimeinfo.cache, we will need two new
sections. "MIME View Cache" and "MIME Edit Cache". In defaults.list,
we will also need "Default View Applications" and "Default Edit
Applications" sections, for symmetry.
TBD: The "Open" order. Obviously if there are no Open actions
available but an Edit or a View action is present, we'll want to
fallback on either. Do we fall back to Edit or View by default?


Problem #4
Desktop Actions cannot be bound to MIME types.
Use case: An application offers different "modes" (with different
command lines) for different file types.
I have encountered this use case with mplayer2 (aka mplayer aka mpv).
The app behaves differently on audio and video files, as audio files
offer no interface other than console; it is then problematic when
opening a file from a file manager (either you get a terminal for
video files or you get audio files that cannot be stopped).
I brought this up in the past: Desktop Actions cannot have a MimeType
key. This is partly
because it was never requested before, partly because it requires new
syntax in mimeinfo.cache.
Worth noting: This can all partly be solved with different desktop
files but I HATE that. To me, the concept of "one desktop file per
app" is strongly engrained. It is much more declarative and on top of
that it allows treating two actions differently in, for example, a
launcher/runner/menu rather than show up app duplicates.

Implementation proposal: In mimeinfo.cache, we identify desktop files
by special, currently-reserved syntax. For example:
image/png=foo.desktop;bar.desktop[Gallery];. ALTERNATIVELY,
image/png=foo.desktop;bar.desktop[Desktop Action Gallery]; The latter
is more verbose but more extensible.
This *should* be backwards-compatible as most implementations will
probably just think it's a missing desktop file. Needs testing.


Finally: Intents
Intents is a name I originally picked before I even knew "android
intents" were a thing (I've been thinking about them for a long, long
time...). Learning about android intents was very instructive and they
inspired a lot of the current functionality of intents.

The idea: An app invokes another app's functionality through dbus. The
functionality offered by the app is standardized and the user is
presented with the choice of app to use for said functionality.

Example: A contact/user manager lets you modify a user's avatar by
either *picking a file through the file manager* or *using a "Camera"
app to take a picture*.
(For more example, just open an android phone and look at the way
various actions can be executed through different files)

So instead of integrating with a specific app, the developer
integrates with the intent and all apps implementing the intent are
then supported.

The actual intent is a dbus interface of the same name as the intent
itself. For example, xdg.intents.Camera (and the method here would be
eg. xdg.intents.Camera.TakePicture). The name does not matter at the
moment as long as the interface is the same.

There's a lot TBD still. For example: Do we require apps implementing
an intent to support every method of the intent? I don't think it's
necessary due to dbus introspection letting us figure out whether a
method is supported.
This would, once again, require adding more categories in
mimeinfo.cache and defaults.list (or mimeapps.list, I really have no
idea which is the deprecated one). And those would be unrelated to
mimetypes really.
-> So now we're at the point where these two files have a lot of
sections and it's worth mentioning the name of the file itself has
lost its meaning. In an ideal world I would say "Move to a generic
desktop.cache and associations.list name", but this all needs to be
backwards compatible and I strongly believe it's better to have it all
in one file. I am fine with deprecating the current file names in
favour of a new, generic one but.. yeah.

Further point about intents: Something called "Portals" was brought up
in the last desktop summit. I tried to get an update about this with
no response from anyone. Portals are the concept of communication
between two sandboxed apps, once again in the same style as android.
This would work just fine with intents and would be handled by the
newly-implemented kdbus (kernel dbus). I suppose different interfaces
might have to be supported depending on whether you want a filename
(dbus, fast, doesn't work sandboxed) or the full file data (kdbus
only, slow on dbus, only way to get it working sandboxed).


Bonus problem: Binding applications to a url glob. For example,
github.com/* opens in the github desktop app. Android intents do that
and that's the only reason I'm bringint this up; this is imho nearly
irrelevant to the desktop. I have to admit I'd like to see it and it
would be pretty easy to do, but the only real use case would be mobile
OSes supporting xdg.


Phew. Please, please bring up anything that doesn't make sense or
seems silly and explain why; there's a lot to think about in all this
and working on it can (and does) give me tunnel vision. I also don't
deal that much with dbus, so please correct me if I'm making wrong
assumptions.
If you are coming to FOSDEM, I will be demoing much of this in the
Desktops devroom so come say hi and shout at me.
J. Leclanche

[Ryan Lortie]

hi,

Post by Jerome Leclanche
Problem #1
Apps cannot enumerate other apps of a specific type. A couple of

It is my "intent" (ha...) to raise for a while that I want to introduce
a new key to desktop files called "Implements". There is already some
discussion about that here:
https://bugzilla.gnome.org/show_bug.cgi?id=712391


In terms of the desktop entry spec, such an addition would be extremely
simple: we have a new 'string list' key called "Implements" with no
particular meaning except that each entry in the list is expected to be
in D-Bus interface name style.

This would solve your "enumerate apps of a specific type" assuming that
you have someone willing to specify, concretely, what it means to be a
given type of application. Taking your 'terminal emulator' example from
another part of this mail, we could have an
org.freedesktop.TerminalEmulator interface (that may not be an actual
D-Bus interface) that specifies what you must do if you're a terminal
emulator and what you can expect a terminal emulator to do if you find
its desktop file via a lookup on
"Implements=org.freedesktop.TerminalEmulator".

*Often* this will imply that an application implements said interface on
the same object path as the org.freedesktop.Application interface, but
this is not a hard requirement. I suspect it would be a recommendation,
though.

I'd be happy to write up a patch to the spec for this part at least.
It's been on the long tail of my TODO list for a while, and if you need
it too, that bumps the priority a bit for me.

Of course, we would then create an index based on this item in the
desktop cache so that we could very rapidly lookup "give me all apps
that are terminal emulators".

Cheers

[Jerome Leclanche]

Post by Ryan Lortie
hi,

Post by Jerome Leclanche
Problem #1
Apps cannot enumerate other apps of a specific type. A couple of

It is my "intent" (ha...) to raise for a while that I want to introduce
a new key to desktop files called "Implements". There is already some
https://bugzilla.gnome.org/show_bug.cgi?id=712391
In terms of the desktop entry spec, such an addition would be extremely
simple: we have a new 'string list' key called "Implements" with no
particular meaning except that each entry in the list is expected to be
in D-Bus interface name style.
This would solve your "enumerate apps of a specific type" assuming that
you have someone willing to specify, concretely, what it means to be a
given type of application. Taking your 'terminal emulator' example from
another part of this mail, we could have an
org.freedesktop.TerminalEmulator interface (that may not be an actual
D-Bus interface) that specifies what you must do if you're a terminal
emulator and what you can expect a terminal emulator to do if you find
its desktop file via a lookup on
"Implements=org.freedesktop.TerminalEmulator".
*Often* this will imply that an application implements said interface on
the same object path as the org.freedesktop.Application interface, but
this is not a hard requirement. I suspect it would be a recommendation,
though.
I'd be happy to write up a patch to the spec for this part at least.
It's been on the long tail of my TODO list for a while, and if you need
it too, that bumps the priority a bit for me.
Of course, we would then create an index based on this item in the
desktop cache so that we could very rapidly lookup "give me all apps
that are terminal emulators".
Cheers

Yes, that was my original idea with intents. I reconsidered after some
discussion though: It is much easier to use the existing Categories
key and improve upon it. Intents themselves can be dbus-only and the
same format as you mentioned, while improving Categories has the major
advantage that a lot of existing apps will be straight up compatible.
What do you think? Is there anything (non-dbus) in your Implements
idea that can't be solved by Categories? Keeping in mind that anything
that has a dbus interface might as well be an intent (or Implements,
or however it'd be called).

J. Leclanche

[Jasper St. Pierre]

Post by Jerome Leclanche

hi,

Yes, that was my original idea with intents. I reconsidered after some
discussion though: It is much easier to use the existing Categories
key and improve upon it. Intents themselves can be dbus-only and the
same format as you mentioned, while improving Categories has the major
advantage that a lot of existing apps will be straight up compatible.
What do you think? Is there anything (non-dbus) in your Implements
idea that can't be solved by Categories? Keeping in mind that anything
that has a dbus interface might as well be an intent (or Implements,
or however it'd be called).

Categories are a set of defined categories used for grouping in menu
systems. They're fairly loosely defined, and I don't think they make a good
fit for intents.

"AudioVideo", "Utilities" and "Education" don't tell me anything about what
the app is, or what its interface will be.

Something more defined and explicit about what the app is and what it will
provide is a much better base for a new system.

J. Leclanche

Post by Jerome Leclanche
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Ryan Lortie]

hi,

Post by Jasper St. Pierre
Categories are a set of defined categories used for grouping in menu
systems. They're fairly loosely defined, and I don't think they make a
good fit for intents.

They may be loosely defined in terms of what it means to be one, but
they are very rigorously defined in terms of what the valid values are.
The desktop entry spec refers you to the menu spec, which list them off:

http://standards.freedesktop.org/menu-spec/latest/apa.html

In a way, this is the exact opposite of what we're trying to do with
Implements=, which aims to be openly extensible by anyone who wants to
define their own interface, but very well-defined on an item-by-item
basis.

The intended usage is entirely different as well. It's pretty clear
that categories are entirely meant for grouping in menus (or similar
things).

It would also be very strange to see reverse-DNS style interface names
listed alongside things like "Network" and "Graphics".

I think a separate key is warranted.

Cheers

[Jerome Leclanche]

Post by Jasper St. Pierre

Post by Jerome Leclanche

hi,

Yes, that was my original idea with intents. I reconsidered after some
discussion though: It is much easier to use the existing Categories
key and improve upon it. Intents themselves can be dbus-only and the
same format as you mentioned, while improving Categories has the major
advantage that a lot of existing apps will be straight up compatible.
What do you think? Is there anything (non-dbus) in your Implements
idea that can't be solved by Categories? Keeping in mind that anything
that has a dbus interface might as well be an intent (or Implements,
or however it'd be called).

Categories are a set of defined categories used for grouping in menu
systems. They're fairly loosely defined, and I don't think they make a good
fit for intents.
"AudioVideo", "Utilities" and "Education" don't tell me anything about what
the app is, or what its interface will be.
Something more defined and explicit about what the app is and what it will
provide is a much better base for a new system.

Post by Jerome Leclanche
J. Leclanche
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

--
Jasper

I know it can be a bit unclear, but I want to stress that most of
these changes are, although related, *separate*. As such, the changes
to categories (problems #1 and #2) are not directly tied to intents,
they just allow better enumeration.

There's of course the matter of more generic categories, which is
still fine. If you want to enumerate every "Education" software,
that's your deal. The idea is to

Post by Jasper St. Pierre
hi,

Post by Jerome Leclanche
Categories are a set of defined categories used for grouping in menu
systems. They're fairly loosely defined, and I don't think they make a
good fit for intents.

They may be loosely defined in terms of what it means to be one, but
they are very rigorously defined in terms of what the valid values are.
http://standards.freedesktop.org/menu-spec/latest/apa.html
In a way, this is the exact opposite of what we're trying to do with
Implements=, which aims to be openly extensible by anyone who wants to
define their own interface, but very well-defined on an item-by-item
basis.

What really bothers me is that Categories are really just.. already
there. It came up a lot while I was writing this. Apps already set
their own categories, and they'll keep doing so.
I see what you mean about categories not being "openly extensible"
though. My original wish was for an app dev to be able to just say
"this app is a TwitterClient".

What I'd suggest is recommend "X-Foo" categories as free to use.

Post by Jasper St. Pierre
The intended usage is entirely different as well. It's pretty clear
that categories are entirely meant for grouping in menus (or similar
things).
It would also be very strange to see reverse-DNS style interface names
listed alongside things like "Network" and "Graphics".
I think a separate key is warranted.
Cheers

J. Leclanche

[Ryan Lortie]

hi,

Post by Jerome Leclanche
though. My original wish was for an app dev to be able to just say
"this app is a TwitterClient".

What does this mean? What makes an app a twitter client? What about
emacs with twitter support? Does it implement some particular
interface?

Probably the best answer here is "this is something that a human user
would think is a program that they could use to post to twitter". It's
not about a particular concrete interface, but rather a "fuzzy"
definition that's mostly beneficial in terms of human understanding.

This sort of thing is useful precisely because it is explicitly
enumerated: people implementing menu systems can know what categories
apps will use. If we explicitly defined a "twitter client" category
then that might be nice. This is only particularly useful if widely
respected (which is why the list of valid categories is specified).

Intents based on solid interfaces are beneficial for another reason: all
you need is a provider and a consumer who agree on the interface. It's
not something that is interesting to humans in the "fuzzy" sense I
discuss above and therefore totally useless to support except when both
sides agree on the protocol already.

The idea of X-Foo categories starts walking you into an area where the
benefits are not clear: you have a poorly-defined fuzzy idea of
something that is useful to humans but also not widely understood in
terms of categorisation by different desktop environments in terms of
how they present that information to the human.

That said -- other than the lingering feeling that maybe we should
deprecate the menu spec -- there is no reason that I would oppose adding
an explicit nod for use of X-Foo type categories if people really want
to use them for some specific-to-desktop purpose with the understanding
that it will not work well on other systems. If anyone else has
something to say about that, they can speak up now, but otherwise I'd be
open to accepting a patch for that.

This is definitely something separate from the concrete
designed-for-machine-consumption Implements=, however.

Cheers

[Jerome Leclanche]

Post by Ryan Lortie
hi,

Post by Jerome Leclanche
though. My original wish was for an app dev to be able to just say
"this app is a TwitterClient".

What does this mean? What makes an app a twitter client? What about
emacs with twitter support? Does it implement some particular
interface?
Probably the best answer here is "this is something that a human user
would think is a program that they could use to post to twitter". It's
not about a particular concrete interface, but rather a "fuzzy"
definition that's mostly beneficial in terms of human understanding.
This sort of thing is useful precisely because it is explicitly
enumerated: people implementing menu systems can know what categories
apps will use. If we explicitly defined a "twitter client" category
then that might be nice. This is only particularly useful if widely
respected (which is why the list of valid categories is specified).
Intents based on solid interfaces are beneficial for another reason: all
you need is a provider and a consumer who agree on the interface. It's
not something that is interesting to humans in the "fuzzy" sense I
discuss above and therefore totally useless to support except when both
sides agree on the protocol already.
The idea of X-Foo categories starts walking you into an area where the
benefits are not clear: you have a poorly-defined fuzzy idea of
something that is useful to humans but also not widely understood in
terms of categorisation by different desktop environments in terms of
how they present that information to the human.
That said -- other than the lingering feeling that maybe we should
deprecate the menu spec -- there is no reason that I would oppose adding
an explicit nod for use of X-Foo type categories if people really want
to use them for some specific-to-desktop purpose with the understanding
that it will not work well on other systems. If anyone else has
something to say about that, they can speak up now, but otherwise I'd be
open to accepting a patch for that.
This is definitely something separate from the concrete
designed-for-machine-consumption Implements=, however.

Yes, absolutely. I think we agree, really - What you call
"Implements", I call "Intents" and they're dbus only. In fact I think
this is what we had discussed last february.

As for categories, I don't understand why you'd want to deprecate
them. They do a pretty good job of what they were meant for:
Categories. I would *like* to use that to be able to pull, say, "every
window manager" or "every terminal emulator", or "every panel" etc.
You do see the value in this, right? Because, sure, those apps could
just implement the relevant intents, but they can't necessarily do
that as we want them to be dbus only (and what would a dbus
"TerminalEmulator" intent do?)
I think splitting categories and intents makes a lot of sense, and is
actually a lot clearer for the end users. They keep using what they've
been using all that time (categories), and for more specific actions
they use intents.

To be clear: To me, intents = communication between apps through
declarative dbus APIs. Categories = Enumerating a specific type of
app.

Post by Ryan Lortie
Cheers

[Ryan Lortie]

hi,

Post by Jerome Leclanche
To be clear: To me, intents = communication between apps through
declarative dbus APIs. Categories = Enumerating a specific type of
app.

I think we're in agreement there.

Here's a patch: https://bugs.freedesktop.org/show_bug.cgi?id=73317

Reviews are welcome from all. Let's keep discussion about specific
issues of this part of discussion on bugzilla, and continue to address
the other issues raised in your first email in this thread.

Cheers

[David Faure]

Post by Ryan Lortie

Post by Jerome Leclanche
Problem #1
Apps cannot enumerate other apps of a specific type. A couple of

It is my "intent" (ha...) to raise for a while that I want to introduce
a new key to desktop files called "Implements". There is already some
https://bugzilla.gnome.org/show_bug.cgi?id=712391
In terms of the desktop entry spec, such an addition would be extremely
simple: we have a new 'string list' key called "Implements" with no
particular meaning except that each entry in the list is expected to be
in D-Bus interface name style.
This would solve your "enumerate apps of a specific type" assuming that
you have someone willing to specify, concretely, what it means to be a
given type of application.

Not really, it's useful but orthogonal.

To let users choose their preferred webbrowser, terminal emulator, WM, and
mail app, all we need is an interface "name" like WebBrowser,
TerminalEmulator, WindowManager, Mail, InstantMessenger, without any relation
to DBus.
E.g. some users might want firefox as their default webbrowser, xterm as their
terminal emulator, twm (ok just joking), skype and thunderbird...

Your suggested spec change seems to suggest that it's ok for an interface not
to be related to DBus, but the way it's worded, I think we'll soon have dbus
interfaces for all these, which excludes apps that don't implement these
interfaces.

There are two different use cases, one about "letting the user choose a type
of application and use that from other apps, with a simple Exec line"
and one about "letting the user choose a type of application to provide a
certain service over dbus".

For the first one, maybe Categories are enough? I didn't check if they work
100% for these use cases above.

For sure we're missing desktop files for windowmanagers :)

[Bastien Nocera]

Post by David Faure

Post by Ryan Lortie

Post by Jerome Leclanche
Problem #1
Apps cannot enumerate other apps of a specific type. A couple of

It is my "intent" (ha...) to raise for a while that I want to introduce
a new key to desktop files called "Implements". There is already some
https://bugzilla.gnome.org/show_bug.cgi?id=712391
In terms of the desktop entry spec, such an addition would be extremely
simple: we have a new 'string list' key called "Implements" with no
particular meaning except that each entry in the list is expected to be
in D-Bus interface name style.
This would solve your "enumerate apps of a specific type" assuming that
you have someone willing to specify, concretely, what it means to be a
given type of application.

Not really, it's useful but orthogonal.
To let users choose their preferred webbrowser, terminal emulator, WM, and
mail app, all we need is an interface "name" like WebBrowser,
TerminalEmulator, WindowManager, Mail, InstantMessenger, without any relation
to DBus.

D-Bus-style name.

This allows namespacing and versioning.

org.freedesktop.TerminalEmulator1
or org.gnome.TerminalEmulator2
vs. simply TerminalEmulator

And it's more about services (allow me to pick a photo, or select a
contact) than about full-fledged applications. A terminal emulator can
hardly be thought as providing a service to other applications, a photo
picker provided by the native photo application would.

[David Faure]

Post by Bastien Nocera
And it's more about services (allow me to pick a photo, or select a
contact) than about full-fledged applications. A terminal emulator can
hardly be thought as providing a service to other applications, a photo
picker provided by the native photo application would.

My point is that both needs (i.e. use cases) exist.

I know that "intents" and the use of dbus interfaces is about what you
describe.

I'm simply pointing out that the other use case (merely starting apps, at most
with a url on the command line) exists too, and that I'd like to see a
standard solution for it.

[Bastien Nocera]

Post by David Faure

Post by Bastien Nocera
And it's more about services (allow me to pick a photo, or select a
contact) than about full-fledged applications. A terminal emulator can
hardly be thought as providing a service to other applications, a photo
picker provided by the native photo application would.

My point is that both needs (i.e. use cases) exist.
I know that "intents" and the use of dbus interfaces is about what you
describe.
I'm simply pointing out that the other use case (merely starting apps, at most
with a url on the command line) exists too, and that I'd like to see a
standard solution for it.

The URL would/should have a mime-type associated to it, so you can just
lookup by mime-type.

[David Faure]

Post by Bastien Nocera

Post by David Faure

Post by Bastien Nocera
And it's more about services (allow me to pick a photo, or select a
contact) than about full-fledged applications. A terminal emulator can
hardly be thought as providing a service to other applications, a photo
picker provided by the native photo application would.

My point is that both needs (i.e. use cases) exist.
I know that "intents" and the use of dbus interfaces is about what you
describe.
I'm simply pointing out that the other use case (merely starting apps, at
most with a url on the command line) exists too, and that I'd like to see
a standard solution for it.

The URL would/should have a mime-type associated to it, so you can just
lookup by mime-type.

"at most" means "sometimes none".

There's no URL and no mimetype involved when listing or starting
- window managers
- terminal emulators
- instant messaging apps
- email clients

[Bastien Nocera]

Post by David Faure

Post by Bastien Nocera

Post by David Faure

Post by Bastien Nocera
And it's more about services (allow me to pick a photo, or select a
contact) than about full-fledged applications. A terminal emulator can
hardly be thought as providing a service to other applications, a photo
picker provided by the native photo application would.

My point is that both needs (i.e. use cases) exist.
I know that "intents" and the use of dbus interfaces is about what you
describe.
I'm simply pointing out that the other use case (merely starting apps, at
most with a url on the command line) exists too, and that I'd like to see
a standard solution for it.

The URL would/should have a mime-type associated to it, so you can just
lookup by mime-type.

"at most" means "sometimes none".
There's no URL and no mimetype involved when listing or starting
- window managers
- terminal emulators

Those would be covered by the Implements changes documented by Ryan:
https://bugs.freedesktop.org/show_bug.cgi?id=73317

Post by David Faure
- instant messaging apps

xmpp, and irc schemes at least, so those are covered by
x-scheme-handler/*

Post by David Faure
- email clients

mailto scheme

[Jerome Leclanche]

Post by Ryan Lortie

Post by David Faure

Post by Bastien Nocera

Post by David Faure

Post by Bastien Nocera
And it's more about services (allow me to pick a photo, or select a
contact) than about full-fledged applications. A terminal emulator can
hardly be thought as providing a service to other applications, a photo
picker provided by the native photo application would.

My point is that both needs (i.e. use cases) exist.
I know that "intents" and the use of dbus interfaces is about what you
describe.
I'm simply pointing out that the other use case (merely starting apps, at
most with a url on the command line) exists too, and that I'd like to see
a standard solution for it.

The URL would/should have a mime-type associated to it, so you can just
lookup by mime-type.

"at most" means "sometimes none".
There's no URL and no mimetype involved when listing or starting
- window managers
- terminal emulators

https://bugs.freedesktop.org/show_bug.cgi?id=73317

Post by David Faure
- instant messaging apps

xmpp, and irc schemes at least, so those are covered by
x-scheme-handler/*

Post by David Faure
- email clients

mailto scheme

All these are not safe assumptions. Quassel, for example, does not
support irc: uris.

J. Leclanche

[Dominique Michel]

Le Mon, 6 Jan 2014 15:38:34 +0000,

Post by Jerome Leclanche

Post by Ryan Lortie

Post by David Faure

Post by Bastien Nocera

Post by David Faure

Post by Bastien Nocera
And it's more about services (allow me to pick a photo, or
select a contact) than about full-fledged applications. A
terminal emulator can hardly be thought as providing a
service to other applications, a photo picker provided by
the native photo application would.

My point is that both needs (i.e. use cases) exist.
I know that "intents" and the use of dbus interfaces is about
what you describe.
I'm simply pointing out that the other use case (merely
starting apps, at most with a url on the command line) exists
too, and that I'd like to see a standard solution for it.

The URL would/should have a mime-type associated to it, so you
can just lookup by mime-type.

"at most" means "sometimes none".
There's no URL and no mimetype involved when listing or starting
- window managers
- terminal emulators

https://bugs.freedesktop.org/show_bug.cgi?id=73317

Post by David Faure
- instant messaging apps

xmpp, and irc schemes at least, so those are covered by
x-scheme-handler/*

Post by David Faure
- email clients

mailto scheme

All these are not safe assumptions. Quassel, for example, does not
support irc: uris.

Is it not the job of an application, or package manager, to
provide the right mimes type for the application?

If that mime type does not exist, it must be added.

Dominique

Post by Jerome Leclanche
J. Leclanche
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Jerome Leclanche]

On Tue, Jan 7, 2014 at 3:24 PM, Dominique Michel

Post by Dominique Michel
Le Mon, 6 Jan 2014 15:38:34 +0000,

Post by Jerome Leclanche

Post by Ryan Lortie

Post by David Faure

Post by Bastien Nocera

Post by David Faure

Post by Bastien Nocera
And it's more about services (allow me to pick a photo, or
select a contact) than about full-fledged applications. A
terminal emulator can hardly be thought as providing a
service to other applications, a photo picker provided by
the native photo application would.

My point is that both needs (i.e. use cases) exist.
I know that "intents" and the use of dbus interfaces is about
what you describe.
I'm simply pointing out that the other use case (merely
starting apps, at most with a url on the command line) exists
too, and that I'd like to see a standard solution for it.

The URL would/should have a mime-type associated to it, so you
can just lookup by mime-type.

"at most" means "sometimes none".
There's no URL and no mimetype involved when listing or starting
- window managers
- terminal emulators

https://bugs.freedesktop.org/show_bug.cgi?id=73317

Post by David Faure
- instant messaging apps

xmpp, and irc schemes at least, so those are covered by
x-scheme-handler/*

Post by David Faure
- email clients

mailto scheme

All these are not safe assumptions. Quassel, for example, does not
support irc: uris.

Is it not the job of an application, or package manager, to
provide the right mimes type for the application?
If that mime type does not exist, it must be added.
Dominique

Post by Jerome Leclanche
J. Leclanche
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

The association is irrelevant. Quassel does not support being given
irc uris. You're welcome to write a patch for every broken app,
though.

J. Leclanche

[Jasper St. Pierre]

What's the use case you imagine where the user would want to choose from a
list of IRC clients, without the list actually able to launch the IRC
client in question with a specific server/channel?

It seems quite backwards to have a way to say "this app supports this
API/protocol" with the app actually not being able to support that
API/protocol. If the app wants to announce itself as an IRC client, it
needs to handle the "I support IRC protocol". Yes, that could mean
something different from irc: URIs, but if Quassel doesn't support IRC
URIs, what makes you think it will gain support for your protocol, or why
your protocol is better than IRC URIs?

Post by Jerome Leclanche
On Tue, Jan 7, 2014 at 3:24 PM, Dominique Michel

Post by Dominique Michel
Le Mon, 6 Jan 2014 15:38:34 +0000,

Post by Jerome Leclanche

Post by Ryan Lortie

Post by David Faure

Post by Bastien Nocera

Post by David Faure

Post by Bastien Nocera
And it's more about services (allow me to pick a photo, or
select a contact) than about full-fledged applications. A
terminal emulator can hardly be thought as providing a
service to other applications, a photo picker provided by
the native photo application would.

My point is that both needs (i.e. use cases) exist.
I know that "intents" and the use of dbus interfaces is about
what you describe.
I'm simply pointing out that the other use case (merely
starting apps, at most with a url on the command line) exists
too, and that I'd like to see a standard solution for it.

The URL would/should have a mime-type associated to it, so you
can just lookup by mime-type.

"at most" means "sometimes none".
There's no URL and no mimetype involved when listing or starting
- window managers
- terminal emulators

https://bugs.freedesktop.org/show_bug.cgi?id=73317

Post by David Faure
- instant messaging apps

xmpp, and irc schemes at least, so those are covered by
x-scheme-handler/*

Post by David Faure
- email clients

mailto scheme

All these are not safe assumptions. Quassel, for example, does not
support irc: uris.

Is it not the job of an application, or package manager, to
provide the right mimes type for the application?
If that mime type does not exist, it must be added.
Dominique

Post by Jerome Leclanche
J. Leclanche
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

The association is irrelevant. Quassel does not support being given
irc uris. You're welcome to write a patch for every broken app,
though.
J. Leclanche
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Jerome Leclanche]

Post by Jasper St. Pierre
What's the use case you imagine where the user would want to choose from a
list of IRC clients, without the list actually able to launch the IRC client
in question with a specific server/channel?

We've been through this.

Post by Jasper St. Pierre
It seems quite backwards to have a way to say "this app supports this
API/protocol" with the app actually not being able to support that
API/protocol. If the app wants to announce itself as an IRC client, it needs
to handle the "I support IRC protocol". Yes, that could mean something
different from irc: URIs, but if Quassel doesn't support IRC URIs, what
makes you think it will gain support for your protocol, or why your protocol
is better than IRC URIs?

Please do not make assumptions about an app's command line interface.
A web browser can be a web browser without ever accepting http uris as
argument. IM clients themselves are much, much less likely to accept
protocol URIs, especially since some of the protocols they support
simply don't have special URIs, and just because xmpp does doesn't
mean that it makes sense to accept it as a URI.

Furthermore I have no idea what you mean by "gaining support for my
protocol". You are conflating protocols and URIs.

J. Leclanche

Post by Jasper St. Pierre

Post by Jerome Leclanche
On Tue, Jan 7, 2014 at 3:24 PM, Dominique Michel

Post by Dominique Michel
Le Mon, 6 Jan 2014 15:38:34 +0000,

Post by Jerome Leclanche

Post by Ryan Lortie

Post by David Faure

Post by Bastien Nocera

Post by David Faure

Post by Bastien Nocera
And it's more about services (allow me to pick a photo, or
select a contact) than about full-fledged applications. A
terminal emulator can hardly be thought as providing a
service to other applications, a photo picker provided by
the native photo application would.

My point is that both needs (i.e. use cases) exist.
I know that "intents" and the use of dbus interfaces is about
what you describe.
I'm simply pointing out that the other use case (merely
starting apps, at most with a url on the command line) exists
too, and that I'd like to see a standard solution for it.

The URL would/should have a mime-type associated to it, so you
can just lookup by mime-type.

"at most" means "sometimes none".
There's no URL and no mimetype involved when listing or starting
- window managers
- terminal emulators

https://bugs.freedesktop.org/show_bug.cgi?id=73317

Post by David Faure
- instant messaging apps

xmpp, and irc schemes at least, so those are covered by
x-scheme-handler/*

Post by David Faure
- email clients

mailto scheme

All these are not safe assumptions. Quassel, for example, does not
support irc: uris.

Is it not the job of an application, or package manager, to
provide the right mimes type for the application?
If that mime type does not exist, it must be added.
Dominique

Post by Jerome Leclanche
J. Leclanche
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

The association is irrelevant. Quassel does not support being given
irc uris. You're welcome to write a patch for every broken app,
though.
J. Leclanche
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

--
Jasper

[Jasper St. Pierre]

A protocol is simply a semi-standard way of using an application.

For instance, when you set the EDITOR environment variable, the expectation
is that the command in EDITOR will accept at zero or one filenames after it.

So: `$EDITOR my_file.txt`

I'd consider that a "protocol". It's undocumented and mostly ad-hoc (UNIX
philosophy at its finest), but lots of programs support launching
`$EDITOR`, and lots of programs support being set as `$EDITOR`.

If I make a "default browser selector" widget, there better be a way of
telling the browser how to launch a specific webpage, since the whole point
of a "default browser" is to let me select what happens when I click on a
very specific webpage. Yes, web browsers don't *have* to have that
functionality, but they shouldn't be able to be selected as a "default
browser".

So, I'm skeptical of the value or utility of the user selecting one of many
"IRC Client"s from a list without any guarantee about what the program even
does. So, what's the goal of building a list of IRC Clients? What will the
user do with this list that's good for them?

Post by Jerome Leclanche

Post by Jasper St. Pierre
What's the use case you imagine where the user would want to choose from

a

Post by Jasper St. Pierre
list of IRC clients, without the list actually able to launch the IRC

client

Post by Jasper St. Pierre
in question with a specific server/channel?

We've been through this.

Post by Jasper St. Pierre
It seems quite backwards to have a way to say "this app supports this
API/protocol" with the app actually not being able to support that
API/protocol. If the app wants to announce itself as an IRC client, it

needs

Post by Jasper St. Pierre
to handle the "I support IRC protocol". Yes, that could mean something
different from irc: URIs, but if Quassel doesn't support IRC URIs, what
makes you think it will gain support for your protocol, or why your

protocol

Post by Jasper St. Pierre
is better than IRC URIs?

Please do not make assumptions about an app's command line interface.
A web browser can be a web browser without ever accepting http uris as
argument. IM clients themselves are much, much less likely to accept
protocol URIs, especially since some of the protocols they support
simply don't have special URIs, and just because xmpp does doesn't
mean that it makes sense to accept it as a URI.
Furthermore I have no idea what you mean by "gaining support for my
protocol". You are conflating protocols and URIs.
J. Leclanche

Post by Jasper St. Pierre

Post by Jerome Leclanche
On Tue, Jan 7, 2014 at 3:24 PM, Dominique Michel

Post by Dominique Michel
Le Mon, 6 Jan 2014 15:38:34 +0000,

Post by Jerome Leclanche

Post by Bastien Nocera

Post by David Faure

Post by Bastien Nocera

Post by David Faure

Post by Bastien Nocera
And it's more about services (allow me to pick a photo, or
select a contact) than about full-fledged applications. A
terminal emulator can hardly be thought as providing a
service to other applications, a photo picker provided by
the native photo application would.

My point is that both needs (i.e. use cases) exist.
I know that "intents" and the use of dbus interfaces is about
what you describe.
I'm simply pointing out that the other use case (merely
starting apps, at most with a url on the command line) exists
too, and that I'd like to see a standard solution for it.

The URL would/should have a mime-type associated to it, so you
can just lookup by mime-type.

"at most" means "sometimes none".
There's no URL and no mimetype involved when listing or starting
- window managers
- terminal emulators

Those would be covered by the Implements changes documented by
https://bugs.freedesktop.org/show_bug.cgi?id=73317

Post by David Faure
- instant messaging apps

xmpp, and irc schemes at least, so those are covered by
x-scheme-handler/*

Post by David Faure
- email clients

mailto scheme

All these are not safe assumptions. Quassel, for example, does not
support irc: uris.

Is it not the job of an application, or package manager, to
provide the right mimes type for the application?
If that mime type does not exist, it must be added.
Dominique

Post by Jerome Leclanche
J. Leclanche
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

The association is irrelevant. Quassel does not support being given
irc uris. You're welcome to write a patch for every broken app,
though.
J. Leclanche
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

--
Jasper

[Jasper St. Pierre]

Post by David Faure
Not really, it's useful but orthogonal.
To let users choose their preferred webbrowser, terminal emulator, WM, and
mail app, all we need is an interface "name" like WebBrowser,
TerminalEmulator, WindowManager, Mail, InstantMessenger, without any relation
to DBus.
E.g. some users might want firefox as their default webbrowser, xterm as their
terminal emulator, twm (ok just joking), skype and thunderbird...
Your suggested spec change seems to suggest that it's ok for an interface not
to be related to DBus, but the way it's worded, I think we'll soon have dbus
interfaces for all these, which excludes apps that don't implement these
interfaces.
There are two different use cases, one about "letting the user choose a type
of application and use that from other apps, with a simple Exec line"
and one about "letting the user choose a type of application to provide a
certain service over dbus".
For the first one, maybe Categories are enough? I didn't check if they work
100% for these use cases above.
For sure we're missing desktop files for windowmanagers :)

When would the user ever be required to pick a default window manager? Why
would a system ever want to enumerate the available window managers?

Also, I don't think "default IM client" is a reasonable thing. There's
rarely a standard interface for IM clients, much less a standard protocol.
What would the "default IM client" allow the user to do?

I want to make sure we're not designing for use cases that don't exist
here, and that we keep thinking about the user experience.

Post by David Faure
--
Working on KDE, in particular KDE Frameworks 5
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[David Faure]

Post by Jasper St. Pierre

Post by David Faure
Not really, it's useful but orthogonal.
To let users choose their preferred webbrowser, terminal emulator, WM, and
mail app, all we need is an interface "name" like WebBrowser,
TerminalEmulator, WindowManager, Mail, InstantMessenger, without any relation
to DBus.
E.g. some users might want firefox as their default webbrowser, xterm as their
terminal emulator, twm (ok just joking), skype and thunderbird...
Your suggested spec change seems to suggest that it's ok for an interface not
to be related to DBus, but the way it's worded, I think we'll soon have dbus
interfaces for all these, which excludes apps that don't implement these
interfaces.
There are two different use cases, one about "letting the user choose a type
of application and use that from other apps, with a simple Exec line"
and one about "letting the user choose a type of application to provide a
certain service over dbus".
For the first one, maybe Categories are enough? I didn't check if they work
100% for these use cases above.
For sure we're missing desktop files for windowmanagers :)

When would the user ever be required to pick a default window manager? Why
would a system ever want to enumerate the available window managers?

I didn't make it up:
Loading Image...

The choice made there is used on next login.

Post by Jasper St. Pierre
Also, I don't think "default IM client" is a reasonable thing. There's
rarely a standard interface for IM clients, much less a standard protocol.
What would the "default IM client" allow the user to do?

OK I was wrong, we have that one to choose between implementers of a
particular DBus interface. So that one should become
Implements=org.kde.InstantMessenger, until/unless a DBus interface is
standardized (I have no clue).

[Kevin Krammer]

Post by Ryan Lortie
hi,

Post by Jerome Leclanche
Problem #1
Apps cannot enumerate other apps of a specific type. A couple of

It is my "intent" (ha...) to raise for a while that I want to introduce
a new key to desktop files called "Implements". There is already some
https://bugzilla.gnome.org/show_bug.cgi?id=712391
In terms of the desktop entry spec, such an addition would be extremely
simple: we have a new 'string list' key called "Implements" with no
particular meaning except that each entry in the list is expected to be
in D-Bus interface name style.
This would solve your "enumerate apps of a specific type" assuming that
you have someone willing to specify, concretely, what it means to be a
given type of application. Taking your 'terminal emulator' example from
another part of this mail, we could have an
org.freedesktop.TerminalEmulator interface (that may not be an actual
D-Bus interface) that specifies what you must do if you're a terminal
emulator and what you can expect a terminal emulator to do if you find
its desktop file via a lookup on
"Implements=org.freedesktop.TerminalEmulator".
*Often* this will imply that an application implements said interface on
the same object path as the org.freedesktop.Application interface, but
this is not a hard requirement. I suspect it would be a recommendation,
though.

Wouldn't it make more sense to be able to derive the object path from the
name?
This way an application which has multiple interfaces can implement them with
different objects but could opt to just register the same object for multiple
paths.

Having a fixed path makes the second case easier but the first hard or
impossible.

Cheers,
Kevin

[Ryan Lortie]

hi,

Post by Kevin Krammer
Wouldn't it make more sense to be able to derive the object path from the
name?
This way an application which has multiple interfaces can implement them with
different objects but could opt to just register the same object for multiple
paths.
Having a fixed path makes the second case easier but the first hard or
impossible.

This isn't really how D-Bus works. You can register multiple interfaces
at the same object path independently of each other.

Cheers

[Kevin Krammer]

Hi,

Post by Ryan Lortie
hi,

Post by Kevin Krammer
Wouldn't it make more sense to be able to derive the object path from the
name?
This way an application which has multiple interfaces can implement them with
different objects but could opt to just register the same object for multiple
paths.
Having a fixed path makes the second case easier but the first hard or
impossible.

This isn't really how D-Bus works. You can register multiple interfaces
at the same object path independently of each other.

I know, sorry for the misunderstanding, let me try to rephrase:

at least in the object oriented languages which have D-Bus bindings, it is
common to have a single object instance per D-Bus object path.
Such an object can, of course, implement multiple interfaces.

If the intents specification declares that there is only a single object path
for intents interfaces, then this is limiting the developer to exactly that
choice (or using a mediator object the demultiplexes, i.e. a lot more work).

If the specification has one path per interface, then developers can easily
still have one object for all paths/interfaces, but also one object per
path/interface.

Cheers,
Kevin

[Kevin Krammer]

Post by Jerome Leclanche
There's a lot TBD still. For example: Do we require apps implementing
an intent to support every method of the intent? I don't think it's
necessary due to dbus introspection letting us figure out whether a
method is supported.

If an intent has an associated D-Bus interface, then IMHO all methods should
be available.

E.g. if I am a contact editor and have an optional feature to take a contact
picture from the camera, then I would check the intents cache for
xdg.intents.Camera.
If I find one (or the preferred one if there are more than on) I expect a call
to xdg.intents.Camera.TakePicture to be available.

I don't want to have to start each camera provider to do runtime
introspection.

Cheers,
Kevin

[Jerome Leclanche]

Post by Kevin Krammer

Post by Jerome Leclanche
There's a lot TBD still. For example: Do we require apps implementing
an intent to support every method of the intent? I don't think it's
necessary due to dbus introspection letting us figure out whether a
method is supported.

If an intent has an associated D-Bus interface, then IMHO all methods should
be available.
E.g. if I am a contact editor and have an optional feature to take a contact
picture from the camera, then I would check the intents cache for
xdg.intents.Camera.
If I find one (or the preferred one if there are more than on) I expect a call
to xdg.intents.Camera.TakePicture to be available.
I don't want to have to start each camera provider to do runtime
introspection.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

You run the risk anyway though, as a new method might be officially
added later on to the intent (especially with non-freedesktop
namespaced intents).

J. Leclanche

[Kevin Krammer]

Post by Jerome Leclanche

Post by Kevin Krammer

Post by Jerome Leclanche
There's a lot TBD still. For example: Do we require apps implementing
an intent to support every method of the intent? I don't think it's
necessary due to dbus introspection letting us figure out whether a
method is supported.

If an intent has an associated D-Bus interface, then IMHO all methods
should be available.
E.g. if I am a contact editor and have an optional feature to take a
contact picture from the camera, then I would check the intents cache for
xdg.intents.Camera.
If I find one (or the preferred one if there are more than on) I expect a
call to xdg.intents.Camera.TakePicture to be available.
I don't want to have to start each camera provider to do runtime
introspection.
Cheers,
Kevin
--
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

You run the risk anyway though, as a new method might be officially
added later on to the intent (especially with non-freedesktop
namespaced intents).

Quoting Bastien Nocera: "D-Bus-style name. This allows namespacing and
versioning."

I mean, what is an intent good for if a service can claim to provide it but
actually not do it?

Cheers,
Kevin

[Simon McVittie]

Post by Jerome Leclanche
There's a lot TBD still. For example: Do we require apps implementing
an intent to support every method of the intent? I don't think it's
necessary due to dbus introspection letting us figure out whether a
method is supported.

With my D-Bus maintainer hat on:

D-Bus introspection (o.fd.DBus.Introspectable.Introspect) is a
debugging, development and (occasionally) code-generation tool, and
should not be used in "production" code[1]. It is not a
capability-discovery mechanism.

For instance, Telepathy connections' introspection XML lists every
method for which they have C code; but on a connection to a particular
server, it's common to have methods that don't work and never will, due
to the limitations of this particular server. For instance, you can
block offensive contacts via proprietary messages to Google's XMPP
servers, but you can't block contacts on a minimal XMPP server with no
extensions; so on Google XMPP servers, the BlockContacts method can
work, but on minimal XMPP servers, it will just fail.

If you want to discover capabilities ("I can do this and this but not
this") over D-Bus, you should use a simpler mechanism that doesn't
involve parsing XML, and does allow saying "I have code for this method
but it doesn't work on this object". A property whose value is an
integer representing a bitfield, or a property whose value is a list of
strings, are better representations. Remember to define (in your D-Bus
API) whether that property can change within an object's lifetime, and
if so, how the change is signalled.

For instance, Telepathy typically uses properties named "Interfaces"
containing a string array (a list of interfaces that work), and a
property per interface named "SomethingFlags" to describe the features
of that interface that will work here.

Regards,
S

[1] Yes, I know I maintain dbus-python, which does (ab)use introspection
for some of its functionality. It's constrained to do so by backwards
compatibility, and I consider it to be a design flaw that it does this.
"Do as I say, not as I do" :-)

[Jerome Leclanche]

On Mon, Jan 6, 2014 at 1:25 AM, Jerome Leclanche

Post by Jerome Leclanche
Problem #1
Apps cannot enumerate other apps of a specific type. A couple of
- A system settings app wants to know about every window manager,
terminal emulator, ... so it can show them in a dropdown to the user.
- An email client wants to open a contact manager.
- A volume control wants to open a volume mixer.
There is groundwork to solve this problem with Categories. What's
missing is a category cache, and more categories.
GNOME uses X-GNOME-Provides for windowmanager and panel. This is
something that could be solved with these changes, imo.
PCMan wrote a patch to desktop-file-utils to generate a [Category
Cache] in mimeinfo.cache. I will talk later in this email about the
mimeinfo.cache file.
https://github.com/PCMan/desktop-file-utils/commit/9d543f9090b96854606e70bc1f43b1bc98132c9e
Problem #2
Apps cannot set a default app of a specific category. Eg "default
terminal emulator", "default window manager". This is an evolution of
problem #1, as those same system settings apps would want to actually
set the default app.
defaults.list (or was it mimeapps.list now?) can be reused for this.
[Default Applications Category]
TerminalEmulator=qterminal.desktop

I'd like to ping the list again on these two specific problems as I'm
currently working on these.

J. Leclanche

[Dominique Michel]

Le Tue, 7 Jan 2014 21:09:41 +0000,

Post by Jerome Leclanche
On Mon, Jan 6, 2014 at 1:25 AM, Jerome Leclanche

Post by Jerome Leclanche
Problem #2
Apps cannot set a default app of a specific category. Eg "default
terminal emulator", "default window manager". This is an evolution
of problem #1, as those same system settings apps would want to
actually set the default app.
defaults.list (or was it mimeapps.list now?) can be reused for this.
[Default Applications Category]
TerminalEmulator=qterminal.desktop

It is another issue with the terminal emulators, some use -e to launch
applications, other use -x, and I am not convinced the wrapper glue
they done in Debian recently around gnome-terminal and
x-terminal-emulator (Debian terminal), instead of fixing
this at the application level, will solve all the cases. In fact, I
just find it work for me at the console, but fail fvwm-crystal menu,
which is very strange because I used the same command in both cases. But
I didn't get the time to look further into it, so I have no certitude at
that time.

Post by Jerome Leclanche
I'd like to ping the list again on these two specific problems as I'm
currently working on these.
J. Leclanche
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Simon McVittie]

Post by Dominique Michel
It is another issue with the terminal emulators, some use -e to launch
applications, other use -x, and I am not convinced the wrapper glue
they done in Debian recently around gnome-terminal and
x-terminal-emulator (Debian terminal), instead of fixing
this at the application level, will solve all the cases.

What you need here is to define a protocol (or an API, if you prefer
that term): as you point out, just saying "use this executable" is
insufficient, unless all available implementations have some sort of
protocol in common. That protocol can be a D-Bus interface, or a
particular set of command-line options, or whatever, but it must exist.

In Debian, the protocol that was defined for terminal emulators includes
"alternatives for x-terminal-emulator must support a subset of xterm
arguments, including -e". gnome-terminal does not actually implement
that protocol (gnome-terminal -e has the same general purpose but
different semantics), so gnome-terminal cannot be used directly as an
implementation of the x-terminal-emulator protocol. GNOME on Debian uses
gnome-terminal.wrapper, a Perl script which translates command-line
arguments and execs gnome-terminal, as its implementation of that protocol.

GNOME in Debian also needed its defaults to be changed, to not assume
that terminal implementations were command-line-compatible with
gnome-terminal (because x-terminal-emulator isn't).

When associating files with applications, one common protocol is "you
append the files as arguments on the application's command-line, one
argument per file". It's so common that people don't necessarily think
of it as a protocol at all, but you can't have interoperability without
agreeing on a protocol of some sort.

S

[Dominique Michel]

Le Wed, 08 Jan 2014 14:11:04 +0000,

Post by Simon McVittie

Post by Dominique Michel
It is another issue with the terminal emulators, some use -e to
launch applications, other use -x, and I am not convinced the
wrapper glue they done in Debian recently around gnome-terminal and
x-terminal-emulator (Debian terminal), instead of fixing
this at the application level, will solve all the cases.

What you need here is to define a protocol (or an API, if you prefer
that term): as you point out, just saying "use this executable" is
insufficient, unless all available implementations have some sort of
protocol in common. That protocol can be a D-Bus interface, or a
particular set of command-line options, or whatever, but it must exist.

In Crystal, a function test a variable which represent the terminal
in use, and call that term with the appropriate command-line options.
Some time ago, fvwm introduced internal variables that can be used
instead of environmental variables, and I used a script to move some
of the preferences to that new kind of fvwm variables. I just find this
messed up that function (the available tests are unfortunately not the
same with these 2 kinds of variables, and I missed this one), so this is
a regression into fvwm-crystal, and not a problem with gnome-terminal
or x-terminal-emulator. I am in the way to fix it.

Best,
Dominique

[Dominique Michel]

Le Wed, 08 Jan 2014 14:11:04 +0000,

Post by Simon McVittie
GNOME in Debian also needed its defaults to be changed, to not assume
that terminal implementations were command-line-compatible with
gnome-terminal (because x-terminal-emulator isn't).
When associating files with applications, one common protocol is "you
append the files as arguments on the application's command-line, one
argument per file". It's so common that people don't necessarily think
of it as a protocol at all, but you can't have interoperability
without agreeing on a protocol of some sort.

For me, that mess is not over. According to xterm man page,

xterm -e mc /home/dom

should work. As a bonus, even it is not into the man page

xterm -e "mc /home/dom"

work too.

With gnome-terminal, both calls are working, but with terminator,
xfce4-terminal and x-terminal-emulator, only

terminator -e "mc /home/dom"

works. But with urxvt, only

urxvt -e mc /home/dom

works. That imply that mess is not over, even if I was able to commit a
fix for fvwm-crystal. In fact, this is worst than before because I now
need to deal with that in 2 functions instead of 1.

I agree with you that a protocol is the way to get interoperability, but
if upstream is not following it, we don't get it. In that case, xterm
is the reference and its man page is clear, we don't need "" after -e.

Best,
Dominique

[Jerome Leclanche]

A TerminalEmulator intent could very well support a *standardized* api
that does something similar to -e.
J. Leclanche


On Wed, Jan 8, 2014 at 6:15 PM, Dominique Michel

Post by Dominique Michel
Le Wed, 08 Jan 2014 14:11:04 +0000,

Post by Simon McVittie
GNOME in Debian also needed its defaults to be changed, to not assume
that terminal implementations were command-line-compatible with
gnome-terminal (because x-terminal-emulator isn't).
When associating files with applications, one common protocol is "you
append the files as arguments on the application's command-line, one
argument per file". It's so common that people don't necessarily think
of it as a protocol at all, but you can't have interoperability
without agreeing on a protocol of some sort.

For me, that mess is not over. According to xterm man page,
xterm -e mc /home/dom
should work. As a bonus, even it is not into the man page
xterm -e "mc /home/dom"
work too.
With gnome-terminal, both calls are working, but with terminator,
xfce4-terminal and x-terminal-emulator, only
terminator -e "mc /home/dom"
works. But with urxvt, only
urxvt -e mc /home/dom
works. That imply that mess is not over, even if I was able to commit a
fix for fvwm-crystal. In fact, this is worst than before because I now
need to deal with that in 2 functions instead of 1.
I agree with you that a protocol is the way to get interoperability, but
if upstream is not following it, we don't get it. In that case, xterm
is the reference and its man page is clear, we don't need "" after -e.
Best,
Dominique
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Simon McVittie]

Post by Dominique Michel
I agree with you that a protocol is the way to get interoperability, but
if upstream is not following it, we don't get it. In that case, xterm
is the reference and its man page is clear, we don't need "" after -e.

(If you haven't already, I suggest reading about the distinction between
shell argument parsing and exec()/posix_spawn()-style argument passing,
and why the former often leads to security flaws, before going further
with this line of thinking.)

More precisely, the API specified in Debian is documented in
<http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.8.3>.
It isn't completely clear from that description whether treating a
single argument as a one-line shell script (which appears to be what
you're trying to do) like this

x-terminal-emulator -e "echo here is arbitrary shell; read"

is expected to work (it does in xterm, but http://bugs.debian.org/648271
suggests that this is not required for an arbitrary
x-terminal-emulator). It does imply that this

x-terminal-emulator -e vi /etc/hostname

is expected to work (and the Policy bug clarifies that that is the
intention).

Please note that even within Debian, that policy says nothing about
whether the underlying executable for any given terminal emulator has
"xterm -e" semantics. *All alternatives for x-terminal-emulator* must
have "xterm -e" semantics. That does *not* mean that running

/usr/bin/konsole -e vi /etc/hostname

must work; it only means that running

/usr/bin/x-terminal-emulator -e vi /etc/hostname

must work. A non-xterm terminal emulator is free to either have those
semantics for -e and register itself as an x-terminal-emulator
implementation (as xterm does); install a wrapper script which does, and
register *that* as its x-terminal-emulator implementation (as
gnome-terminal does); or not implement x-terminal-emulator at all.

If an x-terminal-emulator implementation in Debian does not have those
semantics, please open a Debian bug, quoting a command starting with
"/usr/bin/x-terminal-emulator" that didn't work as you expected with
that implementation.

If you want to define a terminal emulator API that is
non-Debian-specific, in practice you're going to have to cope with
terminal emulators that either implement it via some sort of wrapper or
script because their own command-line parsing not compatible, or don't
implement it at all.

S

[Dominique Michel]

Le Wed, 08 Jan 2014 18:52:32 +0000,

Post by Simon McVittie

Post by Dominique Michel
I agree with you that a protocol is the way to get
interoperability, but if upstream is not following it, we don't get
it. In that case, xterm is the reference and its man page is clear,
we don't need "" after -e.

(If you haven't already, I suggest reading about the distinction
between shell argument parsing and exec()/posix_spawn()-style
argument passing, and why the former often leads to security flaws,
before going further with this line of thinking.)

It can be a good reason why fvwm add an exec call in the fvwm-crystal
function I was talking about.

Post by Simon McVittie
More precisely, the API specified in Debian is documented in
<http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.8.3>.
It isn't completely clear from that description whether treating a
single argument as a one-line shell script (which appears to be what
you're trying to do) like this
x-terminal-emulator -e "echo here is arbitrary shell; read"

No, that's not. I was talking about using

x-terminal-emulator -e mc /home/dom

and quoting the command for terminals that doesn't support xterm -e
syntax.

Post by Simon McVittie
is expected to work (it does in xterm, but
http://bugs.debian.org/648271 suggests that this is not required for
an arbitrary x-terminal-emulator). It does imply that this
x-terminal-emulator -e vi /etc/hostname
is expected to work (and the Policy bug clarifies that that is the
intention).
Please note that even within Debian, that policy says nothing about
whether the underlying executable for any given terminal emulator has
"xterm -e" semantics. *All alternatives for x-terminal-emulator* must
have "xterm -e" semantics. That does *not* mean that running
/usr/bin/konsole -e vi /etc/hostname
must work; it only means that running
/usr/bin/x-terminal-emulator -e vi /etc/hostname
must work. A non-xterm terminal emulator is free to either have those
semantics for -e and register itself as an x-terminal-emulator
implementation (as xterm does); install a wrapper script which does,
and register *that* as its x-terminal-emulator implementation (as
gnome-terminal does); or not implement x-terminal-emulator at all.
If an x-terminal-emulator implementation in Debian does not have those
semantics, please open a Debian bug, quoting a command starting with
"/usr/bin/x-terminal-emulator" that didn't work as you expected with
that implementation.

I will do it for terminator. How can I find if another term provide or
not a x-terminal-emulator?

Dominique

Post by Simon McVittie
If you want to define a terminal emulator API that is
non-Debian-specific, in practice you're going to have to cope with
terminal emulators that either implement it via some sort of wrapper
or script because their own command-line parsing not compatible, or
don't implement it at all.
S
_______________________________________________
xdg mailing list
http://lists.freedesktop.org/mailman/listinfo/xdg

[Dominique Michel]

Le Wed, 8 Jan 2014 22:45:41 +0100,

Post by Dominique Michel
I will do it for terminator. How can I find if another term provide or
not a x-terminal-emulator?

Never mind, I find it.