Bug 476794

Can you attach some screenshots that show the issue happening? Thanks.

Created attachment 168719 [details]
As you can see each window has it's own icon, except in the panel.

I'm now using Plasma 6, the screenshot is from that.

Operating System: Manjaro Linux 
KDE Plasma Version: 6.0.3
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.3
Kernel Version: 6.1.84-1-MANJARO (64-bit)
Graphics Platform: X11

Closing it as "RESOLVED WORKSFORME" due to lack of reply, seems disingenuous. Surely it wouldn't take much to create something infinitely more accurate, for instance "NOTRESOLVED LACKOFINFO".

The Icons-only Task Manager intentionally always shows the app icon, not any custom window icon the windows are showing. The mode to disable grouping breaks the paradigm of what the Icons-Only Task Manager is trying to do (show apps, not windows), but people really wanted that, so here we are.

This does lead to inconsistency when the window shows a custom icon, but such is life. :)

> The Icons-only Task Manager intentionally always shows the app icon, not any custom window icon the windows are showing. 

Seems like an odd choice...I would think that showing the window icon in the list of windows (that pops up when you hover over the app icon) would be preferable for most. It could be configurable, so if it's a bit slow in some cases, people can choose.

Obviously, people expect the window icon to be used when the windows are not grouped.

> The mode to disable grouping breaks the paradigm of what the Icons-Only Task Manager is trying to do (show apps, not windows), 

Perhaps you've explained poorly, or I've misunderstood, but I think you need to re-assess your paradigm.

1. It doesn't "show apps, not windows"...it shows windows grouped by app.
2. The paradigm only applies to one "mode" and we're talking about another.
3. Showing the window icon for windows, where applicable, fits the group-windows-by-app paradigm, just as well as the don't-group-windows paradigm. You just put the icon in a different place...or not, in KDE's case.

As you put it, un-grouped is another mode...it's just poorly implemented because the focus is on the vision of the grouped mode (you've said as much). Though nothing so far tells us why you think that using the wrong icons is acceptable, or why it's difficult to use the proper icons. You've only said  that it doesn't fit someone's idea of how it should work. Perhaps there are other, better, reasons that haven't been identified...

>but people really wanted that, so here we are.

That's the point, not everyone wants windows grouped by app. You realised this, and implemented something. Great, but why not do it right?

> This does lead to inconsistency when the window shows a custom icon, but such is life. :)

What's stopping you from checking if there's a custom icon and using it appropriately? The lack of doing that is what leads to the inconsistency.

Mate uses the window icon whether it's grouped or not. Admittedly the group uses the icon of the last window to open, not ideal but I could live with that if I used groups. 

Apparently, even windows can do it right:
https://forum.kicad.info/t/taskbar-icons-of-different-kicad-windows-win10-vs-linux/38287

So far, it just sounds like a bad design decision...but such is life I suppose. ;)

I'm sympathetic to your point. But it's challenging. If we use the window icon when windows are not grouped, then you'll have the experience of clicking on a launcher icon (which uses the app's icon) and then once the app launches, the icon will change into a different icon specific to what the window shows. That would be rather odd.

The greater issue is that right now the UX here is incoherent since the icons-only task manager was originally intended to implement the "dock" style UI where windows are always grouped under an icon provided by the app itself, not any of its specific windows.

We need to sort out the design vision here before we start pulling it in any given direction, or else it will drift ever more aimlessly in random directions that make the UX less coherent.

Thank you for your reply. :)

>If we use the window icon when windows are not grouped, then you'll have the experience of clicking on a launcher icon (which uses the app's icon) and then once the app launches, the icon will change into a different icon specific to what the window shows. That would be rather odd.

That should only happen if the first window closed, and another one opened. I think using the window icon would be proper behavior, but it should be a separate entity. In other words the launcher always stays the same. If the main/first window to which that icon applies is open then it's listed under that launcher, otherwise the window has it's own icon separate from the launcher (of course this includes any additional windows that use the launcher icon).

Or again when not grouped, launchers are just launchers and always spawn a new window object. Seems like a candidate for an option.

What you describe is basically the reverse of what we have now. We click on a launcher with one icon (in Kicad's main window), it launches a window with the same icon, but the task manager uses a different icon). You can see it all in the screenshot I posted. 

If the window has an icon then it's there for a reason, so presumably that's what should be displayed. Anything else seems rather odd.

>The greater issue is that right now the UX here is incoherent since the icons-only task manager was originally intended to implement the "dock" style UI where windows are always grouped under an icon provided by the app itself, not any of its specific windows.

You're right, this issue is why (or at least one reason why) it's incoherent. Grouping them under a single icon is one thing, but that doesn't mean you can't also use window icons where appropriate.

I just checked out cairo-dock, it uses icons for the windows in a group, but incorrectly uses the same icon for all windows in the group. Even if you want to otherwise copy docks, there's no reason not to use the proper window icon. 


>We need to sort out the design vision here before we start pulling it in any given direction, or else it will drift ever more aimlessly in random directions that make the UX less coherent.

Fair enough, but that should've been done when the functionality to ungroup the windows was added....arguably that functionality never should've been omitted in the first place. 

I see only one option, which is what you're already doing. Allow both grouped and not grouped modes. Speaking as a user and as someone who likes window switchers and doesn't like docks, the only thing I've found to screw up the UX is the lack of proper window icons.

So my way of looking at it:

There are groups, windows and launchers. In this context I see launchers as pinned groups, I'll lump them together with groups. The task manager shows groups or windows.

A window is represented by it's own icon. When you hover over it, an image of the window is displayed and above that is the icon on the left followed by the title. So almost the same as now but use the window icon, twice.

A group is represented by the app icon, presumably you already have a definition for that, but I'd say it's the icon from the launcher (the main window should be the same anyway). When you hover, a window list is displayed. Each window in the list is shown the same way as described above. So again the same as now but use the window icon for the windows.

Combined with the launcher stuff from the top, I think it's coherent and should suit most if not all, but perhaps there's more to consider.

For years, our party line was that we only use app icons and not window icons, because window icons aren't supported on Wayland.

However that's changing soon, meaning both platforms will have feature parity the the technical objection  becomes invalid.

If we do end up displaying window icons, we'll have to be careful, for a number of reasons:
1. Not all windows set window icons, so some windows will still show app icons.
2. Some window icons are ugly low resolution pixmaps that look bad on light or dark themes.
3. The case where a launcher transforms into a Task becomes awkward, since the launcher will always show the app icon, but when it transforms into a Task, if the Task's window has a window icon, it will change into that, which could be unexpected and look bad
4. We wouldn't want to show window icons at all in the always-use-grouping mode of the Icons-Only Task Manager because it's designed to represent tasks as instances of apps, rather than as discrete windows. So whether it shows window icons or not would change depending on whether grouping is enabled or disabled, and what type of Task Manager it is.
5. Some people just don't like seeing window icons in their Task Managers; see bug reports like Bug 192932.

None of these are insurmountable issues to overcome, but it would require careful design to avoid becoming incoherent, ugly, or feeling arbitrary and buggy to users who can't grasp the patterns behind why things are the way they are.

Anyway, re-opening for consideration since soon we won't be no longer blocked technically. I recall an old bug report asking for this, but I can't find it right now. If I do, I'll probably re-open it and mark this as a duplicate of it.