-
Notifications
You must be signed in to change notification settings - Fork 462
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix missing dominant color #2045
Conversation
Some icons are not `Gio.ThemedIcon`, but ` Gio.LoadableIcon`, so we can get their pixel buffer from memory. Updated with `const` and list unpacking as used elsewhere in the file.
If the dominant color is missing (icon cannot be loaded), then a sensible fallback is used so that a running dot is still displayed.
Replaced `lookup_icon` with `choose_icon`, since it keeps looking in the current theme for a themed icon using all of its available names instead of only one. While `Gio.ThemedIcon` offers a `iconTexture.load_icon()`, it only looks for the first name available and fails otherwise. Also, `iconInfo` has been renamed to `iconBuffer` since `Gio.LoadableIcon` returns a stream/buffer (or should outright fail, which I could not observe yet). Could not find an example of app that uses a `Gio.EmblemedIcon` or any other implementation (i.e.: lacking `iconTexture.load`) that would justify another branching.
Looks good, thanks a lot! |
It seems that you've found the hard-to-replicate bug lol. From what I've understood before, in this bug the icon's emblem (usually the notification counter, but maybe the padlock in your case?) is retrieved as the So, to be clear, does the icon not appear on your dock, does it have the wrong dominant color, or are you only concerned about the messages? dash-to-dock/appIconIndicators.js Lines 1156 to 1175 in 52dfc08
|
seems to be something i'm cursed with 😩
The icon (and emblem) appear on my dock, that's where i got the picture from in my post.
The color is fine but not sure what you mean by dominant color. I checked the settings and it seems to only be mentioned in regards to the window counter indicators that show up under the icons, which are working fine and use an appropriate color with "Use dominant color" option on.
Yes, this, since I'm running Debian testing and monitoring the system messages/journal. I guess maybe I was confused about the error message initially and how it relates to this pull, but this was the only place i found |
The dominant color is used for these window counters as well as a glossy highlight replicating the old Unity dock. My theory is that dash-to-dock is trying and failing to get the dominant color of the padlock emblem (probably yellow) and apply it over the original dominant color (probably blue). I agree that this should be a new issue, because I don't know what would be the expected behavior here (ie: should we ignore the emblem, interpolate both colors, use only the emblem color?), and also because it has a different behavior (even if the same cause). |
This is the same attempt to fix #1493, in which we separate
Gio.ThemedIcon
fromGio.LoadableIcon
but now with theconst
keyword and using list unpacking, as is done in similar pieces around the file.I apologise for closing the previous merge request, GitHub asked to remove my previous commit when I clicked to sync my branch.
I read the documentation on how to cache and async it, but I couldn't make sense of the documentation, sorry.
When
iconTexture
is aGio.ThemedIcon
, it seems we can use choose_icon or lookup_icon, and the former is better suited as it's able to check for all possible names (which is useful as Papirus theme doesn't use the first name available fordrive-harddisk
).There's also a fourth case that I have trouble replicating, in which the icon is an emblem (I don't know the icon type), such as when an external HD is mounted. This doesn't apply to other emblem-like icons, such as mounted network devices and the trash can. This emblem raises aiconTexture.load is not a function
error.