AppData Screenshot Requirements

Kevin Kofler kevin.kofler at chello.at
Thu Dec 18 12:36:09 UTC 2014


Bastien Nocera wrote:
> It's not the blogging. Blogging more often that the standards were upped
> and that next month's Fedora release won't accept your old AppData is
> fine. Blogging every month saying "we changed this little thing" is more
> the problem.

Other maintainers might appreciate the early notifications though, as 
opposed to learning a few days before Final Freeze that they have to fix all 
their AppData for "next month's Fedora release".


As for my opinion, what I consider the real problem is the fact that the 
requirements are growing at all, or even that there ARE such requirements to 
begin with. For example, minimal screenshot sizes are a problem if upstream 
does not deliver screenshots at that size, it means the packager needs to 
take his/her own screenshots. And if the required minimum size keeps 
increasing, we may even end up with the packager not having hardware 
displaying at that size, which will make it very inconvenient to take 
screenshots at such a size. I have seen Richard Hughes's extreme padding 
example, but the main issue there is how GNOME Software is displaying the 
screenshots: It should scale and letterbox them, not pad them on all 4 
sides.

The fact that Richard Hughes decided to not show Qt 3 applications is also 
bad. Qt 3 still works fine, and just because an application still uses it, 
it doesn't mean it isn't useful. (And I guess Qt 4 will be getting the same 
treatment soon with the everincreasing "standards", which will have even 
worse fallout.) And porting to a newer version of a toolkit, or to another 
toolkit altogether (e.g. from Tcl/Tk), is also not something a packager can 
easily do. Why should an end user even have to care what toolkit the 
application uses? What users care about is whether it does what they need to 
do! If the only application that does it is written in Qt 3, Tcl/Tk, or even 
Xaw, so what?

        Kevin Kofler



More information about the devel mailing list