Bug 7911 - icons don't follow current standard sizes
Summary: icons don't follow current standard sizes
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Other (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.15.0
Assignee: Pierre Ossman
URL:
Keywords: prosaic, wilsj_tester
Depends on: 7541
Blocks: 5273 7885
  Show dependency treegraph
 
Reported: 2022-04-27 14:44 CEST by Pierre Ossman
Modified: 2022-12-09 09:28 CET (History)
1 user (show)

See Also:
Acceptance Criteria:
* Icons should be provided in the recommended resolutions and variants for each platform * Icons should follow the interface guidelines of each platform


Attachments
macOS icon template (3.21 KB, image/svg+xml)
2022-05-02 14:07 CEST, Pierre Ossman
Details

Description Pierre Ossman cendio 2022-04-27 14:44:21 CEST
Our current icons for the client and server have all been with standard dpi in mind. On a high dpi system, larger sizes will generally be use automatically to avoid scaling. This is mostly fine, except for when the icons have been explicitly modified to fit a certain size.

Right now, this only concerns the 16x16 size. For this size we've increased the overall weight of the icon, reduced the amount of detail, and exaggerated some features.

So if the system picks the 32x32 icon instead because it has twice the standard DPI, it will get an unsuitable result.

(we also do grid fitting for some more icons sizes, but that should not be a problem in this context as there will be a 1:1 mapping of the image and display pixels)
Comment 1 Pierre Ossman cendio 2022-04-27 14:50:47 CEST
Linux seems to have support for this, in that the icon theme specification also allows you to provide several versions with different scale. On my Fedora 35 system, I can see that the default "hicolor" theme has added a 2x scale in the theme definitions. No actual images are included with that, though.

macOS also seems to have support for an explicit 2x scale.

Not finding anything about this for Windows, though, so it might be completely overlooked there.
Comment 2 Pierre Ossman cendio 2022-04-28 09:43:57 CEST
Let's do this as part of updating icons for the new visual profile.
Comment 3 Pierre Ossman cendio 2022-04-28 10:53:32 CEST
Current guidelines for Windows:

https://docs.microsoft.com/en-us/windows/apps/design/signature-experiences/iconography
https://docs.microsoft.com/en-gb/windows/apps/design/style/app-icons-and-logos

However, they seem to be written for UWP applications. They also give no real style information, just sizes.

The Windows 7 guidelines are here:

https://docs.microsoft.com/en-us/windows/win32/uxguide/vis-icons

The design there doesn't match current versions of Windows, so it should probably be ignored. It is a bit clearer on relevant icon sizes, though.

I can't find anything about density handling. And I can confirm that Windows just picks larger icons for system applications if you increase the density. Looking at Windows 11, it seems like they are trying to avoid the whole density issue by having fairly simple icons in general. Avoiding the need to adjust detail as things get smaller.
Comment 4 Pierre Ossman cendio 2022-04-28 11:07:22 CEST
macOS's guidelines are here:

https://developer.apple.com/design/human-interface-guidelines/macos/icons-and-images/app-icon/

They seem to include everything we need; style, sizes and density.
Comment 5 Pierre Ossman cendio 2022-04-28 11:31:41 CEST
Linux is more difficult. There is no single unifying standard. The major player would be GNOME, and they have their style guide here:

https://developer.gnome.org/hig/guidelines/app-icons.html

However, they use application icons differently from more classical desktop, so they don't really care about different sizes or densities. Their own applications only include a single SVG each.

The Icon Theme specification doesn't give any recommendations on sizes either. The default "hicolor" theme supports a massive amount of sizes. But it only has 1x and 2x density, so at least that solves the question on densities.

If we look at what MATE does, we can see that they include the sizes 16x16, 22x22, 24x24, 32x32, 48x48, 256x256 and a scalable SVG.

Xfce is a bit more restrictive and has 16x16, 24x24, 32x32, 48x48, 128x128 and a scalable SVG.

Neither include multiple densities. In fact, very few applications in Fedora's repos include multiple densities. It seems to mostly various icon themes. Some are from larger projects, such as Linux Mint or Elementary, though.

Looking specifically at elementary, they include 16x16, 24x24, 32x32, 48x48, 64x64 and 128x128. All as SVGs, and all in 1x and 2x density.
Comment 6 Pierre Ossman cendio 2022-04-28 11:33:57 CEST
Also need to check if all platforms adjust the weight for smaller icons. And if so, how much.
Comment 7 Pierre Ossman cendio 2022-04-28 12:41:12 CEST
There's also KDE's style guide:

https://develop.kde.org/hig/style/icons/

It doesn't mention sizes or density much though, but if we look at their default theme we can see that they use 16x16, 22x22, 32x32, 48x48 and 64x64, all as SVGs. They also provide 2x and 3x density versions for 16x16 and 22x22. I assume those are the sizes with reduced detail and/or exaggerated features.

Looking at our current packaging, we've included 16x16, 24x24, 48x48 and a scalable version.
Comment 8 Pierre Ossman cendio 2022-05-02 13:30:05 CEST
(In reply to Pierre Ossman from comment #6)
> Also need to check if all platforms adjust the weight for smaller icons. And
> if so, how much.

There is some variation here, but most do some adjustment at lower sizes.

GNOME only has the icon size 128px, which is then scaled to everything else. A square is 104px at this size, meaning a margin of 12px on all sides. This means a 16x16 icon still has a margin around it.

For other Linux icons, everyone seems to use the full size at 16x16. I.e. no margins at all. At 24x24 it's a bit of a mix with some using the full size, some having a margin.

macOS has a similar margin as GNOME when looking at their icon template. They reduce it somewhat at 32x32 and 16x16 though, having 2px and 1px margins there respectively.

Windows has slightly larger weight on their images. At 256x256, they have a margin of 16px. At 128x128, that would mean a margin of 8px, compared to GNOME's and macOS 12px. They have no margins at 16x16, though. At 24x24 they seem to either have no margins, or just 1px. Oddly enough, it is picking the 32x32 size and scales it down, rather than using the 24x24 version in the .ico file.
Comment 9 Pierre Ossman cendio 2022-05-02 13:32:31 CEST
Also note that GNOME's "symbolic" icons should be designed with 16x16 in mind and no margin.
Comment 10 Pierre Ossman cendio 2022-05-02 14:07:01 CEST
Created attachment 1034 [details]
macOS icon template

Here's an SVG version of the macOS template, grabbed from here:

https://github.com/elrumo/macOS_Big_Sur_icons_replacements/issues/839
Comment 22 Pierre Ossman cendio 2022-05-03 09:41:29 CEST
ImageMagick is able to create .ico files, which makes things a lot easier to update. However, we seem to trigger this bug:

https://gitlab.gnome.org/GNOME/eog/-/issues/37
https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/50

Should not be an issue in practice, though, as this is just for the Windows stuff.
Comment 31 Pierre Ossman cendio 2022-05-05 10:37:27 CEST
The icons are now sized according to GNOME standards. This is slightly smaller than what seems to be the norm on Windows. But the difference is not noticeable IMO, so I don't think it justifies having a separate set of icons for Windows.
Comment 34 Pierre Ossman cendio 2022-05-10 09:36:20 CEST
After investigating things further, I'm re-scoping this bug as I cannot see an actual need for high dpi icons:

 * Windows has no technical support for high DPI icons, so we can't do
   anything there

 * On macOS, our current sizes are sufficient for high dpi without the OS
   having to upscale things. Very small icons (16x16) are very rarely used, so
   the fact that the OS will use the 32x32 version on high DPI systems is a
   very small problem and not worth all the extra handling.

 * On Linux, high DPI is not yet a standard feature, so GNOME and KDE are
   probably the only interesting cases.

   GNOME uses our SVG for large sizes, so upscaling is not an issue. It also
   only uses the "symbolic" icon for small sizes, of which we only have a
   single  variant. So no issues there.

   KDE uses large icons, but it grabs them from the windows, rather than the
   icon theme, and window icons cannot indicate if they are high DPI or not:

   https://bugs.kde.org/show_bug.cgi?id=351055

   (the task bar also uses window icons, despite the comments there)

   KDE rarely uses small icons, so like macOS, it is probably not worth the
   complexity of having high DPI icons for just that case.
Comment 35 Pierre Ossman cendio 2022-05-10 09:38:42 CEST
Investigating KDE showed that they do want some more sizes. In fact, more sizes than their own applications provide. So they have some magic for their own stuff that doesn't work for other applications.

Looking at Mozilla, we can see that they provide the sizes 16x16, 22x22, 24x24 32x32, 48x48, 64x64, and 128x128. These are provided both on disk, and as window properties. It's probably best if we use the same set for good compatibility.
Comment 36 Pierre Ossman cendio 2022-05-10 10:27:48 CEST
(In reply to Pierre Ossman from comment #34)
> 
>    KDE uses large icons, but it grabs them from the windows, rather than the
>    icon theme, and window icons cannot indicate if they are high DPI or not:
> 
>    https://bugs.kde.org/show_bug.cgi?id=351055
> 
>    (the task bar also uses window icons, despite the comments there)

Actually, it seems to be even more buggy. We don't set an icon on all our windows, because of bug 7915. Yet, KDE manages to sort out an icon for ThinLinc Setup. But it still fails to use the SVG version when it needs large resolutions.

KDE is just a mess...
Comment 39 Pierre Ossman cendio 2022-05-10 12:27:04 CEST
KDE seems to be happier now that we have more sizes. I get crisp icons in the start menu, and when hovering over items in the task bar.
Comment 40 Pierre Ossman cendio 2022-05-10 14:49:17 CEST
Should be all done now. Tested on Ubuntu 22.04, Fedora 35, Windows 10, Windows 11 and macOS 12.

> * Icons should be provided in the recommended resolutions and variants for each platform
> 

Should be okay now. We provide:

Linux standard: 16x16 22x22 24x24 32x32 48x48 64x64 128x128 and an SVG
Linux symbolic: Same as above

Windows: 16x16 24x24 32x32 48x48 256x256

macOS: 16x16 32x32 128x128 256x256 512x512

This should cover what the platforms recommend, and everything looked good whilst testing.

> * Icons should follow the interface guidelines of each platform

Linux: No one standard, but we have margins that seem to follow what many do. The style is also flat, which is what GNOME currently recommends. And they are the biggest DE.

Windows: Unclear guidelines. Margins are similar enough that it looks okay. Flat fits well with their UWP applications. Fits poorly with the older Windows 7 style. Unclear what the style for Windows 11 is supposed to be, as the included icons have many different styles. Hopefully we are good enough for now.

macOS: We use the same size and margins as recommend. We also add a drop shadow. However, we use a standard rounded rectangle rather than the adjusted shape Apple recommends. We also don't have a realistic icon. Unclear what that would look like though, so I think this is sufficient for now.
Comment 41 William Sjöblom cendio 2022-05-18 08:43:49 CEST
I have now given this some testing love using server build #2642 running on RHEL8 and client build #2642.

> * Icons should be provided in the recommended resolutions and variants for each platform
I have checked that the icons are correctly shipped with the Windows PEs, macOS iso, and rpm/deb packages (including both the client and server packages), as well as the icons used by tlinstaller.

The new icons also seemingly display correctly on:
- Windows 11 
- macOS 12
- RHEL8 (client and various server applications)
  - KDE
  - GNOME
  - XFCE

All looks fine besides the uninstaller binary on windows which uses the previous set of icon dimensions and the old icon. All other Windows PEs have the new icon resources besides that one.

> * Icons should follow the interface guidelines of each platform
Icons look good on all desktop platforms tested in terms of margins and other stylistic aspects. Worth noting is that IGEL uses rounded icons. So, in a perfect world, we would also provide a rounded icon specifically for IGEL terminals.


Apart from the Windows uninstaller not having the the updated icons things look good. Reopening.
Comment 43 Pierre Ossman cendio 2022-05-18 10:51:30 CEST
It was actually both the installer and uninstaller. Both should now use the same icon as the client itself.
Comment 44 William Sjöblom cendio 2022-05-24 08:54:56 CEST
Checked the windows installer and uninstaller in client build #2560. Both now have the updated icon in all sizes. Closing.

Note You need to log in before you can comment on or make changes to this bug.