Review of attachment 266864 [details] [review]:

Sure, looks good to me!

Review of attachment 266864 [details] [review]:

Thanks!

+<screenshot type="default">http://software.opensuse.org/package/thumbnail/nautilus.png</screenshot>

Doesn't look right to me at all.

Oh indeed - I had wondered about that myself, but did not check the image.
Do we have a recommended way to choose and host screenshots?

http://people.freedesktop.org/~hughsient/appdata/#screenshots is apparently the set of guidelines.

But I think there are bigger questions here. How does specifying a screenshot upstream make any sense? You would have to make so many assumptions about how it would look to the end user. I guess the best we can do is use screenshots generated by something like gnome-continuous. Then the question is how to version them. They will literally change every day as we tweak the toolkit, theme, and app. That sounds like a maintenance nightmare.

If we want to generate them automatically somehow then we would need a way to setup the conditions and script the app inside continuous. Maybe we need to do that anyway in order to get more rigorous integration testing. Don't know. But I don't think anyone is doing that yet.

Then then question is hosting. Hosting in git.gnome.org isn't really a good idea. If we have lots of downstream users we are a) going to do a shitty job of serving them b) kill the performance of our git server.

I think the only GNOME server we have that is capable of serving data like this to an unknown number of consumers static.gnome.org. But I'd have to check with Andrea Vera again to be sure.

I'd really like to get these issues resolved before this problem spreads farther.

A lot of really good points here...

An interesting question is who "owns" the screenshots. If it's upstream, then it makes sense to generate them probably at release time and tie them to a specific branch/version. This implies the screenshots possibly won't look correct on other distributions using e.g. a different theme or font.
If it's downstream, do we have a good way for those screenshots to be changed? I don't see patching the appdata xml file at packaging time being very convenient, but maybe that's a fair price to pay if you plan to change appearance from default? At the same time that would free us from some of the burden of serving millions of downstream users from GNOME servers.

In any case, for the immediate issue here I should probably remove the screenshot altogether for now.

My fail... I didn't review the screenshot before sending the patch.

You can upload the screenshot to wiki,gnome.org (indeed, there is a Goal to create a wikipage for every GNOME app, so you can use it in the page).

About maintenance of the screenshot, I agree with William... further changes may deprecate the screenshot, but I think it isn't necessary to have up-to-date with latest changes. Just a having a more or less accurate image should be enough to use it.

So, if you could please provide an screenshot, I can commit the changes.

Many thanks for your comments!

(In reply to comment #5)
> I guess the best we can do is use screenshots
> generated by something like gnome-continuous.

So, I thought a bit about using continuous, maybe with dogtail it's scriptable, but for most apps actually setting up the application state is hard. For instance, setting up evolution with an email account with actual accounts and emails. Showing an email client without showing what the emails look like wouldn't be good at all.

>Then the question is how to
> version them. They will literally change every day as we tweak the toolkit,
> theme, and app. That sounds like a maintenance nightmare.

I'm hoping the toolkit appearance doesn't change too much in the stable branches; and software like totem that does change between branches would have something like this in the appdata file: https://git.gnome.org/browse/totem/tree/data/appdata/totem.appdata.xml?h=gnome-3-10#n17

> Then then question is hosting. Hosting in git.gnome.org isn't really a good
> idea. If we have lots of downstream users we are a) going to do a shitty job of
> serving them b) kill the performance of our git server.

The only thing that uses those git urls is the metadata scraper, which runs ~once a month generating the metadata files that are served by the distro. We mirror the screenshots in Fedora at the moment on alt.fedoraproject.org.

Created attachment 289697 [details] [review]
Use appstream util to validate appdata format

at make check

Created attachment 289698 [details] [review]
Use appstream util on make distcheck

I attached two validations, obviously these will fail unless we fix the screenshot issue.

I did notice with 3.14 a screenshot pack. Couldn't we upload relevant ones to the wiki, starting with files_3_14, going on on each release in order to bump version on appdata xml? we might even be able to use the $(version) if we use the right filenames...

Richard already pushed app data to nautilus, so closing this one as fixed. Thanks for the patches Pierre! Sorry it tool so long to answer...