----- Original Message -----
On 26 September 2014 12:36, Miloslav Trmač mitr@redhat.com wrote:
This is $n-th gradual tightening of the rules
Right, I think that's the only way to transition from having no rules of inclusion, to a large cohesive set of high quality applications. Dropping 95% of applications in the software center from F21 to F22 would be a very difficult thing for a lot of people to swallow.
Doing the same kind of work over and over is also difficult to swallow. I don’t know what the right answer is, I am just concerned. (Or, to put it in personal terms, I have two packages that are so marginally used that I am on the fence between updating them and orphaning them; they don’t have any appdata file yet, and seeing the pattern, it is always just too easy to rationalize that waiting for the next rule update will save me work.)
Just ask for something like (1024x1024 bitmap or a SVG/PDF) by F22 Beta, to give us some future proofing, perhaps?
SVG isn't a silver bullet. You need a very different source SVG for a 16px icon to a 256px icon just due to the amount of detail that has to be ommitted.
The 256px icon doesn’t _have_ to have more detail to be sharp and look basically good (well, unless you decide to include complex real-world objects like a globe with all the continents), and do you expect to render them at 16px from the app data anywhere?
(And I always thought that HiDPI is trying to keep the screen size of elements
You can either sacrifice quality or size; padding a 32px icon to 128px with a giant white border would keep the icon crisp and sharp, but scaling it up *4 would make it the right size, but with awful quality.
It would at least be no worse than having the same physical-size non-HiDPI screen; showing a tiny icon on HiDPI may well cause the HiDPi display to be _less_ usable. Blurry is “just” ugly (more of an aesthetics issue), tiny is unrecognizable (more of an getting-the-job-done issue). Mirek