https://bugs.kde.org/show_bug.cgi?id=476794
--- Comment #9 from twistedturtle <hindred...@gmail.com> --- 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. -- You are receiving this mail because: You are watching all bug changes.
