If you create a special windows per window. Historically you can use it to place multiple konsole windows per window , it detects the second konsole opened as <2> And tigervnc, has 3 windows, login/password/main windows, new "special window setting" only sees 1 settings for all 3. It seems to no longer detect each specific window. Reproducible: Always Steps to Reproduce: 1. Open Konsole (twice) 2. Open "special window setting" on first settings from corner, set position and size. 3. Open "special window setting" on second window, settings are already populated. (Id should be a new profile for each sub window!) Actual Results: "special window setting" defaults to all application, not exact window. Expected Results: Each sub window. "special window setting" worked in kubuntu 14.10, does not in 15.04.
> Historically you can use it to place multiple konsole windows per window , it detects the second konsole opened as <2> No, certainly not. The "<2>" is part of _NET_WM_VISIBLE_NAME, not _NET_WM_NAME, but added by KWin Matching _NET_WM_VISIBLE_NAME would be totally random (aka useless) I also just tried the SC4 rules dialog to be sure about this behavior. > And tigervnc, has 3 windows, login/password/main windows This might be an issue with the toolinvocation (passing the parameter to control the match precision) - see other bug (you're lucky to get a dialog at all) - what match elements (first tab) are enabled?
but konsole sets different roles for different windows of the (by default invocation) same process... :-) So detection can be expected, but by role, not title.
Created attachment 91911 [details] Kubuntu 1504 - Latest showing window specific settings.
Created attachment 91912 [details] Kubuntu 1410 - showing each window has different windows settings
Uploaded photos from Kubuntu 1410 and 1504 showing how KDE no longer see the position/size for each window like before.
The important tab is "window matching".
(Only required from 15.04)
No, its not luck it use to work properly. Thats why I took the screen shots. Window matching is auto populates the information, it just no longer works in the 5.x series rules. Is this the proper section for the bug? Also what does it take to get switched to confirmed?
See comment #2 I got "irritated" by the suggestion that matching _NET_WM_VISIBLE_NAME would fail what *is* a totally random match that could only apply by luck, but konsole sets different WM_WINDOW_ROLE's for each window (in one process) what is the actual match you're looking for and what apparently fails. Also see comment #6 - the relevant tab is the first one, what settings you rule and whether they're equal is irrelevant. Another info that might turn out interesting is the output of ps fax | grep -C3 kwin_rules (while a special window settings dialog is shown!)
The "Window Matching" rules are indeed different default on the newer kwin. So I tried what you said, I applied the same 4.x window rules to 5.x, no go, it didnt fix the issue. In 4.x Window Role has an exact match with a window number "mainwindow#1", etc. and window title marked as "Unimportant" In 5x. Window Role has Unimportant, and Window Title has exact match of "kbuntu:bash" Attaching the windows kwin-4 and kwin-5 photos of each.
Created attachment 91956 [details] ubuntu 14.10 - kwin window matching ubuntu 14.10 - kwin window matching
Created attachment 91957 [details] ubuntu 15.04 - kwin window matching ubuntu 15.04 - kwin window matching
This is a client issue. Konsole 3.0.1 - nor kwrite 5.0 - (the KF/5 versions) does not longer set WM_WINDOW_ROLE. Therefore the match is set to unimportant (the value is empty anyway) and all windows (their title is initially the same) appear totally equal. Passing to konsole, but this might be an issue with QMainWindow?
Had Qt5 open anyway, so I had a look, seems you're pretty much right. the WM_WINDOW_ROLE atom is declared in the Qt XCB backend but never used. a breakpoint on QWidget::setWindowRole shows that's being called, so apps are doing the right thing. This sets a private property on a private QWidget internal class, but does nothing with it. WindowRole will need adding to QWindow, QPlatformWindow and then the XCB backend. Either way, definitely seems like a bug in Qt5 from the widget/GUI split.
Actually it does nothing, have a close look on #if defined(Q_DEAD_CODE_FROM_QT4_X11) ;-) Neither is ::setWindowRole() implemented in QWidgetPrivate. Did you file a Qt bug?
Done https://bugreports.qt.io/browse/QTBUG-45484