Bug 345924 - KF/5 versions no longer set WM_WINDOW_ROLE
Summary: KF/5 versions no longer set WM_WINDOW_ROLE
Status: RESOLVED UPSTREAM
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: 3.0.1
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-06 17:03 UTC by Brook Harty
Modified: 2015-05-21 19:00 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Kubuntu 1504 - Latest showing window specific settings. (362.54 KB, image/png)
2015-04-06 20:36 UTC, Brook Harty
Details
Kubuntu 1410 - showing each window has different windows settings (504.76 KB, image/png)
2015-04-06 20:37 UTC, Brook Harty
Details
ubuntu 14.10 - kwin window matching (354.54 KB, image/png)
2015-04-08 21:02 UTC, Brook Harty
Details
ubuntu 15.04 - kwin window matching (486.35 KB, image/png)
2015-04-08 21:03 UTC, Brook Harty
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brook Harty 2015-04-06 17:03:48 UTC
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.
Comment 1 Thomas Lübking 2015-04-06 17:29:19 UTC
> 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?
Comment 2 Thomas Lübking 2015-04-06 17:40:07 UTC
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.
Comment 3 Brook Harty 2015-04-06 20:36:59 UTC
Created attachment 91911 [details]
Kubuntu 1504 - Latest showing window specific settings.
Comment 4 Brook Harty 2015-04-06 20:37:36 UTC
Created attachment 91912 [details]
Kubuntu 1410 - showing each window has different windows settings
Comment 5 Brook Harty 2015-04-06 20:38:48 UTC
Uploaded photos from Kubuntu 1410 and 1504 showing how KDE no longer see the position/size for each window like before.
Comment 6 Thomas Lübking 2015-04-06 20:50:02 UTC
The important tab is "window matching".
Comment 7 Thomas Lübking 2015-04-06 20:50:48 UTC
(Only required from 15.04)
Comment 8 Brook Harty 2015-04-08 16:25:59 UTC
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?
Comment 9 Thomas Lübking 2015-04-08 18:39:46 UTC
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!)
Comment 10 Brook Harty 2015-04-08 21:02:14 UTC
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.
Comment 11 Brook Harty 2015-04-08 21:02:52 UTC
Created attachment 91956 [details]
ubuntu 14.10 - kwin window matching

ubuntu 14.10 - kwin window matching
Comment 12 Brook Harty 2015-04-08 21:03:10 UTC
Created attachment 91957 [details]
ubuntu 15.04 - kwin window matching

ubuntu 15.04 - kwin window matching
Comment 13 Thomas Lübking 2015-04-08 21:25:25 UTC
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?
Comment 14 David Edmundson 2015-04-08 22:14:06 UTC
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.
Comment 15 Thomas Lübking 2015-04-09 05:24:06 UTC
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?
Comment 16 David Edmundson 2015-04-09 14:56:22 UTC
Done https://bugreports.qt.io/browse/QTBUG-45484