Sometimes I'm forced to do a service kdm restart. Here's the bug I'm concerned about - after restarting kdm (and certain other instances I haven't yet quite identified), my chrome windows don't stack. If I right click and open the Window Manager Settings, the windows fix themselves even though I don't change the settings. Just the action of opening the settings window is enough to trigger whatever mechanism forces them to their proper place. I have 7 separate instances of chrome running. I get the exact same behavior with everpad, and konsole as I also have many of each of these windows running and they should stack, but don't until I open the window manager settings, hit OK or Cancel without making any additional changes and then they stack. Reproducible: Always
I forgot to mention, I don't know if it's related but all of the chrome browsers are tabbed together in one big group and I have to untab them to separate them from each other. After untabbing, sometimes they pop to their assigned virtual desktop, but most of the time they don't. Here I'm using window matching in their settings to force them to the proper desktop - this is already setup and should "just work", but again - they don't go to their assigned desktop until I open the window manager settings and hit OK or Cancel.
Just to clarify the above comment - I do NOT want the browsers tabbed together and autogroup settings are NOT set.
Created attachment 84202 [details] activity, xwininfo & xprop settings
are the windows tabbed by kwin or chromium? (can you provide a screenshot of the tabbed windows?) please attach your ~/.kde/share/config/kwinrulesrc
The windows are tabbed by kwin. chrome has it's own set of tabs, but I know the difference and that's NOT the set of windows I'm talking about. Still want a screenshot?
Created attachment 84214 [details] ~/.kde/share/config/kwinrulesrc
By the way... I stated "window manager settings" above... I meant "Special Window Settings" and "Special Application Settings"... not window manager settings. Sorry about the confusion.
Notice at the bottom, chrome has multiple icons indicating those are NOT stacked. Once I open "Special Application Settings" or "Special Window Settings" and then close again with OK or Cancel, the icons stack themselves as I would expect. I'll attach another screenshot showing the corrected behavior.
Created attachment 84215 [details] Screenshot of desktop showing NON-stacking behavior icons not stacked properly. Notice how the chrome icons at the bottom are spread out horizontally. I would expect to see only 1 chrome icon, and when moused over, to expand vertically showing the stack of chrome windows.
Now it's making a liar out of me... at the moment I'm unable to get the stacking behavior by simply opening either of the settings windows I mentioned, even though that's what was happening for over a week.
Please make note that all of this discussion so far has actually been about the stacking behavior - not the tabbing behavior. I had only mentioned the tabbing in the start, as I didn't know if there was any relationship between the two behaviors.
Created attachment 84220 [details] Unwanted autogrouping behavior Well it didn't take long for kwin to crash and force me to restart kdm. So I'm attaching the autogrouping behavior I mentioned. Notice the gray windows across the top. Those are all autogrouped - but shouldn't be. I'm NOT talking about the chrome browser tabbing feature, that's different and works as it should.
By the way - the window system is using "Attach as tab to", "Switch to tab" and "untab", with the underlying mechanism labeled as "Autogroup". May I suggest one terminology be used - either "Tab" or "Group", not both since they seem to be the same in this context. Just a thought.
(In reply to comment #5) > Still want a screenshot? No, but please understand that we first need to be sure about the issue and there's enough people who would not know or understand the difference. (In reply to comment #6) > Created attachment 84214 [details] > ~/.kde/share/config/kwinrulesrc Thanks, explains things. (In reply to comment #7) > By the way... I stated "window manager settings" above... I meant "Special > Window Settings" and "Special Application Settings"... I thought so after seeing the rules, yes.... Ok, what's going on: You've a bunch of rules for chrome windows with particular titles, distiguished only by those titles actually. When chromium starts, it will in case not initially pass the windows those titles but sth. like "unknown", then load the page and update the title. So when the window appears, the rule doesn't match and isn't considered. The windows appear on the same desktop and since you'll (very likely...) use "autogrouping", they'll be tabbed together. When editing rules, the dialog will send kwin a notice to update rules, kwin will re-evaluate the rules, the titles of the present windows now match and everything acts as supposed. -> wish/bug #220227 You can prevent autogrouping for chromium windows by setting up a rule that matches all chromium windows and "Force" autogrouping to "No" Chromium windows will then appear stacked, but on the same desktop. Unfortunately, it does not seem as if chromium woul support a "--title" switch. -> What you want to do can so far only be done through a script: http://techbase.kde.org/Development/Tutorials/KWin/Scripting/API_4.9 ---------- As for everpad, you got two kinds of rules: 1. > autogroup=true > autogrouprule=2 This will force all everpad windows to autogroup 2. > autogroupid=PhoneGroup > autogroupidrule=2 This will put the matching windows (title driven again) to be grouped with SFLphone in the PhoneGroup I assume that you wanted to force autogrouping (with other everpads) to "false" and also that you may run into the same titlematch issue reg. grouping with SFLphone. In general please notice that upper rules trump lower ones, but that grouping by ID always takes precedence over autogrouping. So if you wanted to manipulate ID based grouping by the autogroup rule, that doesn't work. Instead create an upper "Do not affect" rule to "clear" the lower rule for a more particular client. --- I did not see any rule for konsole windows, they'll just group for the global setting in "kcmshell4 kwinoptions", "Advanced" tab. Tagging as dupe, everything else seems boiling down to "unwanted global autogrouping" or "how do rules work in particular" - for that see: http://userbase.kde.org/KWin_Rules or http://docs.kde.org/stable/en/kde-workspace/kcontrol/windowspecific/index.html *** This bug has been marked as a duplicate of bug 220227 ***
(In reply to comment #12) > Well it didn't take long for kwin to crash and force me to restart kdm. If kwin crashes, it simply restarts (and you'll get a dr. konqui dialog which you should please use to file a bug). It's more likely that the X11 server crashed because that will get you back to KDM