Proposal: Increasing application icon sizes to 64px

[Miloslav Trmač]

----- Original Message -----
> On 26 September 2014 12:36, Miloslav Trmač <mitr at 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