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

[Dominique Michel]

Le Wed, 8 Jan 2014 22:45:41 +0100,
Dominique Michel  a écrit :

> 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.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Dominique Michel]

Le Wed, 08 Jan 2014 18:52:32 +,
Simon McVittie  a écrit :

> On 08/01/14 18:15, Dominique Michel wrote:
> > 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.

> 
> More precisely, the API specified in Debian is documented in
> .
> 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.

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

This is what I was referring to, sorry if it wasn't clear enough:
> 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

> 
> 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
> xdg@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Simon McVittie]

On 08/01/14 18:15, Dominique Michel wrote:
> 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
.
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

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

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

[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
 wrote:
> Le Wed, 08 Jan 2014 14:11:04 +,
> Simon McVittie  a écrit :
>
>
>>
>> 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
> xdg@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Dominique Michel]

Le Wed, 08 Jan 2014 14:11:04 +,
Simon McVittie  a écrit :


> 
> 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
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Dominique Michel]

Le Wed, 08 Jan 2014 14:11:04 +,
Simon McVittie  a écrit :

> On 08/01/14 14:03, Dominique Michel wrote:
> > 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
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Simon McVittie]

On 08/01/14 14:03, Dominique Michel wrote:
> 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

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

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

[Dominique Michel]

Le Tue, 7 Jan 2014 21:09:41 +,
Jerome Leclanche  a écrit :

> On Mon, Jan 6, 2014 at 1:25 AM, Jerome Leclanche
>  wrote:
> > 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

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.

> 
> 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
> xdg@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Jerome Leclanche]

On Mon, Jan 6, 2014 at 1:25 AM, Jerome Leclanche
 wrote:
> 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

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
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[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?


On Tue, Jan 7, 2014 at 11:51 AM, Jerome Leclanche  wrote:

> On Tue, Jan 7, 2014 at 4:00 PM, Jasper St. Pierre 
> wrote:
> > 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.
>
> >
> > 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
>
> >
> >
> > On Tue, Jan 7, 2014 at 10:34 AM, Jerome Leclanche 
> wrote:
> >>
> >> On Tue, Jan 7, 2014 at 3:24 PM, Dominique Michel
> >>  wrote:
> >> > Le Mon, 6 Jan 2014 15:38:34 +,
> >> > Jerome Leclanche  a écrit :
> >> >
> >> >> On Mon, Jan 6, 2014 at 1:56 PM, Bastien Nocera 
> >> >> wrote:
> >> >> > On Mon, 2014-01-06 at 14:48 +0100, David Faure wrote:
> >> >> >> On Monday 06 January 2014 14:44:27 Bastien Nocera wrote:
> >> >> >> > On Mon, 2014-01-06 at 14:35 +0100, David Faure wrote:
> >> >> >> > > On Monday 06 January 2014 14:28:01 Bastien Nocera wrote:
> >> >> >> > > > 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
> >> >> >
> >> >> >> - instant messaging apps
> >> >> >
> >> >> > xmpp, and irc schemes at least, so those are covered by
> >> >> > x-scheme-handler/*
> >> >> >
> >> >> >> - 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
> >> >>
> >> >> J. Leclanche
> >> >> 

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

[Jerome Leclanche]

On Tue, Jan 7, 2014 at 4:00 PM, Jasper St. Pierre  wrote:
> 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.

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

>
>
> On Tue, Jan 7, 2014 at 10:34 AM, Jerome Leclanche  wrote:
>>
>> On Tue, Jan 7, 2014 at 3:24 PM, Dominique Michel
>>  wrote:
>> > Le Mon, 6 Jan 2014 15:38:34 +,
>> > Jerome Leclanche  a écrit :
>> >
>> >> On Mon, Jan 6, 2014 at 1:56 PM, Bastien Nocera 
>> >> wrote:
>> >> > On Mon, 2014-01-06 at 14:48 +0100, David Faure wrote:
>> >> >> On Monday 06 January 2014 14:44:27 Bastien Nocera wrote:
>> >> >> > On Mon, 2014-01-06 at 14:35 +0100, David Faure wrote:
>> >> >> > > On Monday 06 January 2014 14:28:01 Bastien Nocera wrote:
>> >> >> > > > 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
>> >> >
>> >> >> - instant messaging apps
>> >> >
>> >> > xmpp, and irc schemes at least, so those are covered by
>> >> > x-scheme-handler/*
>> >> >
>> >> >> - 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
>> >>
>> >> J. Leclanche
>> >> ___
>> >> xdg mailing list
>> >> xdg@lists.freedesktop.org
>> >> http://lists.freedesktop.org/mailman/listinfo/xdg
>> > ___
>> > xdg mailing list
>> > xdg@lists.freedesktop.org
>> > 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
>> xdg@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/xdg
>
>
>
>
> --
>   Jasper
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[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?


On Tue, Jan 7, 2014 at 10:34 AM, Jerome Leclanche  wrote:

> On Tue, Jan 7, 2014 at 3:24 PM, Dominique Michel
>  wrote:
> > Le Mon, 6 Jan 2014 15:38:34 +,
> > Jerome Leclanche  a écrit :
> >
> >> On Mon, Jan 6, 2014 at 1:56 PM, Bastien Nocera 
> >> wrote:
> >> > On Mon, 2014-01-06 at 14:48 +0100, David Faure wrote:
> >> >> On Monday 06 January 2014 14:44:27 Bastien Nocera wrote:
> >> >> > On Mon, 2014-01-06 at 14:35 +0100, David Faure wrote:
> >> >> > > On Monday 06 January 2014 14:28:01 Bastien Nocera wrote:
> >> >> > > > 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
> >> >
> >> >> - instant messaging apps
> >> >
> >> > xmpp, and irc schemes at least, so those are covered by
> >> > x-scheme-handler/*
> >> >
> >> >> - 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
> >>
> >> J. Leclanche
> >> ___
> >> xdg mailing list
> >> xdg@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/xdg
> > ___
> > xdg mailing list
> > xdg@lists.freedesktop.org
> > 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
> xdg@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>



-- 
  Jasper
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Jerome Leclanche]

On Tue, Jan 7, 2014 at 3:24 PM, Dominique Michel
 wrote:
> Le Mon, 6 Jan 2014 15:38:34 +,
> Jerome Leclanche  a écrit :
>
>> On Mon, Jan 6, 2014 at 1:56 PM, Bastien Nocera 
>> wrote:
>> > On Mon, 2014-01-06 at 14:48 +0100, David Faure wrote:
>> >> On Monday 06 January 2014 14:44:27 Bastien Nocera wrote:
>> >> > On Mon, 2014-01-06 at 14:35 +0100, David Faure wrote:
>> >> > > On Monday 06 January 2014 14:28:01 Bastien Nocera wrote:
>> >> > > > 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
>> >
>> >> - instant messaging apps
>> >
>> > xmpp, and irc schemes at least, so those are covered by
>> > x-scheme-handler/*
>> >
>> >> - 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
>>
>> J. Leclanche
>> ___
>> xdg mailing list
>> xdg@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/xdg
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> 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
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Dominique Michel]

Le Mon, 6 Jan 2014 15:38:34 +,
Jerome Leclanche  a écrit :

> On Mon, Jan 6, 2014 at 1:56 PM, Bastien Nocera 
> wrote:
> > On Mon, 2014-01-06 at 14:48 +0100, David Faure wrote:
> >> On Monday 06 January 2014 14:44:27 Bastien Nocera wrote:
> >> > On Mon, 2014-01-06 at 14:35 +0100, David Faure wrote:
> >> > > On Monday 06 January 2014 14:28:01 Bastien Nocera wrote:
> >> > > > 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
> >
> >> - instant messaging apps
> >
> > xmpp, and irc schemes at least, so those are covered by
> > x-scheme-handler/*
> >
> >> - 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 
> 
> J. Leclanche
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Kevin Krammer]

Hi,

On Monday, 2014-01-06, 13:24:28, Ryan Lortie wrote:
> hi,
> 
> On Mon, Jan 6, 2014, at 10:31, Kevin Krammer wrote:
> > 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, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Ryan Lortie]

hi,

On Mon, Jan 6, 2014, at 10:31, Kevin Krammer wrote:
> 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
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Jasper St. Pierre]

On Mon, Jan 6, 2014 at 4:09 AM, David Faure  wrote:

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


> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE, in particular KDE Frameworks 5
>
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>



-- 
  Jasper
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[David Faure]

On Monday 06 January 2014 11:14:14 Jasper St. Pierre wrote:
> On Mon, Jan 6, 2014 at 4:09 AM, David Faure  wrote:
> > 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:
http://www.davidfaure.fr/2014/wm_chooser.jpeg

The choice made there is used on next login.

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

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

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

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

[Simon McVittie]

On 06/01/14 01:25, Jerome Leclanche wrote:
> 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" :-)

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

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

[Kevin Krammer]

On Monday, 2014-01-06, 15:37:33, Jerome Leclanche wrote:
> On Mon, Jan 6, 2014 at 3:29 PM, Kevin Krammer  wrote:
> > On Monday, 2014-01-06, 01:25:58, Jerome Leclanche wrote:
> >> 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
> > xdg@lists.freedesktop.org
> > 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

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Jerome Leclanche]

On Mon, Jan 6, 2014 at 3:29 PM, Kevin Krammer  wrote:
> On Monday, 2014-01-06, 01:25:58, Jerome Leclanche wrote:
>
>> 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
> xdg@lists.freedesktop.org
> 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
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Kevin Krammer]

On Monday, 2014-01-06, 01:25:58, Jerome Leclanche wrote:

> 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


signature.asc
Description: This is a digitally signed message part.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Jerome Leclanche]

On Mon, Jan 6, 2014 at 1:56 PM, Bastien Nocera  wrote:
> On Mon, 2014-01-06 at 14:48 +0100, David Faure wrote:
>> On Monday 06 January 2014 14:44:27 Bastien Nocera wrote:
>> > On Mon, 2014-01-06 at 14:35 +0100, David Faure wrote:
>> > > On Monday 06 January 2014 14:28:01 Bastien Nocera wrote:
>> > > > 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
>
>> - instant messaging apps
>
> xmpp, and irc schemes at least, so those are covered by
> x-scheme-handler/*
>
>> - email clients
>
> mailto scheme
>

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

J. Leclanche
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Kevin Krammer]

On Sunday, 2014-01-05, 21:42:47, Ryan Lortie wrote:
> hi,
> 
> On Sun, Jan 5, 2014, at 20:25, Jerome Leclanche wrote:
> > 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.

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

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring


signature.asc
Description: This is a digitally signed message part.
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Bastien Nocera]

On Mon, 2014-01-06 at 14:48 +0100, David Faure wrote:
> On Monday 06 January 2014 14:44:27 Bastien Nocera wrote:
> > On Mon, 2014-01-06 at 14:35 +0100, David Faure wrote:
> > > On Monday 06 January 2014 14:28:01 Bastien Nocera wrote:
> > > > 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

> - instant messaging apps

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

> - email clients

mailto scheme

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

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

[David Faure]

On Monday 06 January 2014 14:44:27 Bastien Nocera wrote:
> On Mon, 2014-01-06 at 14:35 +0100, David Faure wrote:
> > On Monday 06 January 2014 14:28:01 Bastien Nocera wrote:
> > > 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

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

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

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

[Bastien Nocera]

On Mon, 2014-01-06 at 14:35 +0100, David Faure wrote:
> On Monday 06 January 2014 14:28:01 Bastien Nocera wrote:
> > 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.

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

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

[David Faure]

On Monday 06 January 2014 14:28:01 Bastien Nocera wrote:
> 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.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

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

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

[Bastien Nocera]

On Mon, 2014-01-06 at 10:09 +0100, David Faure wrote:
> On Sunday 05 January 2014 21:42:47 Ryan Lortie wrote:
> > On Sun, Jan 5, 2014, at 20:25, Jerome Leclanche wrote:
> > > 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.
> 
> 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.

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

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

[David Faure]

On Sunday 05 January 2014 21:42:47 Ryan Lortie wrote:
> On Sun, Jan 5, 2014, at 20:25, Jerome Leclanche wrote:
> > 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.

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 :)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5

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

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

[Ryan Lortie]

hi,

On Sun, Jan 5, 2014, at 23:56, Jerome Leclanche wrote:
> 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
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Jerome Leclanche]

On Mon, Jan 6, 2014 at 4:48 AM, Ryan Lortie  wrote:
> hi,
>
> On Sun, Jan 5, 2014, at 23:11, Jerome Leclanche wrote:
>> 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.

>
> Cheers
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Ryan Lortie]

hi,

On Sun, Jan 5, 2014, at 23:11, Jerome Leclanche wrote:
> 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
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Jerome Leclanche]

On Mon, Jan 6, 2014 at 3:50 AM, Jasper St. Pierre  wrote:
> On Sun, Jan 5, 2014 at 9:52 PM, Jerome Leclanche  wrote:
>>
>> On Mon, Jan 6, 2014 at 2:42 AM, Ryan Lortie  wrote:
>> > 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
>> ___
>> xdg mailing list
>> xdg@lists.freedesktop.org
>> 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


On Mon, Jan 6, 2014 at 3:59 AM, Ryan Lortie  wrote:
> hi,
>
> On Sun, Jan 5, 2014, at 22:50, Jasper St. Pierre wrote:
>> 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.

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.

>
> 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
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Ryan Lortie]

hi,

On Sun, Jan 5, 2014, at 22:50, Jasper St. Pierre wrote:
> 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
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Jasper St. Pierre]

On Sun, Jan 5, 2014 at 9:52 PM, Jerome Leclanche  wrote:

> On Mon, Jan 6, 2014 at 2:42 AM, Ryan Lortie  wrote:
> > 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
> ___
> xdg mailing list
> xdg@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>



-- 
  Jasper
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Jerome Leclanche]

On Mon, Jan 6, 2014 at 2:42 AM, Ryan Lortie  wrote:
> hi,
>
> On Sun, Jan 5, 2014, at 20:25, Jerome Leclanche wrote:
>> 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

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
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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

[Ryan Lortie]

hi,

On Sun, Jan 5, 2014, at 20:25, Jerome Leclanche wrote:
> 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
___
xdg mailing list
xdg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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 d