Details
-
Bug
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
-
5.14, 5.15.0
-
None
-
macOS 11.x Big Sur
Description
(Note: I don't know the precise 5.x.x versions to specify, so I picked several essentially at random.)
On macOS Big Sur, the tray icon for the Qt-based application Nextcloud Desktop appears scaled to the wrong pixel dimensions; that is, the on-screen pixel dimensions of the icon do not match the pixel dimensions of the source image, and the on-screen pixel density does not match the correct (i.e. integer 2x) pixel density for the operating system.
A cropped screenshot of the Nextcloud tray icon is 40px x 40px, while a cropped source image of the icon is 28px x 28px or 56px x 56px. (I have also included a size comparison with two first-party Menu Bar icons.) I looked on the Qt documentation, and there does not appear to be any way to specify the geometry of a QSystemTrayIcon; it inherits its size from the QIcon, the size of which is determined programmatically based on mode and state, or with the paint() function, none of which appear in the source code for Nextcloud Desktop, suggesting that the dimensions are determined inherited from the NSStatusItem object itself.
I can't find the specific reference for Qt 5, but in the code mirror on GitHub, statusItemWithLength takes the NSSquareStatusItemLength parameter, suggesting that the size being inherited is the maximum allowed size for a Status Item icon, which:
- seems to have increased in macOS 11 Big Sur
- is not actually specified anywhere in the Apple Developer Documentation, and
- is significantly larger than most actual Status Item icons in macOS Big Sur.
All of this suggests that inheriting the dimensions of the NSSquareStatusItemLength parameter is no longer safe practice (if it ever was). Rather, in order to render Status Item icons on Big Sur at the same size they were in previous versions of macOS, the QIcon should render at the previous effective value (which would be backwards compatible) or, better, at a fixed, integer pixel density (which would be easier to develop for).
For further context, see the following GitHub Issues: