https://bugs.kde.org/show_bug.cgi?id=315488
GaryM <garymarty...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |garymarty...@gmail.com
--- Comment #26 from GaryM <garymarty...@gmail.com> ---
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?
--
You are receiving this mail because:
You are watching all bug changes.
