More about "intents": Several improvements to desktop files and caches
Jasper St. Pierre
jstpierre at mecheye.net
Tue Jan 7 09:20:21 PST 2014
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 <adys.wh at gmail.com> wrote:
> On Tue, Jan 7, 2014 at 4:00 PM, Jasper St. Pierre <jstpierre at mecheye.net>
> 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 <adys.wh at gmail.com>
> wrote:
> >>
> >> On Tue, Jan 7, 2014 at 3:24 PM, Dominique Michel
> >> <dominique.michel at vtxnet.ch> wrote:
> >> > Le Mon, 6 Jan 2014 15:38:34 +0000,
> >> > Jerome Leclanche <adys.wh at gmail.com> a écrit :
> >> >
> >> >> On Mon, Jan 6, 2014 at 1:56 PM, Bastien Nocera <hadess at hadess.net>
> >> >> 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 at lists.freedesktop.org
> >> >> http://lists.freedesktop.org/mailman/listinfo/xdg
> >> > _______________________________________________
> >> > xdg mailing list
> >> > xdg at 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 at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/xdg
> >
> >
> >
> >
> > --
> > Jasper
>
--
Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20140107/09c9ff60/attachment-0001.html>
More information about the xdg
mailing list