On Samstag, 9. Mai 2015 14:59:38 CEST, Sebastian Kügler wrote:
Your email client doesn't line break, I have a wide-screen
monitor. What kind of crappy MUA are you using? (Muahaha, well played, Sir!)
outdated trojita affected by https://bugs.kde.org/337919 &
https://bugs.kde.org/show_bug.cgi?id=321462
What's important from my side is that we do not disturb
existing workflows of the default behaviour, we have to keep that in place.
(See wall of text email for details.)
The implementation, I don't care so much about as long as we can
free it from bugs in time for the next stable update.
Ok, since members of the HIG team previously asked for some behavior that
deviates from the exact former one, also we've some more flexibility - so
let's determine some cases first.
1. Keep Above windows (most prominently: yakuake)
----------------------
a) treat like "normal" windows (vanish, their activation breaks the state)
b) unconditionally keep visible (their activation leaves the state intact)
c) interchangeable with desktop (they go above and below the desktop
depending on the active window - does oc. not break the state)
2. Windows that "belong to the desktop" (same PID, eg. wallpaper dialog)
---------------------------------------
a) unconditionally keep visible (their activation leaves the state intact)
b) treat like "normal" windows (vanish, their activation breaks the state)
c) interchangeable with desktop (they go above and below the desktop
depending on the active window - does oc. not break the state)
3. Unminimizable windows (real cornercase, but can be forbidden)
------------------------
a) unconditionally keep visible (their activation leaves the state intact)
b) treat like "normal" windows (vanish, their activation breaks the state)
c) interchangeable with desktop (they go above and below the desktop
depending on the active window - does oc. not break the state)
4. Splash screens
-----------------
a) their showing-up breaks the state
b) ignore them
5. Break condition
-------------------
a) mapping + activation (mapping = "whenever a window is brought to
screen")
b) activation only (ie. the focus stealing prevention would also prevent
breakage. In case of "extreme" -the default is "low"- that implies only
explicit/forceful activation, eg. throught the taskbar, will break the
desktop showing)
c) forceful activation only (NOTICE: that this would break the pot. usecase
to show the desktop to click a file on it to have it opened, resp. that
opening would be stashed until the state is broken - unless the desktop
breaks the state itself on this occasion)
The answer to the above items used to be "a"
In case you answered "c", you may also define the initial behavior (ie. eg.
if you've only the wallpaper config dialog and press the "show desktop"
button, you likely want it to disappear at first, but if you entered the
mode and called it from the RMB menu, you do not necessarily want to break
the state to see it?
6. Krunner
----------
There's a long standing complaint about krunner breaking the mode. The KDE3
runner used to be part of the desktop group, but krunner became a process
of its own and was not moved into the desktop group by WM hints.
KWin will *not* try to detect krunner, but the latter could be set
transient for the desktop. Transient windows are in their main windows
group (thus did not get hidden nor break the state before) and are
naturally above them (that's the point of a transient ;-)
Cheers,
Thomas
---
ccbbb-transient
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
