3:39 p.m.
tl;dr: AppStream builder will reject AppData screenshots smaller than 312x175.
If you want things to be pixel-crisp and your application ships only
one screenshot use 752x423. If you've got multiple screenshots use
624x351, or integer multiples thereof. You can still ship random sized
screenshots bigger than 312x175 and we'll pad them out to the right
size and shape, but choosing a 16:9 resolution makes everything look
consistent in the software center. If you think 312x175 is being too
strict, you really need to have a look at this:
http://alt.fedoraproject.org/pub/alt/screenshots/f22/624x351/proofgeneral...
-- I'm considering making 624x351 the smallest screenshot size allowed
for F22/F23 although this may be too strict at this stage.
Also, if you need to show the desktop background (e.g. for gimp, where
you want to show multiple windows at once) use an alpha channel as the
background. This allows gnome-software to composite in the current
users desktop when we show it before it's installed.
I've emailed most of the maintainers this affects privately, although
you can check your app by looking at this commit to the logs:
https://github.com/hughsie/createrepo_as_logs/commit/42e4c078a8a8bd882d29...
-- Thanks.
Richard
5:53 p.m.
Mr. Hughes, I have a complaint.
On Fri, Dec 12, 2014 at 2:39 PM, Richard Hughes <hughsient(a)gmail.com> wrote:
If you want things to be pixel-crisp and your application ships only
one screenshot use 752x423. If you've got multiple screenshots use
624x351, or integer multiples thereof. You can still ship random sized
screenshots bigger than 312x175 and we'll pad them out to the right
size and shape, but choosing a 16:9 resolution makes everything look
consistent in the software center. If you think 312x175 is being too
strict, you really need to have a look at this:
http://alt.fedoraproject.org/pub/alt/screenshots/f22/624x351/proofgeneral...
-- I'm considering making 624x351 the smallest screenshot size allowed
for F22/F23 although this may be too strict at this stage.
You, personally, asked that AppData be created for *all* packages [1].
I took you seriously.
You, personally, told me that "any screenshot is better than no
screenshot" [2]. I took you seriously.
I spent hours of my personal time, time that I could have spent in
other pursuits, to create AppData for a number of packages and try to
push upstreams to take it. Then you started throwing my work away,
because you didn't like a toolkit, or you didn't like an icon size,
discarding work that I spent precious time on based on criteria that
*were not revealed up front* (see [1] again). And now you have
rewarded my efforts to take you seriously by holding those efforts up
for public shame and ridicule.
When one is managing an effort staffed by volunteers, "Do not waste
the volunteers' time" and "Do not embarrass the volunteers in front of
large groups of people" ought to be on one's top ten list of guiding
principles for the effort. You could have sent me private email
telling me that the ProofGeneral screenshot is too ugly to live. I
would have been fine with that. Please understand that my motivation
to continue assisting with the AppData effort has been decreasing over
time, and has now hit a new low. For your sake, I hope that is not
true of other volunteers as well.
Please send me a list of the AppData in my packages that is not up to
your standards, or will not be up to your standards next year, and I
will do a git push to make it disappear.
References:
[1] https://lists.fedoraproject.org/pipermail/devel/2013-September/188799.html
[2] https://lists.fedoraproject.org/pipermail/devel/2013-November/191616.html
Alienatedly yours,
--
Jerry James
http://www.jamezone.org/
7:05 p.m.
On Fri, Dec 12, 2014 at 04:53:01PM -0700, Jerry James wrote:
Mr. Hughes, I have a complaint.
On Fri, Dec 12, 2014 at 2:39 PM, Richard Hughes <hughsient(a)gmail.com> wrote:
> If you want things to be pixel-crisp and your application ships only
> one screenshot use 752x423. If you've got multiple screenshots use
> 624x351, or integer multiples thereof. You can still ship random sized
> screenshots bigger than 312x175 and we'll pad them out to the right
> size and shape, but choosing a 16:9 resolution makes everything look
> consistent in the software center. If you think 312x175 is being too
> strict, you really need to have a look at this:
>
http://alt.fedoraproject.org/pub/alt/screenshots/f22/624x351/proofgeneral...
> -- I'm considering making 624x351 the smallest screenshot size allowed
> for F22/F23 although this may be too strict at this stage.
Hi Jerry,
I think you should step back and consider this in context.
*Everything* we do in Fedora, and more generally speaking in open
source, is a work in progress. There's no way to point out issues
except by showing examples. Anything else would be too handwavy.
gnome-software has taken the installation of applications to a new
level. For end-user graphical applications, especially games and
fonts, its a giant improvement. As with all new stuff, it's impossible
to guess all requirements upfront. When work on this started, hidpi
displays weren't as prevalent as they are now, and this wasn't as much
of an issue. But at least for the last year, recommendations have
been clear to have large 16:9 ratio screenshots.
Anyway, rhughes has put an incredible amount of work into this and is
doing a lot to coordinate various steps required to make this work. I
looked at the screenshot you linked, and I consider it an example,
presumably one of hundreds. Actually it is too fuzzy to make out
the application in it, unless you already know it. I'm certain that
the intent was not to riducule or discourage, but just to show the
issue.
Zbyszek
You, personally, asked that AppData be created for *all* packages
[1].
I took you seriously.
You, personally, told me that "any screenshot is better than no
screenshot" [2]. I took you seriously.
I spent hours of my personal time, time that I could have spent in
other pursuits, to create AppData for a number of packages and try to
push upstreams to take it. Then you started throwing my work away,
because you didn't like a toolkit, or you didn't like an icon size,
discarding work that I spent precious time on based on criteria that
*were not revealed up front* (see [1] again). And now you have
rewarded my efforts to take you seriously by holding those efforts up
for public shame and ridicule.
When one is managing an effort staffed by volunteers, "Do not waste
the volunteers' time" and "Do not embarrass the volunteers in front of
large groups of people" ought to be on one's top ten list of guiding
principles for the effort. You could have sent me private email
telling me that the ProofGeneral screenshot is too ugly to live. I
would have been fine with that. Please understand that my motivation
to continue assisting with the AppData effort has been decreasing over
time, and has now hit a new low. For your sake, I hope that is not
true of other volunteers as well.
Please send me a list of the AppData in my packages that is not up to
your standards, or will not be up to your standards next year, and I
will do a git push to make it disappear.
References:
[1] https://lists.fedoraproject.org/pipermail/devel/2013-September/188799.html
[2] https://lists.fedoraproject.org/pipermail/devel/2013-November/191616.html
2:08 a.m.
On 13 December 2014 at 01:05, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
I think you should step back and consider this in context.
*Everything* we do in Fedora, and more generally speaking in open
source, is a work in progress.
100% agree, I couldn't have said this better myself. The only way for
a standard to remain relevant and useful is to allow it to slowly
evolve.
There's no way to point out issues
except by showing examples. Anything else would be too handwavy.
Jerry: I didn't consider this would be insulting, and I'm really sorry
if it came across like that. I certainly wasn't aiming to ridicule
you, just to show an actual example. In this case I showed it's
clearly not a screenshot and just a resized thumbnail. Because another
screenshot is listed in the proofgeneral AppData file
http://alt.fedoraproject.org/pub/alt/screenshots/f22/source/proofgeneral-...
that does look good and fits all the size criteria I didn't email you
directly.
Anyway, rhughes has put an incredible amount of work into this and
is
doing a lot to coordinate various steps required to make this work.
...in his free time, in this case late on a Friday night. I do get
paid to hack on some of this stuff working at Red Hat, but a lot of
the more dull, time-consuming emailing and upstream bug-opening
happens in my spare time. I'm trying my best to make this work, and
I'm heartened to see the number of AppData-enabled applications is
going up nearly every day, with newly added applications
more-often-than-not having validated AppData files without any nagging
from me.
Richard
3:46 a.m.
----- Original Message -----
On 13 December 2014 at 01:05, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
> I think you should step back and consider this in context.
> *Everything* we do in Fedora, and more generally speaking in open
> source, is a work in progress.
100% agree, I couldn't have said this better myself. The only way for
a standard to remain relevant and useful is to allow it to slowly
evolve.
To be honest, the "slowly evolving" AppData requirements/changes have
also grated me the wrong way. I get confused by the upstream vs. Fedora
requirements, I get confused by the F21 vs. F22 requirements. I get annoyed
that I can't easily test changes and see what it will look like (although
the tools got somewhat better recently).
This would explain why the AppData for my packages haven't been up-to-scratch,
I'm just waiting for the updated requirements a couple of weeks from now.
Cheers
3:54 a.m.
On 18 December 2014 at 09:46, Bastien Nocera <bnocera(a)redhat.com> wrote:
To be honest, the "slowly evolving" AppData
requirements/changes have
also grated me the wrong way.
Okay, so that's probably something we need to do something about.
Would more frequent blogging help or hinder this?
I get confused by the upstream vs. Fedora requirements,
They are the same thing, no?
I get confused by the F21 vs. F22 requirements.
So, at the moment the only way that F22 and F21 differ is that F22
requires a minimum icon size of 48px, and f21 requires 32px. Most
actively maintained packages (especially the kind of ones you
maintain) easily meet this requirement. Would a generated HTML page
of:
pkgname,fasname,application-id,green/red for F21, green/red for F22?
be a useful thing to do?
I get annoyed that I can't easily test changes and see what it
will look like
Doesn't dumping the updated AppData file in /usr/share/appdata work?
Richard
4:18 a.m.
----- Original Message -----
On 18 December 2014 at 09:46, Bastien Nocera
<bnocera(a)redhat.com> wrote:
> To be honest, the "slowly evolving" AppData requirements/changes have
> also grated me the wrong way.
Okay, so that's probably something we need to do something about.
Would more frequent blogging help or hinder this?
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.
> I get confused by the upstream vs. Fedora requirements,
They are the same thing, no?
You tell me ;)
> I get confused by the F21 vs. F22 requirements.
So, at the moment the only way that F22 and F21 differ is that F22
requires a minimum icon size of 48px, and f21 requires 32px. Most
actively maintained packages (especially the kind of ones you
maintain) easily meet this requirement. Would a generated HTML page
of:
pkgname,fasname,application-id,green/red for F21, green/red for F22?
be a useful thing to do?
That would be useful indeed, as long as it doesn't require too much work.
> I get annoyed that I can't easily test changes and see what
it will look
> like
Doesn't dumping the updated AppData file in /usr/share/appdata work?
I don't know. Does it? :)
I'd probably know more about testing if there wasn't that procrastination kicking
in every time I see a necessary change.
Good job so far on the cat herding though :)
6:36 a.m.
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
7:33 a.m.
On 18 December 2014 at 12:36, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
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.
Right, I'm about done with this discussion. You've made your opinion
very clear on this mailing list and on a number of trac tickets. As
far as I can see, you've done very little to actually work upstream on
the specification side, on the implementation or on actually writing
AppData files. I think it's time for you either to come up with a
better proposal, write some actual code or specification to improve
things, or to stop writing the same opinions again and again and
again. I'm sorry if this comes across as rude, but there's only a
finite number of times I can reply to essentially the same email.
Richard
7:22 a.m.
On 18 December 2014 at 10:18, Bastien Nocera <bnocera(a)redhat.com> wrote:
> > I get confused by the upstream vs. Fedora requirements,
> They are the same thing, no?
You tell me ;)
Yes, they are :)
> Would a generated HTML page ... be a useful thing to do?
That would be useful indeed, as long as it doesn't require too much work.
This was a few minutes work:
https://alt.fedoraproject.org/pub/alt/screenshots/f22/matrix.html
ideas of other things to show most welcome.
> Doesn't dumping the updated AppData file in
/usr/share/appdata work?
I don't know. Does it? :)
Yes, it does.
Good job so far on the cat herding though :)
We're at 49.9% AppData coverage for F22. That's something I'm very proud of.
Richard
9:44 a.m.
On Thu, Dec 18, 2014 at 01:22:04PM +0000, Richard Hughes wrote:
On 18 December 2014 at 10:18, Bastien Nocera
<bnocera(a)redhat.com> wrote:
>> > I get confused by the upstream vs. Fedora requirements,
>> They are the same thing, no?
> You tell me ;)
Yes, they are :)
>> Would a generated HTML page ... be a useful thing to do?
> That would be useful indeed, as long as it doesn't require too much work.
This was a few minutes work:
https://alt.fedoraproject.org/pub/alt/screenshots/f22/matrix.html
ideas of other things to show most welcome.
I'm a bit confused by this. For emacs the output is:
emacs emacs OK OK OK OK Warning OK
emacsclient emacs OK Warning Warning OK Warning Failed
But emacsclient does not have an appdata file at all. It something wrong
with its .desktop file?
For zaz:
zaz zaz OK OK OK Failed Warning Failed
The appdata file passed appdata-validate test a few weeks ago. Is this
things about missing icons something new or is this a false positive?
>> Doesn't dumping the updated AppData file in
/usr/share/appdata work?
> I don't know. Does it? :)
Yes, it does.
Good to know. This wasn't obvious.
Zbyszek
9:50 a.m.
On 18/12/14 15:44, Zbigniew Jędrzejewski-Szmek wrote:
I'm a bit confused by this. For emacs the output is:
emacs emacs OK OK OK OK Warning OK
emacsclient emacs OK Warning Warning OK Warning Failed
But emacsclient does not have an appdata file at all. It something wrong
with its .desktop file?
Actually why does emacslient even appear as a desktop app? Does it have
any UI of it's own? I know I have accidentally selected it sometimes
when searching for emacs in the overview...
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
9:58 a.m.
On 18 December 2014 at 15:44, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
I'm a bit confused by this. For emacs the output is:
emacs emacs OK OK OK OK Warning OK
emacsclient emacs OK Warning Warning OK Warning Failed
But emacsclient does not have an appdata file at all. It something wrong
with its .desktop file?
This is a bit unclear; what's happened here is that emacsclient has
been merged into emacs, absorbing all the keywords and search tokens.
Should emacsclient.desktop perhaps have NoDisplay=true?
For zaz:
zaz zaz OK OK OK Failed Warning Failed
The appdata file passed appdata-validate test a few weeks ago. Is this
things about missing icons something new or is this a false positive?
Hovering over the end "Failed", i see it's because zaz uses an XPM
icon. Since a few years we've not been supporting .ico or .xpm icons
as we wanted to keep the number of image loaders on the build servers
to the bare minimum. On the assumption the icon is >= 48x48, just
converting this to png in the spec file would magically fix this. In
my experience, most xpm icons are 16x16 and black and white, so
usually upstream needs a poke to ship something more modern.
Richard.
3436
days inactive
3442
days old
12 comments
6 participants
participants (6)
-
Bastien Nocera -
Jerry James -
Kevin Kofler -
Richard Hughes -
Tom Hughes -
Zbigniew Jędrzejewski-Szmek