This is propably a very similar problem to the wine case. See http://forum.kde.org/viewtopic.php?f=17&t=106637 and bug #317264.

I can confirm the same behavior. really missing and nice feature!
voted for this bug

Tried this feature in unity earlier today. It was really nice to see an "independent" app such as facebook or other nice stuff.
Tried in my laptop with kubuntu later, and I get multiple chromium windows instead... not nice!

Hope someone will take a look at this ....!

Came here with the same problem. I use quicklists for sime sites, which have hotkeys, and in Unity it behaves as should be, but Icon Tasks on KDE groups those windows.

*** This bug has been confirmed by popular vote. ***

Like the default taskbar Icon-only task manager should also have an option to not to group tabs. There's plenty of space in my taskbar. I would like to have separate tab for everything. For example, Chrome and Chrome Incognito, Konsole opened in different folders, etc.

It would lend me faster workflow. I will not have to click the group icon, search tab from the Present Window and click it to launch it.

Same here. Vote for feature request: add not to group option.

Still a problem in 14.10 . Any ideas if this can be fixed?

There seem to be two requests in this bug report:
1. Make Chromium/Chrome web apps not group with Chromium/Chrome browser windows
2. Add an option to not group certain windows/window types.

Regarding number 1, the task manager would have to use the app's ClassName to determine grouping. Below are some snippets of the relevant line from xprop:
Standard Chrome window:
WM_CLASS(STRING) = "Google-chrome-unstable (/home/lengau/.config/google-chrome-unstable)", "Google-chrome-unstable"
Chrome app window (hosted app):
WM_CLASS(STRING) = "crx_pkclgpgponpjmpfokoepglboejdobkpl", "Google-chrome-unstable"
Chrome app window (command line: google-chrome --app='https://kde.org'):
WM_CLASS(STRING) = "kde.org", "Google-chrome-unstable"

As can be seen, the ClassClass string (which the task manager uses for grouping) is always the same (in this case "Google-chrome-unstable"), but the secondary class string changes for items run in an app window.

The flip side of this is for Chromium to change the primary WM_CLASS of app windows, which was suggested in https://crbug.com/394037, which is much like the 

Regarding number 2, this should probably be its own separate feature request, provided people want it independently of #1.

I think it would be better to implement an option to let user choose it he/she wants to group two windows of same applications. I doesn't matter if they are Chrome web apps, Chromeand incognito window, two instances of Konsole, etc.

By using Icon-Only Taskbar we save a lot of space compared to regular taskbar. Grouping apps bring up back to the cluttering problem of regular taskbar. Half of the taskbar will remain free to be used and apps will use one icons for N number of windows.

Smooth taskbar already does that.

+1 for a fix.

I think the solution of blacklisting all apps which should not be grouped would be the best solution. So everyone can customize it for their needs. I suggest that for chrome/chromium and wine, grouping should be disabled by default.

*** Bug 344245 has been marked as a duplicate of this bug. ***

There's a blacklist system in place actually, and wine is set to manual grouping for some time.

Also: Note that you can actually manually set Google Chrome not to group via More Actions -> Do not allow this program to be grouped in the context menu.

This is more about whether it should be done by default for Chrome or not, but to be honest I don't like shipping large prefab lists for magic defaults. I'm going to NACK this for now.

Eike, the problem is that we want separate grouping for Chrome and it's web apps. If we disable grouping for Chrome, every Chrome window will be separate.

See comment #9 by Alex, this bug is describing request 1.

Yeah, but it's not that simple.

The grouping could be handled by implementing a "disable instance grouping for" rule type and shipping a prefablist with google-chrome-stable for it, but that wouldn't magically make pinning Chrome Apps as launchers work.

If you pin a chrome app to the application menu, you get a desktop file like chrome-<appid>-Default.desktop with an Exec value like "/opt/google/chrome/google-chrome --profile-directory=Default --app-id=<appid>". Mapping between that and a crx_<appid> WM_CLASS instance string is too complex to be reasonably rule-governed, and I'm not going to put Chrome-specific hacks into C++ library code.

What Chrome should do is use a WM_CLASS class string matching the menu id, i.e. chrome-<appid>-Default instead of Google-chrome-stable. Or at the very least use an instance string matching the menu id.

If that is the reason to not implement this then fine,  your previous comment suggested that disabling grouping for Chrome would fix the issue.

Lets hope that https://code.google.com/p/chromium/issues/detail?id=394037 will be implemented then.

@Eike The default Task Manager has Grouping options which allows you to set grouping to either "Do not group" or "By program name." A similar setting in Icon-Only Task Manager would solve a whole lot of problems. For example, I have multiple Android emulators running at any moment and they are by default grouped together. In order to access an emulator I have to first click the group tab and then choose the emulator. Currently, same apps are occupying single icon space while the whole panel is left empty.

Both default Task Manager and Smooth Tasks let you choose if you want to group or not. Do you think such a feature would be implementable and desired in Icon-Only Task Manager.

Let me put it this way: Task Manager and Icons-only Task Manager are the same codebase, just two different .desktop files and a few codepath forks based on the widget id. So exposing the grouping options is technically trivial, the code is there. In fact it's actually that there's code to *hide* it for Icons-only Task Manager.

This is a design decision - the idea being that in the label-less design it doesn't really make sense to default to showing several usually identical icons on the bar, especially since the user can out put of grouping themselves for exceptional applications.

It's also worth noting that Wayland is currently against adding support for dynamic window icons.

What about using ClassName for grouping instead of ClassClass?

As far as I can tell, most applications (and indeed most windows) set ClassName and ClassClass the same (or if not to the same thing, they vary at the same time). This would keep most apps unaffected, but wine, chrome, and similar apps that do change ClassName will have grouping based on that.

Or perhaps we could make advanced grouping options, so if ClassClass matches a specific regex then grouping is based on ClassName. This would allow identical behaviour for most apps (in case this does change something), but could be overridden in cases where it makes sense (e.g. wine, chromium).

Here's what the spec says:

ClassClass: 'A string that names the general class of applications to which the client that owns this window belongs. Resources that are specified by class apply to all applications that have the same class name. Class names are specified by the application writer. Examples of commonly used class names include: "Emacs", "XTerm", "XClock", "XLoad", and so on. '

ClassName: 'A string that names the particular instance of the application to which the client that owns this window belongs.'

IOW: Grouping applications by their ClassClass is correct, and Chrome is essentially asking for its apps to be treated as instances of Chrome. If it wants Chrome Apps to be treated as their own apps altogether, it should set different window metadata.

And yes, we could add another rule option a la "list ClassClasses where you want to substitute the ClassName instead" and put Google-chrome-stable into the default. But this would already be the second workaround we ship for a Chrome bug (we already ship with a WM_CLASS<->menuid mapping, because they manage to keep it the same for their unstable channels but not for the stable build ...), and I'm wondering where things stop. It also means more magic behavior that's difficult for users to gain insight into - I don't think exposing the complexity of all of this in the GUI is viable.

Does anyone here knows how Unity implements this? What do they group apps by? They manage to do it right for Chrome Apps.

(In reply to Eike Hein from comment #21)
> And yes, we could add another rule option a la "list ClassClasses where you
> want to substitute the ClassName instead" and put Google-chrome-stable into
> the default. But this would already be the second workaround we ship for a
> Chrome bug…

Hello! I am not a developer, I am a Linux desktop user. (I run Debian and Gentoo on various computers). I don’t know how to code.

But I do know that when I run multiple seperate wine applications, like notepad.exe and TeamViewer, both (even though a different icon) become one icon (of the last started wine application) in the taskbar.

The desired behaviour would be: let notepad.exe be one icon (with all its open windows i.e. if there are more than one instance/window of notepad.exe, it should still be one icon) and let TeamViewer be another icon (again, with all its open windows).

I don’t know about Chrome applications, but I guess it is the same problem really.

Another issue is, having a program starter should make the program starter icon remain as the active application icon. For instance, having a starter icon for TeamViewer always adds a new icon (a wine application icon) once TeamViewer is started. So I end up seeing two TeamViewer icons on the icon-only taskbar: one program starter, one active running TeamViewer.

In the end this is wrong desktop behaviour. I think that a universal workaround for wine and chrome should be worked out (and I am convinced this is also the case for other interpreter based applications, mono comes to my mind).

The only thing left for me to say is: please, PLEASE, please add a fix for this. A lot of users are waiting for a recognizable solution – they want to see the desired behaviour in the icons-only taskbar. And: BIG THANKS in advance! In general for KDE, in particular for working on making it better!

Wouldn't a simple preference allowing users to choose to group by ClassClass or ClassName solve this problem? Wouldn't this leave everyone happy?

(In reply to Pedro Albuquerque Santos from comment #24)
> Wouldn't a simple preference allowing users to choose to group by ClassClass
> or ClassName solve this problem? Wouldn't this leave everyone happy?

I forgot to say, that either way, I think that the KDE community, Google, and other "vendors" should just put any animosity aside and come up with a standard for web applications. It's important if we ever want to have the web as a first class citizen on our desktops, and I'll also think that KDE doesn't want to be left behind when it comes to that (right now GNOME Shell and Unity support this use case, while KDE doesn't).

I'd also like to add that while making an exception for Google Chrome does show one icon on the taskbar for every open window, the icon is always the Google Chrome icon. It doesn't use the window icon (the one shown on the top left corner by default and that is shown on Alt-Tab or Exposé). This is also undesirable IMHO.

Could someone give a fresh perspective about this bug report, or should I just create a new one?

It seems to some extent the code is in place.  If you create a launcher matching rule for a Chrome WebApp launcher it looks at the Windows Class and Window Name in order to match them.  So you can create a series of launchers for web apps and if you run one of them it correctly matches to the launcher.  It's only when you run a second and it 'groups' them that they stack under a single icon.

If the code is already reading both Class & Name fields to match to a launcher, it would seem that this is already an indication that the item would make sense to not be grouped with others of the same class, or indeed that a flag in the launcher matching rule to 'group independant of core class' (or some better term) would not add any significant additional complexity for users (given they've already gone so far as to make the rules).   

Could this logic then be fed through to the grouping algorithm to keep them separated out when grouping kicks in?

Forgot to say.  When using the launcher rules you can have multiple launchers which work as desired but then vanish when grouping kicks in only to then reappear when their linked application is closed. 

I understand what you were saying about Google changing the ClassName for webapps, but it seems the current situation is that it works for launchers, but not grouping, resulting in some quite interesting behaviours when the launchers also stack into  the group and then pop back out again.

If the ClassName is never used in grouping, I'm unclear what benefit there is to linking a launcher to a specific ClassClass and ClassName.  It would seem to only make sense to link a launcher to a specific ClassClass otherwise you get this slightly unexpected launcher stacking/hiding behaviour.

Just wanted to say that even at the cost of showing identical icons and no way of distinguishing among windows I would really like to see grouping disabled similar to task manager. First open preview and then pick a window really takes a toll on fastly moving among windows. People can make their choice even if it is not the best option.

PS:- Is there a Chrome bug filed so this gets fixed eventually? I will read this thread over, to my best understanding, and file one if it is not.

FWIW, I'm currently rewriting the Task Manager backend library from scratch (it's a necessary step to get us on Wayland, unfortunately) and I'll be revisiting the grouping logic as part of that.

(In reply to Eike Hein from comment #29)
> FWIW, I'm currently rewriting the Task Manager backend library from scratch
> (it's a necessary step to get us on Wayland, unfortunately) and I'll be
> revisiting the grouping logic as part of that.

Nice to hear that this issue will be looked upon in the future. Any idea of when will this new Task Manager backend land? Do you expect it to be ready for Plasma 5.7? Or will it only land later?

It's slated for 5.7.

(In reply to Eike Hein from comment #31)
> It's slated for 5.7.

I have just tested the latest "KDE Neon Developer Edition Git-Unstable Branch" image (http://files.kde.org/neon/images/neon-devedition-gitunstable/current/) and
I'm happy to see that the new Task Manager backend fixes this issue.

The testing that I have done was limited, but everything seemed to work well. Thanks to this change I may end up moving back to KDE in the near future. I moved away before because I started to use more and more "web apps" that running them as separate application icons on the "Icons-only Task Manager" became really advantageous for my workflow. Unfortunately, KDE didn't cover this usage scenario, up until now, so I had to move to GNOME Shell, which is better on this particular matter, but lacking in other areas (which are not that critical for me).

The only thing missing on the KDE ecosystem, that I can think of, is a seamless way to connect to and mount network shares, SSH direcroties, etc. Just like it happens on the GTK+ world thanks to GVFS. But... ohh well!! You can't get everything you want at the same time ;)

Hi Eike Hein,

In the old code of icon-only-task-manager there was code to show all windows of an app. Is that same code still available in the newly rewritten icon-only-task manager?

I will always have a few Chrome, Android Studio, and emulator windows. I find it extremely annoying that I have to first click the group then click the window. Or go through the filmsy animations.

So if that code is still available then I would like to learn a little bit QML/C++ or whatever language it is written it and enable it for my personal use. I want to disable all grouping in icon-only-task-manager similar to how it is the regular task-manager widget.

If you could guide me where to look, I would be very grateful for that.

Just right-click, then Advanced -> Disable grouping for the app.

Thank you Eike. That's awesome.

Is there a global setting to enable it for all apps?

^ It's per-app, sorry. If you want to disable grouping entirely see groupingStrategy in the applet's main.qml.

The primary problem here seems to be grouping is based on the ClassClass string, not the ClassName string (which would be preferred for Chrome apps).

I think this worked properly with Plasma 5.8.0 but now I'm on Plasma 5.8.2 and it's back to the old behavior. I compared Github but cannot see any changes in the code which would explain this (I checked plasma-desktop and plasma-workspace) so I guess the change is somewhere else (something I updated along Plasma).

I'd like to patch this myself to get my preferred behavior back. Do you know where to look (maybe the exact commit) which changed this back to grouping by ClassClass instead of ClassName?

When I had Plasma 5.8.0 installed, each Chrome app had its own instance on the taskbar (with child windows properly grouped within the correct task icon) even with the correct icon (not the general Chrome icon). All other apps worked correctly wrt grouping. So I think "wontfix" is not a satisfactory resolve status of this bug. Even unity gets this correct. I'm not even sure if the problem was properly understood when looking at the last comments.

If working with a lot of Chrome apps, the behavior as it is right now is a real pita. OTOH, I don't want to disable grouping of Chrome altogether as the taskbar gets much too cluttered then.

Comment #9 explained well what the difference is.

I can confirm that the problem reappeared. It was fixed with Plasma 5.7, and I'm almost 100% sure that it was still ok as of 5.8.0. However, I have tested 5.8.2 and 5.8.3 and the behaviour just changed back to how it was on 5.6.

What was changed that caused this? And why? Eike Hein seemed to agree with this change and, as far as I'm aware, he's the one responsible by the Task Manager component.

So maybe this should be reopened? Although some of the discussion points into the wrong direction by saying that explicitly ungrouping applications is the same - but that is not true...

So alternatively open a new bug report? I'm not sure...

What changed is Chrome - they broke their app identification again as they do regularly. We have a fix in 5.8.4. Kai?

Yup, Chrome broke it and I updated the mapping rules, will work again in Plasma 5.8.4 [1]. There was also a logic flaw in the code that I fixed [2].

[1] https://cgit.kde.org/plasma-workspace.git/commit/?h=Plasma/5.8&id=7c443aa53900521deab4fcd4641ea5273afc294e
[2] https://cgit.kde.org/plasma-workspace.git/commit/?h=Plasma/5.8&id=61860066a4cea845598fa4904607db1bba411356

(In reply to Kai Uwe Broulik from comment #41)
> Yup, Chrome broke it and I updated the mapping rules, will work again in
> Plasma 5.8.4 [1]. There was also a logic flaw in the code that I fixed [2].
> 
> [1]
> https://cgit.kde.org/plasma-workspace.git/commit/?h=Plasma/5.
> 8&id=7c443aa53900521deab4fcd4641ea5273afc294e

I already added this to /etc/xdg/taskmanagerrulesrc (it's the only file by that name on my system, so I'd expect it's the correct location). I restarted the machine to be sure it takes effect. But nothing changed: Chrome is still grouped no matter if I start it as web browser or as app container.

The browser shows this in xprop:

WM_WINDOW_ROLE(STRING) = "browser"
WM_CLASS(STRING) = "google-chrome", "Google-chrome"

One of the app windows (started from a .desktop entry created by chrome):

WM_WINDOW_ROLE(STRING) = "pop-up"
WM_CLASS(STRING) = "crx_ghajjjjboaaodcboidcanphmnidfikjb", "Google-chrome"

Desktop entry:

$ ~/.local/share/applications $ cat chrome-ghajjjjboaaodcboidcanphmnidfikjb-Default.desktop
#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Terminal=false
Type=Application
Name=Autotask
Exec=/opt/google/chrome/google-chrome --profile-directory=Default --app-id=ghajjjjboaaodcboidcanphmnidfikjb
Icon=chrome-ghajjjjboaaodcboidcanphmnidfikjb-Default
StartupWMClass=crx_ghajjjjboaaodcboidcanphmnidfikjb

I expect both windows having distinct icons on the taskbar.

> [2]
> https://cgit.kde.org/plasma-workspace.git/commit/?h=Plasma/5.
> 8&id=61860066a4cea845598fa4904607db1bba411356

Is this needed to fix the behavior? I could include it as Gentoo user patch and recompile...

Yes.

Okay, works... Gentoo backported some patches to 5.8.3 which didn't compile, I reverted back to the previous patch level with this patch included and now it works.

What I am missing is correct icons. That seemed to work previously. But I guess it is now working correctly because now it matches the icon from the KDE launcher.