| Summary: | Ghidra icon using .ico file is low-res in Kickoff app launcher but crisp in Task Manager | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | gudvinr+kde |
| Component: | Application Launcher (Kickoff) widget | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | aacid, kde, kdelibs-bugs-null, mikel5764, nate, noahadvs |
| Priority: | NOR | ||
| Version First Reported In: | 6.4.4 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
ghidra.desktop
task manager kicker ghidra icon |
||
|
Description
gudvinr+kde
2025-09-03 06:54:58 UTC
If you open /opt/ghidra/support/ghidra.ico in GIMP, do you see that it has multiple layers, and the top one is a small one rather than a big one? I gon't have GIMP but icotool shows this: ghidra.ico: x_pels_per_meter field in bitmap should be zero ghidra.ico: y_pels_per_meter field in bitmap should be zero --icon --index=1 --width=16 --height=16 --bit-depth=32 --palette-size=0 ghidra.ico: x_pels_per_meter field in bitmap should be zero ghidra.ico: y_pels_per_meter field in bitmap should be zero --icon --index=2 --width=24 --height=24 --bit-depth=32 --palette-size=0 ghidra.ico: x_pels_per_meter field in bitmap should be zero ghidra.ico: y_pels_per_meter field in bitmap should be zero --icon --index=3 --width=32 --height=32 --bit-depth=32 --palette-size=0 ghidra.ico: x_pels_per_meter field in bitmap should be zero ghidra.ico: y_pels_per_meter field in bitmap should be zero --icon --index=4 --width=40 --height=40 --bit-depth=32 --palette-size=0 ghidra.ico: x_pels_per_meter field in bitmap should be zero ghidra.ico: y_pels_per_meter field in bitmap should be zero --icon --index=5 --width=48 --height=48 --bit-depth=32 --palette-size=0 ghidra.ico: x_pels_per_meter field in bitmap should be zero ghidra.ico: y_pels_per_meter field in bitmap should be zero --icon --index=6 --width=64 --height=64 --bit-depth=32 --palette-size=0 ghidra.ico: x_pels_per_meter field in bitmap should be zero ghidra.ico: y_pels_per_meter field in bitmap should be zero --icon --index=7 --width=128 --height=128 --bit-depth=32 --palette-size=0 --icon --index=8 --width=256 --height=256 --bit-depth=32 --palette-size=0 Yep, the smallest one is in the top layer, as I expected to see I guess this is a bug in the .ico file extractor *somewhere*; it should choose the largest size, or at least the one most appropriate for the requested size, rather than the top layer. Can you attach a screenshot showing how it looks in both places on your system? Created attachment 185103 [details]
task manager
Created attachment 185104 [details]
kicker
Very interesting; that's not what I would have expected. Both use Kirigami.Icon under the hood, so it's possible what's going on here is that one UI happens to have the icon at an exact size that the .ico file has a version for, whereas the other one does not, so it falls back to the top layer, which is small. That's speculation on my side though. Why did you assign this to kimageformats? Speculation that the .ico file format handler returns a non-ideal layer. But it's kind of a guess as I'm not super familiar with this stack. If this is the wrong place for the bug report, feel free to move it to the right place. There is no ico handler in kimageformats, it's part of qtbase. This is probably me editorializing a bit too much, but I think it would be great if the robot could look slightly derpy or silly. That way you'd get a subconscious visual cue not to take its output as gospel truth. Ok, if my speculation is correct, then I guess it's a Qt bug. Do you think my speculation is indeed correct? With the information of this bug and having done no debugging at all, i don't think this is a Qt bug. It works in one place and does not work in another. It seems that if it was a bug in Qt it would not work anywhere. For me it seems a bug in kickoff (or it's dependency chain) that should be doing the same that the task switcher is doing to get the proper rendering/contents. Both are using Kirigami.Icon to display the icons. Here are the the only differences in the implementation: - Kickoff sets `animated: false` and `selected: [some condition]` - Task Manager sets `active: [some condition]` I wonder if it's `animated: false`. I'll look into this further. Created attachment 185461 [details]
ghidra icon
If I make the Kickoff implementation and size identical to those of Task Manager, I can still reproduce the icon being blurry in Kickoff but crisp in Task Manager. I'm at a loss to explain why at this point.
I'm attaching the icon that exhibits the problem so someone smarter can figure it out.
>Both are using Kirigami.Icon to display the icons.
I doubt it. The task manager would prefer the X provided window icon direct from the application if available
They both are on the QML side. It's possible the task manager has a more complicated C++ underbelly to get the icon. |