The current task manager assumes that the launcher icon is always appropriate to use. However multiple windows from the same application can have different icons, which are useful to distinguish those windows. Example #1: Pidgin uses the buddy icon in chat windows. Example #2: Virtual Box can have an OS icon associated for each virtual machine that is then used for the window icon. It is a lot more important to me to use the correct icon than for it to be themable. Until there is a magic way to determine when it is appropriate to use the launcher icon, please bring back the option to disable this "feature" (removed in https://quickgit.kde.org/?p=plasma-desktop.git&a=commit&h=8bfb3d596d2bb87e58476bd8a366f890e3cb1d9c). Reproducible: Always
This issue affects all Google Chrome apps as well. Any Chrome app, pinned or opened, shows up exactly like another Chrome window. I much preferred the previous option as well, as it at least allowed Pidgin to work, and if I remember correctly, right up until Plasma 5.3, allowed Hangouts and other Chrome apps to render their actual icon.
Created attachment 98068 [details] Patch to revert to the desired behavior For anyone willing to build from source, this patch applies against plasma-workspace (5.6.0, may work with others) to revert to the desired behavior of not using launcher icons. There is no configurability: this unconditionally uses the window's icon, which is the correct behavior as far as I'm concerned.
(In reply to kde from comment #2) > Created attachment 98068 [details] > Patch to revert to the desired behavior > > For anyone willing to build from source, this patch applies against > plasma-workspace (5.6.0, may work with others) to revert to the desired > behavior of not using launcher icons. There is no configurability: this > unconditionally uses the window's icon, which is the correct behavior as far > as I'm concerned. Thanks! Patched and working as intended on Archlinux (with testing repos enabled as 5.6.0 is still there).
*** Bug 361442 has been marked as a duplicate of this bug. ***
I can confirm bug with Plasma 5.6.2
Chrome actually tells us the ID of the webapp it's currently showing, I'll have a look if I can add a heuristic for that at least.
Note I will veto a Chrome-specific heuristic; it has to be sufficiently generic.
Git commit 92efc6ca6ec3c1c1c34a777c470337d4fde4b0c1 by Kai Uwe Broulik. Committed on 06/06/2016 at 20:05. Pushed by broulik into branch 'master'. [Libtaskmanager] Add support for regular expression mapping This allows more complicated rules, useful for matching Chrome webapps to their respective desktop file where we need to change crx_foo to chrome-foo-default. Related: bug 358277 FIXED-IN: 5.7.0 Differential Revision: https://phabricator.kde.org/D1673 M +6 -0 libtaskmanager/taskmanagerrulesrc M +47 -0 libtaskmanager/xwindowtasksmodel.cpp http://commits.kde.org/plasma-workspace/92efc6ca6ec3c1c1c34a777c470337d4fde4b0c1
What's the reason to show the application icon instead of the window icon? The task list does not show applications, but windows. The window manager shows the window's icon, the task switcher shows the window's icon, but the task list shows the application icon. That's not only inconsistent, but also bad usability. In the worst case, you have to click all tasks with the same icon just to find the one you want to activate.
> The task list does not show applications, but windows. The task list shows tasks, not windows. Tasks are an abstraction built out of data from different sources. One of those sources is windows, but the others are launchers and startups notifications. Launchers and startup notification use system theme icons for applications. These different things form a lifecycle; a button morphs between launcher, startup notification and window. Preferring it always means that: - Icons don't change jarringly between states. - Buttons always use the theme icon, meaning they change reliably when changing the system icon theme, even if the application uses an incorrect mechanism to load its icon assets (i.e. not using the system icon theme). Both of these not being true lead to many, many user bug reports in the past. Additionally, on Wayland there is currently no window icon. There's only an app id, and the app id is used to find an icon, just like is now done on X11. That means consistent behavior between the two supported windowing systems. The code falls back to the window icon (on X11) as a last resort when an app can't be identified (due to not being installed or being broken).
Thanks for the clarification, Eike. We're only talking about those tasks that represent windows here. I see it this way: - when starting an application, all you have is the launcher icon, so that's what you show - when it is started and you have a window (or more), you should show the window's icons; that's what the wm does, that's what the task switcher does and that's what you use to recognize the window If Wayland does not support window icons (yet), that's fine, Then it's again consistent with the wm and the taslk switcher, because all will display the application icon. Just take it to an extreme, open 10 chromium apps or eclipse instances with different icons and try it find the one you need. It becomes horribly inefficient.
It comes down to this: - I get bug reports either way. - This avoids many more of them. -- Because the problems stated are obvious and hard to avoid, while the other is much rarer. -- Meanwhile few apps have window icons differ from system icons, and of those, most are unintentional cases or better fixed otherwise, or will get fixed otherwise because Wayland forces them to fix it. --- For example: The Chrome apps case you mentioned no longer applies with the changes in comment #8, they get their individual icons now. - It has the benefit of consistent behavior between X11 and Wayland - I's where things are headed: The "it's inconsistent" thing is fixed on Wayland. (But I disagree this is an issue, because tasks are not windows.) - It improves performance and memory usage by avoiding data copies. Theme icons are cached. So, it's a judgement call -- and one I'm fairly confident in. That's the direct answer to "what's the reason?"
Also, the idea of "you fall back to the launcher icon until you get the better icon" is wrong usability wise: I've seen many users confused (along with reports about it) that they can't find their pinned app after launching it because the icon changed. Additionally with shoddy toolkits the window icon is often not the "better" icon (i.e. KDE apps will look up their icon properly, sure, but there's plenty of apps that install a .desktop pointing at a good icon, but stuff a crappy/different 32px icon into their window metadata - fun on hidpi).
(The latter actually brings me to another case: Even when the launcher and window icons are "the same", there can still be an ugly visual morph between startup notification and window because e.g. the launcher icon can be a vector asset rendered perfectly and the window icon a bitmap that gets scaled, or the assets simply of different initial sizes. It's very ugly when you see a sharp startup transition to a blurry final state, i.e. the visual degrades during launch.)
Do I get this right: the maintainer of the taskmanager rules decides which applications can have window specific icons? Not the app developer, nor the user? I see the problem in a different light: showing a non-themed icon is not just a visual thing, while having all windows with the same icon actually impacts usability. I agree that hidpi support is something to be considered, but IMHO that's up to the application developer. If the author does not set a big enough icon, I guess that'll be one of the smaller problems with that application. And I don't think that the performance savings have any significance compared to the time spent (lost) searching for the right window.
> Do I get this right: the maintainer of the taskmanager rules decides which applications can have window specific icons? Not the app developer, nor the user? No, you don't. App developers get to register their apps properly on the system and set up their window metadata so we can match windows to apps. Chrome does it incorrectly for their Chrome Apps windows, and the rule is a fixup to work around their bug. Fortunately Wayland makes it much harder for them to screw up this way, because the relevant piece of metadata on Wayland is a freedesktop.org appId, whereas on X11 the documentation state makes it a bit harder for app devs to get it right (though mosy are less broken than Chrome). It's likely on Wayland they'll get it right (if not, tough: we'll resist supporting broken apps on Wayland as hard as we can). > just a visual thing Features are not done until they look good. Users don't like things that look broken. Not liking things impacts usability. This is the best way to a not-broken-looking icon, which matters a great deal to how the system feels.
Re this, > the time spent (lost) searching for the right window Note we've both provided examples of users losing time searching for the right window: The launcher -> app case, and the windows-with-different-icons case. The latter are still differenciated by window titles, but the former are not as launchers are shown sans title initially. It's also fairly uncommon for applications to have multiple persistent windows or instances these days, much less ones that actually set different window icons on them. I acknowledge your pathological case -- I just don't think it's correct to optimize for it given the many issues it brings, and the migration path to Wayland which would make it obsolete again. Plus it's fixable by app devs in other ways: Just like Chrome registers its web apps (but then gets the window metadata slightly wrong, requiring a fixup), so can VirtualBox register VMs. This also has a big advantage: When done this way, windows an automatically be pinned as launchers, because they have a proper identity.
OK, so if there is a standard, documented way to specify which icon to use for a window, that's fine. If you have a reference to the spec, if would be nice if you could post it here so that one could pass it on to the authors of misbehaving applications. Just nitpick left: you quickly learn that clicking a certain launcher icon results in a task with a differently looking window icon. The loss of time is therefore a one-time penalty, compared to the constant lookup of windows with the same icon.
On X11: 1. Install a desktop file named <foo> that references the desired icon 2. Make the second part of the window's WM_CLASS be <foo> On Wayland: 1. Install a desktop file named <foo> that references the desired icon 2. Set the window's appid be <foo> Bonus: If the .desktop's Exec= has a way to launch whatever to get tha window back, cool. Also, you can add jump list actions there, and if you register documents you open with the same id, we can show recent docs for you.
Created attachment 100151 [details] Updated patch for plasma-workspace 5.7
Gotta close this as a WONTFIX, sorry everyone. It doesn't do anyone any good to keep open tickets we don't intend to act on. I understand that this is frustrating for folks, but Eike makes a lot of good points. Many apps set really lousy window icons[1]. Often they're 32x32 bitmaps. Sometimes they're radically different from the pretty theme icons. And they're not supported in Wayland anyway. Sometimes you have to make tough design decisions, knowing that you can't please everyone and some people will be negatively impacted. It's a hard call, but ultimately having consistent app icons used throughout Plasma is important, so here we are. [1] Some prominent examples: - Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1371932 - Thunderbird: https://bugzilla.mozilla.org/show_bug.cgi?id=1371931 - LibreOffice: https://bugs.documentfoundation.org/show_bug.cgi?id=65754 - etc.