Re: Detecting appstream scheme support ; end-user-oriented "About AppStream" page (was: Re: Add "Install via AppStream" links to applications on kde.org)
- Date: Mon, 19 Dec 2016 03:38:54 +0100
- From: "Friedrich W. H. Kossebau" <kossebau@xxxxxxx>
- Subject: Re: Detecting appstream scheme support ; end-user-oriented "About AppStream" page (was: Re: Add "Install via AppStream" links to applications on kde.org)
Moving to kde-devel for more input by app developers:
For the current testing entry with an appstream: url on KDE pages see the
right box on https://www.kde.org/applications/utilities/okteta/
But it is unclear if "AppStream" works here with most end-users. Please read
on below and then give your comments/2 cents :)
Am Montag, 19. Dezember 2016, 01:30:39 CET schrieb Matthias Klumpp:
> 2016-12-19 1:00 GMT+01:00 Friedrich W. H. Kossebau <kossebau@xxxxxxx>:
> > Am Sonntag, 18. Dezember 2016, 22:50:23 CET schrieb Albert Astals Cid:
> >> El dissabte, 17 de desembre de 2016, a les 0:17:22 CET, Friedrich W. H.
> >> Kossebau va escriure:
> >> Is it possible to detect if the browser has a handler for the appstream:
> >> scheme and if not don't show the link at all?
> > At least from a quick search there is no simple querying of the supported
> > protocols possible. Only saw hacks of the kind which made me try to stay
> > out of web development.
> > I would agree only showing the link active in browsers where the protocol
> > works would be nicer. I can just tell myself e.g. irc:// urls in the same
> > box also have a similar fate.
> I am actually rather happy about that, the less information a browser
> exposes to the webpage by default, the harder it gets to use the
> information for tracking or to detect vulnerable systems.
> > @Matthias & Co: What other web pages/sites are already making use of such
> > appstream links? How do they handle it?
> So far I've only seen very few, mainly on Wiki pages or private pages
> at GNOME. All of them show these links unconditionally.
> What you could do is detect whether the user is running Linux and if
> not, hide the link. As of no, there is no Windows client consuming
> this data that I know of.
> > That left aside, most people surely still have no clue what "AppStream"
> > is.
> > So it could make sense to have a small note mark to the right of the
> > appstream:id link for the "What the heck is Appstream" use-case, so people
> > could click/tap the button and learn about AppStream (or already learn a
> > little in a tooltip, though a separate note mark still is needed for
> > discovery and touch UI browsing).
> About that: I wonder whether it would actually make more sense to show
> a link like "Open in Software Center" or "Open in KDE Discover" or
> anything more descriptive... AppStream is a rather technical term, and
> if users need to read a page to know what it does, the links are less
The issue here is that we do not know what handler is invoked by the
appstream: scheme. Only the browser knows. If lucky, it perhaps might be nice
enough to show some information on cursor hovering (at least in a mouse-driven
UI, no idea how touch UI can preview info about url handling on linked
Given the variety of names of the software installation managers on all the
systems, I fear there is no generic enough name, which might not result again
in people also thinking "Does not work for me" or wrongly thinking "Works for
IMHO the distro-agnostic appstream thing is an implementation detail and
concept which can/should _not_ be hidden from the user here in the case of the
distro-agnostic app pages. That would be trying to make things more simple
than they are, and this will only result in more than less confusion.
So similar like flatpak or snap this is a concept which needs to be understood
by those people who want to become independent of what is only available
inside their distro's software manager. They have to know this is an appstream
link to know if it is working for them (like they will have to know if flatpak
or snaps work for them).
Everyone else, who is not smart enough to learn about appstream links, should
not try to install something from the internet anyway, unless they also fancy
shooting their parts of their own body ;)
So IMHO the motivation for putting the name "AppStream" on the button images
https://www.freedesktop.org/software/appstream/docs/sect-AppStream-Services-UrlHandler.html was correct, "AppStream" is a term/concept to be used here.
> > @Matthias: is there some distro-agnostic end-user website/page this "About
> > AppStream" symbol could link to?
> > Only found
> > https://www.freedesktop.org/software/appstream/docs/chap-AppStream-About.
> > html but that is not really consumable by Sue and Joe -No-Code-Please-
> > User.
> We could make one...
> https://www.freedesktop.org/wiki/Distributions/AppStream/ exists, but
> since AppStream is a rather technical project, I don't think we even
> should attempt to explain it for users who will never see the metadata
> (what is metadata anyway? - we'd even need to explain that first).
> IMHO some short explanation maybe in form of a small "what is this?"
> info on the webpage or a tooltip which shows something like "Open the
> page of this application in the software center of your operating
> system" would be much more useful. And since at time *every* software
> center on Linux, including the one on Ubuntu, uses AppStream metadata
> and appstream-IDs, we can simplify and generalize a lot :-)
Ah, what I meant was an explanation for just the appstream: link and what it
is used for: that it is a distro-agnostic way to activate the software manager
of one's operating system to try to install a version of that very software if
available from a location trusted/used by that very software manager, by the
means of that unique identifier for the software as used in the url.
No mentioning of any other metadata stuff, just this. I would assume a person
who already learned what a link is should be able to get this.
This discussion makes me wonder if such links should not be having a different
separate (marketing) name. That would allow to promote the concept of such
links completely separate from the implementation detail of the distro-
agnostic appstream metadata and all the other stuff it allows inside the world
of software managers.
So to summarize:
Given this very use-case:
Us upstream (source-code developers) wants to point the end-users to packages
of our software provided by downstream (distributions). Either because
upstream cannot provide such packages themselves or because the end-user only
trusts their distribution.
This needs to be doable in a distro-agnostic way. Also does it need to be
processable by software, so end-users do not have to retype something and know
where to retype this exactly.
(So this is not about e.g. software manager internal communication, e.g. with
web pages for the UI which talk back to the core by urls.)
An url seems a good approach, with a dedicated scheme and the generic, distro-
agnostic app identifier being encoded in the rest of the url, with the address
space being inside the world of the respective software manager handling this.
Such urls would work in web pages, but also other places like documentation or
text-based communication (email, chat).
The appstream: urls are an existing scheme here and already supported by some
software manager apps (which also install handlers for the scheme into the
Disadvantage of the term "Appstream" is that is also refers to the app
metadata system in general, so end-users/developers searching for explanations
will only be confused and useless discussions held (cmp. e.g. existing
wikipedia page or similar docs about "AppStream").
Also might it be not too descriptive for the given use-case, and Amazon
occupying the term for something different but slightly related adds to the
Thus a new dedicated name, both used in the url scheme and for marketing such
urls, might be good. As user-facing appstream: urls have not yet appeared a
lot in public places, there is still time for starting with a new specially
AppStream metadata then would just be the implementation detail for this,
providing one way to define the id that should be used by the software manager
for resolving any incoming app urls as discussed here.
Same like telephone uri, email uri, or geouri just point to an id, whose
metadata is then resolved by the system processing the uri.
If we could rule the scheme world, this would be best, by example of Okteta:
It would perhaps even allow to use path?query#fragment for specifying a
version and even action intends, e.g.
which could be used in release announcements to allow users to query their
software managers by a simple mouse click if the new version is already
available from the trusted/registered package stores.
Having such a separate non-appstream url should only need minimal adaption
with the software manager apps, they only will need to also support the new
So what name to use? Ideally both the scheme and the technology should have
the same name, so there is not a lot to know. Something based on english terms
might help as well.
It would need to be cross-desktop, cross-platform, cross-license.
"app", "appid", "application" come to mind, but conflict with schemes in use
or terms otherwise occupied.
Global App id, universal app id, ... too tired now to pass some good proposals
here, will do in a later post.
Meanwhile... What do you think?