[Github-comments] [geany/geany] Add appdata file and make it known to Makefile.am (#1142)

Wed Jul 20 14:00:33 UTC 2016

> Related: https://sourceforge.net/p/geany/feature-requests/739/

@codebrainz  Ah! thanks, I knew we already had something like that, just couldn't seem to find it.

> The appdata file as contributed here will likely make its way through openSUSE (because I already submitted there), so it will get some testing thereafter. Would you prefer to wait for that? The only testing so far is on my local system, where this has been seen to work so far.

Well, I'm less interested on whether it's working than whether it's useful.  We could ship something specific for Atari distributions, but I hardly think it'd be of any use :)  Ok that's unfair, but you get the point: even if it's a current technology, if it isn't done in a way that make it useful there's no point.  And as I have zero knowledge about that -- and that the specs you all linked are clunky -- I hardly have any way to really say.

> FYI, fedora ships a hand-crafted file in their .spec file:
>
> http://pkgs.fedoraproject.org/cgit/rpms/geany.git/tree/geany.spec#n129

That's interesting to know, thanks.  Looking at it it doesn't look too different from what this PR shows, which is probably good.

> release and provides tags are listed as 'suggested', not required (not even in the recommended list):

Well, this specification is very inconsistent.  Indeed in some places it shows example of not using them, but https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#spec-component-filespec clearly states that *"The XML for a generic component definition starts with an `<component>` tag as root element. The `<component>` element must at least have an `id`, `name` and `releases` tag, a `provides` tag with appropriate children is highly recommended.*".  So it's hard to know what to believe.

> It might be a bit concerning then that downstream packagers would likely be shipping their own versions of "unblessed" appstream files for geany (like Fedora does, openSUSE might follow suit) which may carry out-of-date or plain wrong info in some cases.

Just like would the same file here if we don't update it.  And updating it means we know how, and don't forget about it.  It's more likely someone knowing why they want that file remember to update it together with a new version of the software.

> > As I said in a previous post, its ok to provide a set of default xml tags for distros to use, but without the distro specific parts we shouldn't install it when Geany is built and installed from tarball or git. After all a user who has just done that, isn't going to need the application description.
>
> She could still use e.g. gnome-software to write a review, etc.

That doesn't make much sense to me, and @elextr point seem valid.  Where would that review go?  if it's into a distribution-specific repository, it has to match what the *distribution* provides, so there's no point in installing it from custom manual installations.  Same applies to which version it is for (that one could be addressed with a `<release>` info I guess).

---

> You might also have heard about snappy and flatpak - two methods currently worked on in producing 'bundled' applications. This can be 'on your own' infra or, more likely to happen, in a cross-distro appstore like setup ('store does not mean commercial here, allthough these options might be arising too).
>
> flatpak for sure is basing it's application presentation on the .appdata.xml files - snappy is likely to follow suite....
>
>Those cross-distro app-stores would give you even more power over reaching the users with updates at the time you want them to happen, no longer having to wish for goodwill from random distribution projects... having your leg-work done in preparation for this can only be beneficial for you.

Stop right here if you want to convince me or @elextr, we both have strong beefs against that Flatpack and Snappy craziness :)  One of my own being specifically that it removes downstream.  But that's not so much the subject here.

> Regarding your question about the screenshots: they are meant to only show your application. Of course you can have different window styling, depending on the desktop environment you run in, but this is by far not as important as being able to show ANYTHING to your user what they can expect. Of course a 'KDE Application' will likely be shown with upstream KDE styling, GNOME Apps with upstream GNOME Styling... you can present your app in a way that makes users want it.

That's not exactly what the [docs](https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html#qsr-app-contents) say: they seem to say "you should use the default theme" (and apparently that doesn't even include your distro's specific ones, as what looks like an Ubuntu screenshot to me is deemed *"BAD: Uses custom font, custom color theme"*).

> Distributors are there to help you GET the application to the user... convincing the user that YOUR project is the right one to use is your task

Well, actually not really.  We're not here to sell anything to anyone, we provide an application, and if people like it and want to use it, that's great.  If they don't, that's just as fine.  We aren't an ad company, and we have actually little to gain in having more users.  We just try to make a good application, and whatever happens from there is fine.

> Software Centers != Package Managers... Test GNOME Software and/or KDE Discover - they read also installed files in /usr/share/appdata; which is why it can be beneficial for make install to do it...

What is the use of those software centers if the application is installed? (and even more so, if the application was *manually* installed)  That's a genuine question.
I tried launching gnome-software on my Debian Unstable, and what I see is a very slow app (kinda unfair point I guess), and I can run installed apps (doesn't seem of much use to me to go through that to launch an app), write a review (see above), and the rest seem to be package management stuff.

One pro for adding the appdata file though might be *not* to be listed as a foreign, non-free app in there, as Geany currently is (probably through it's desktop file?).  Which though, is unfair from that gnome-software thing, but well.

> @elextr it needs to be part of the RPM at least at the moment it is being scanned by appstream-builder (and rpm means installed)

There is no need to install a file in our build system just so the packagers have it.  They can install it just fine on their own if they want, that's not ours to decide -- just like they can remove files from the package if they don't want them (think about `.la` if you think they don't).
If that's the only reason to install the appdata file, it would be what I feared before: doing things that don't improve our releases because we think we know better what downstream needs.

> Additionally, Software Centers use the local information to assess what is there (next to querying package managers, most notably through PackageKit at this moment).

I'd think at least gnome-software uses desktop files for that purpose too.  And it sounds hardly sensible to require metadata just to know whether the application is there or not (short of the `<provides>`, maybe).

However, as the *appdata* docs do say we should install it as an upstream, we probably should if we have it, and just not think too much of it.  It's not like it does more harm than wasting a few bytes on the user's drive.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1142#issuecomment-233957785
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20160720/f8e96d27/attachment.html>