It's faster, simpler, and it avoids the resolution problems as it's the client loading the icon. Rather than passing the icon as a pixmap over DBus, it's more typical to use the IconName + IconPath. (for one thing there may be N hosts).Įven if you have a QIcon with multiple sizes, it can still only send one image as an IconPixmap field. It's not part of the spec, so whatever abstraction layer you use it simply won't work. There's no way to get the size the host is displaying at.
That's correct from Qt5.7, and probably worth doing, but it won't help fix anything, as you can see below. It also seems that QSystemTrayIcon will use AppIndicator or XEmbed That's not quite true, it is supported now, however you won't be using it as you have AppIndicator support. Hmm, AFAIU xembed deprecated There was a time KDE's plasma did not support it.
#Pixelated folder icon png code#
If I'd already dabbled in this corner of Qt, and wasn't about to leave for a week and a half, I'd offer to try writing the code myself and submit a pull request. I'd look around for more details (so far I've only dabbled with making little useless 'toy' programs using Qt, and kinda want to try implementing my own system tray icon in a program just to see how it all works), but I'm currently packing for a trip. Perhaps you could put in a ridiculous size like '512', and then use the 'actual size' it returns as the size of the icon you generate with _trayIconImageGen(). I also see the QIcon::actualSize() method that tells you the dimensions of a pixmap given a certain size, which it claims will never be larger than the requested size but can be smaller. Weird.Īt any rate, apparently QIcon has a lot of documentation too, including a way to choose which 'Icon Engine' you use which might be a simpler way of choosing between XEmbed and AppIndicator. I suppose in this way that KDE is the oddball though I swear this worked fine in a previous build. I do see in the documentation that 22px is considered the standard size for Linux (X11) desktops. However, I don't know how well integrated it looks on other OSes.
#Pixelated folder icon png windows#
It also apparently supports Windows and OS X, so you could potentially remove this from platform specific implementation and simply have it as the default code for all platforms. So perhaps you could just use that and not have separate code for AppIndicator (especially since Telegram has Qt and whatnot compiled statically). It also seems that QSystemTrayIcon will use AppIndicator or XEmbed on Linux, choosing whichever one is available/works best.
Is it possible for you to write such a handler for AppIndicator or QSystemTrayIcon? Failing that, at least a function or method that detects what the requested icon size is? You do have a resize handler for GtkStatusIcon. I don't know exactly what that size might be (and it will change depending on the user's preferences), but with the default panel (40px tall with fonts set to 96 DPI) the icons appear to be 32x32 pixels. Maybe that's telegram 'fault', maybe it's a KDE systray panel bug for resize events? Has anymore Plasma 5.7 running? There the systray is in KDE the panels can be dynamically resized at runtime, so ideally the code would use whatever size is requested. When I start Telegram in a konsole I get:įontconfig error: "/etc/fonts/conf.d/nf", line 72: non-double matrix elementįontconfig warning: "/etc/fonts/conf.d/nf", line 80: saw unknown, expected number usr/share/icons/breeze/apps/48/telegram.svg home/allee/.TelegramDesktop/tdata/icon.png: PNG image data, 256 x 256, 8-bit/color RGBA, non-interlacedĪs I use plasmas default breeze theme, I've also
On the other hand I use the 'Icon-only' Taskmanger and there even a biiig Telegram Icon is crisp and sharp! The taskmanager use the icon from the desktop file and it's a 256x256 png. I see the same problem when I resize the panel higher than the default:
0 kommentar(er)
