Always keep group transients above
AbandonedPublic

Authored by zzag on Oct 15 2018, 7:51 PM.

Details

Reviewers
None
Group Reviewers
KWin
Plasma
Summary

The original intent behind not keeping non-modal dialog group transients
was to let the search window in KMail go behind the main window. See bug 76026.

But the proposed solution has some problems:

  • first, we're working around bugs/issues in KMail. The search window should not be a transient if one wants to put it behind the main window;
  • we're not following the EWMH spec: "Windows that are transient for another window should be kept above this window."

Even though the spec doesn't explicitly mention group transients, I
think that statement applies to them too.

Test Plan
  • Opened KMail;
  • Pressed the "S" key on my keyboard;
  • Clicked on an empty area in the main window;
  • (the search window didn't go behind the main window)

Diff Detail

Repository
R108 KWin
Branch
always-keep-group-transients-above
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 3917
Build 3935: arc lint + arc unit
zzag created this revision.Oct 15 2018, 7:51 PM
Restricted Application added a project: KWin. · View Herald TranscriptOct 15 2018, 7:51 PM
Restricted Application added a subscriber: kwin. · View Herald Transcript
zzag requested review of this revision.Oct 15 2018, 7:51 PM
zzag edited the summary of this revision. (Show Details)Oct 15 2018, 7:57 PM

I generally hold the view that we shouldn't work round KDE clients, but I'm very unconvinced in this case.

As for what kmail should have set. It's not modal, which means the author explicitly wanted the user to be able to interact with the main window whilst it is open.
Kmail does not set a transient, QtXCB does because it's of the window type.

In the bug reports listed, if you follow the dupes there are 3 applications affected.


Your quote is not from the spec, but in a compatibility notes section under the heading " the following layered stacking order is recommended, ".
The line after is "The window manager may choose to put some windows in different stacking positions"


Working with an old code base can suck, but the huge advantage is that we have the real-world experience with quirks and corner cases.

Out of curiosity, does this search window still appear in the task manager? That was cited as one of the rationals for the change.

zzag abandoned this revision.Oct 16 2018, 11:15 AM

Out of curiosity, does this search window still appear in the task manager? That was cited as one of the rationals for the change.

Yep, it still appears in the task manager.

Well, let's leave things as is then.