| Summary: | Big icons in task switcher when previews are disabled can get blurry, despite qualitative enough icons available | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Porkepix <porkepix> |
| Component: | tabbox | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | bugseforuns |
| Priority: | NOR | ||
| Version First Reported In: | master | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
Screenshot with Element blurry icon
Screenshot with Alacritty blurry icon |
||
|
Description
Porkepix
2023-02-18 19:21:47 UTC
Created attachment 156457 [details]
Screenshot with Element blurry icon
Created attachment 156458 [details]
Screenshot with Alacritty blurry icon
mpv disables compositing, so kwin stops providing previews and falls back to displaying icons. Electron based applications don't provide desktop file hints, so kwin uses whatever icons are provided in the X11 windows. Usually, those icons are low resolution and look blurry when upscaled. It can be fixed if the application provides _KDE_NET_WM_DESKTOP_FILE or _GTK_APPLICATION_ID properties. (In reply to Vlad Zahorodnii from comment #3) > mpv disables compositing, so kwin stops providing previews and falls back to > displaying icons. > > Electron based applications don't provide desktop file hints, so kwin uses > whatever icons are provided in the X11 windows. Usually, those icons are low > resolution and look blurry when upscaled. It can be fixed if the application > provides _KDE_NET_WM_DESKTOP_FILE or _GTK_APPLICATION_ID properties. I don't know what are desktop file hints, but while Element is indeed an electron application, Alacritty isn't one. So, kwin isn't checking `/usr/share/icons/hicolor/` by itself at all? Shouldn't it? No idea about _KDE_NET_WM_DESKTOP_FILE or _GTK_APPLICATION_ID but it seems to be very DE-specific; I think the task switcher should be able to get the correct pictures by itself with generic locations, shouldn't it? > I think the task switcher should be able to get the correct pictures by itself with generic locations, shouldn't it?
kwin doesn't have enough information to do that, all it knows that there is this window with this geometry, caption, wm class, and (optionally pid), but that's not enough. libtaskmanager uses some heuristics, but we won't add them in kwin.
The proper way would be to set either _KDE_NET_WM_DESKTOP_FILE or _GTK_APPLICATION_ID with the desktop file name. Then kwin read the desktop file and find the icon.
Then kwin can read* Oka, I tried to lookup for information about these _KDE_NET_WM_DESKTOP_FILE or _GTK_APPLICATION_ID but couldn't find satisfactory enough ones. Are these supposed to be properties in the .desktop file? Is it something that you intend to have fixed by the distribution maintainers/packagers? Or the software developers themselves? For the latter I highly doubt some of these devs will bother managing the special case of every desktop environment/window manager/compositor, which is why I was looking for pretty standardized ways working for every environment: from the software I was running, not many of them were affected by such issues (at least for those I ran there, many are more casually launched). Okay* |