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

[Jerome Leclanche]

On Mon, Jan 6, 2014 at 4:48 AM, Ryan Lortie <desrt at desrt.ca> 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