On 20 August 2014 14:42, Karel Volný <kvolny@xxxxxxxxxx> wrote:
> 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?
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.
> 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?
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.
> 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?
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.
> 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?
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.
> 6) 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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
