Hi.
I have a few concerns about AppData that don't seem to be covered elsewhere, or at least I haven't found the answers - not counting Richard's talk[1], as I gave up after five minutes, because I just couldn't get used to the accent ... sorry, I'm not native speaker, this was just too exhausting for me (plus I'm not exactly happy about having to spend time listening to 99% of sauce to get to 1% of information I'm interested in)
I've put those concerns onto the ticket[2] but the only answer I got was that it is wrong communication channel, so I'm copying it here:
1) Why not to take the information from the .desktop file by default and use appdata.xml only if the author/packager wants to provide additional information that cannot be in the .desktop file?
2) What is it good for to install appdata.xml into %{_datadir}/appdata/ when the installer (Apper, GNOME Software) takes the information from /usr/share/app-info/xmls so the files in /usr/share/appdata/ will lay on end-users' systems completely unused?
3) Almost the same goes for icons, if appstream-data will copy icons to /usr/share/app-info/icons, why to have two copies of the same image?
4) from http://people.freedesktop.org/~hughsient/appdata/
What happens if I don't ship this file?
The GNOME Software Center currently shows a nag message that the upstream project doesn't ship the additional data. Additionally, we will penalize apps that do not ship the extra metadata by showing them lower in the
search
results.
why do we penalize users by hiding contents from them when some upstream just doesn't care about this stuff? (see also comment 7 about the "unjust burden")?
5) If there is a trend to split localised information into separate langpacks, why to mix all locales into one file, not allowing any split?
Also, no localised screenshots allowed - "Screenshots should be taken with US English as the display language." - even if they could be tagged with language code too?
6) If we copy the screenshots, why not to provide them also in an optional package?
I've heard there are still some people who don't have Internet connection and install Fedora from DVD (do we still allow to install more packages from DVD after the initial install, right?) Or some may prefer not to get online just to browse the applications list ...
- TIA for the answers, K.
[1] https://www.youtube.com/watch?v=mSWIodEQMqo
[2] https://fedorahosted.org/fpc/ticket/414#comment:31
On 20 August 2014 14:42, Karel Volný kvolny@redhat.com wrote:
- Why not to take the information from the .desktop file by default and use
appdata.xml only if the author/packager wants to provide additional information that cannot be in the .desktop file?
That's what we do. Some data can't go in the .desktop file, as you can't put 5 localized screenshot URLs, with captions into an ini-style document without it looking crazy, and multi-paragraph text with lists is also as hard to do. You also might want different "names" for applications shown locally (e.g. "Web") than in the software center (e.g. "Epiphany"). This is why we read the values in the AppData file, and then fall back to the .desktop files.
- What is it good for to install appdata.xml into %{_datadir}/appdata/ when
the installer (Apper, GNOME Software) takes the information from /usr/share/app-info/xmls so the files in /usr/share/appdata/ will lay on end-users' systems completely unused?
This is for four reasons:
* For distros not shipping AppStream metadata at all yet, e.g. Ubuntu * For applications that have been installed locally, but from a repo that doesn't support AppStream, e.g. Chrome or Steam could do this in the future. * You need to install the file to the filesystem so that it's present in the correct binary package * You might have installed a different version of an application to what the metadata was built against, e.g. installing F22 packages in an F21 system.
- Almost the same goes for icons, if appstream-data will copy icons to
/usr/share/app-info/icons, why to have two copies of the same image?
The AppStream ones are pre-resized, optimised and padded to 64x64 PNG format, as processing lots of .svgs or large PNGs takes a loooong time to render when we start the session installer. We also might want to ship a different icon in the software center to the installed version. The bigger problem is you'd have to hardlink things in /usr when installing, which really isn't a good idea at all just to save a few tens of kb's.
why do we penalize users by hiding contents from them when some upstream just doesn't care about this stuff? (see also comment 7 about the "unjust burden")?
We have both a carrot and a stick. The carrot is that if you ship high quality translated descriptions, keywords and screenshots with the correct aspect ratio you get included higher up in the search results. The stick is that applications that are really bad or that are dead upstream don't show. They'll still show up in the "installed" view if you install them on the command line, we just don't make them easy to install. I'm intending to keep raising the bar for applications in the next few years, and at the moment the bar is set so very low.
- If there is a trend to split localised information into separate
langpacks, why to mix all locales into one file, not allowing any split?
We're not doing anything with langpacks. The only time languages comes into the story is when the metadata gets built we decompress the application and any packages it requires from the same srpm and then run some tools to find out what locales are included in the application so we can suggest applications higher that are available in the users locale. In the software center, installing inkscape should probably just install all languages, and I'm hoping to use the new soft-dependencies feature of rpm to achieve this. If you install it on the command line, you can choose just the language packs you want, but for the saving of a few Mb it's not something I wanted to clog up the UI for. If the language packs are huge and that important, I guess you could use metainfo files to install them as addons, just like we're doing with eclipse extensions and browser plugins, but that's not something I'm super interested in.
Also, no localised screenshots allowed - "Screenshots should be taken with US English as the display language." - even if they could be tagged with language code too?
You can take localised screenshots and tag them with the right language code, but at the moment we just ignore them in the extractor. There's exactly one application in the whole of F21 that has localised screenshots (in just two languages) but it's an open feature request in libappstream-glib to support this better. At the moment it's an uphill battle getting upstreams to take screenshots, and I didn't want the message to be "take them in any language you like". Realistically, we need automated screenshot capture to be a reality before we can advertise "localized screenshots" as a feature.
- If we copy the screenshots, why not to provide them also in an optional
package?
Why? What use would they be when you've installed the application? We already mirror them to the mirror network, and we cache them locally.
I've heard there are still some people who don't have Internet connection and install Fedora from DVD (do we still allow to install more packages from DVD after the initial install, right?)
I don't think gnome-software is going to work very well without internet access. It shouldn't explode, but it's just not going to be super useful.
Richard
On Wed, 2014-08-20 at 15:42 +0200, Karel Volný wrote:
why do we penalize users by hiding contents from them when some upstream just doesn't care about this stuff? (see also comment 7 about the "unjust burden")?
To clarify, the goal is not to penalize users: quite the opposite. We want applications in the software installer to have good descriptions and screenshots to help the user decide if he wants to install the application. The status quo in F20 is that many apps have just a sentence fragment of description taken from the desktop file, which is not very helpful to users and makes our software center look bad. Hiding applications without good descriptions will improve the quality of the results we show, and also encourage Fedora packagers to add the descriptions. (If upstream doesn't want to add an appdata file, you can do so in your packaging!)
Michael