https://bugs.kde.org/show_bug.cgi?id=396421
Bug ID: 396421
Summary: unshading a window should (probably) raise it to the
front
Product: kwin
Version: 5.12.6
Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: kwin-bugs-n...@kde.org
Reporter: kd...@osndok.com
Target Milestone: ---
Created attachment 113889
--> https://bugs.kde.org/attachment.cgi?id=113889&action=edit
freshly-unshaded window hidden by its neighbors
This probably isn't noticed in the default configuration, as the first click of
double-clicking a titlebar to unshade a window will also raise that window.
However, if one uses the mouse-wheel to shade/unshade windows (which has being
able to densely-pack still-usable windows in-place), the window *OFTEN* is
obscured by the adjacent shaded windows when unshaded. In practice, the most
frequently used window will statistically be on top, but it can still be quite
a nuisance.
(I have attached a screenshot of this effect)
I'm sure it sounds trivial, as the workaround would be to simply click the
titlebar again that is under the mouse (like bug#8005), but I find that there
is something odd about this mouse-wheel-to-button lateral movement that
discourages any sort of haste, even with repetition.
So I'm a bit stuck... on the one hand, I *can* just set the double click action
to be window shading (and avoid the odd/slow finger motion), but then I would
lose other productivity boosts like double clicking to make the window appear
on all desktops, and a peculiar benefit of quickly shading windows en-mass by
moving the mouse position & wheel at the same time.
It would be nice if there was an option, default, window-rule-boolean, or
plugin to simply raise windows when they are unshaded.
--
You are receiving this mail because:
You are watching all bug changes.
