tl;dr: You need an application icon of at least 64×64 in size

At the moment the appstream-builder in Fedora requires a 48x48px application icon to be included in the AppStream metadata. I’m sure it’s no surprise that 48×48 padded to 64×64 and then interpolated up to 128×128 (for HiDPI screens) looks pretty bad. For Fedora 28 and higher I’m going to raise the minimum icon size to 64×64 which I hope people realize is actually a really low bar.

For Fedora 29 I think 128×128 would be a good minimum. From my point of view the best applications in the software center already ship large icons, and the applications with tiny icons are usually of poor quality, buggy, or just unmaintained upstream. I think it’s fine for a software center to do the equivalent of “you must be this high to ride” and if we didn’t keep asking more of upstreams we’d still be in a world with no translations, no release information and no screenshots.

Also note, applications don’t have to do this; it’s not like they’re going to fall out of the Fedora — they’re still installable on the CLI using DNF, although I agree this will impact the number of people installing and using a specific application. Comments welcome.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food. View all posts by hughsie

7 thoughts on “tl;dr: You need an application icon of at least 64×64 in size”

Great idea. Also add complete, current, and clear user documentation/help to the “you must be this high to ride” bar.

So many applications have poor, incomplete, out of date, or even no end user documentation or help.

Time for the upstream to step up to the bar, or be left behind.

I believe this cleanup is needed, but vector graphic icons is what we should strive for, though

hughsie says:

September 12, 2017 at 8:10 am

As a source format, agree. It’s not awesome as a destination format as 100 svg’s take a long time to render.
1. Anton says:
  
  September 12, 2017 at 4:34 pm
  
  True, there is no point in rasterizing icons on every redraw. Rasterizing SVGs to very small icons also going to reduce their quality. But to have an option to generate icons for your specific settings is a dream anyway:)

Will upstreams be auto-notified in some way? This seems like one of many issues where being able to engage with upstreams over automated communications channels would be really useful, e.g. automated emails to project maintainers, or a bot auto-filing issues with upstream projects issue trackers (e.g., on GitLab, GitHub, …).

[WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.

This mean more a bigger metadata to downloas, isn´t it? Why not use a SVG scalable icon? SVG it is smaller in size that png.

hughsie says:

September 13, 2017 at 3:22 pm

$ du -h /usr/share/app-info/icons/fedora/64×64/darktable.png /usr/share/icons/hicolor/scalable/apps/darktable.svg
8.0K /usr/share/app-info/icons/fedora/64×64/darktable.png
40K /usr/share/icons/hicolor/scalable/apps/darktable.svg

Comments are closed.