Bug 255052

I know this is not a very important issue but is there any chance this might get resolved?

the "lower window" / "raise window" shortcut indeed drops the focus, while the "toggle lower/raise" shortcut does not.
Clicking the titlebar toggles the focus.

No idea, but there's a chance that this was intended implicit behaviour for the actions. -> Gonna have a look later this day ;-)

code comment:
        // As this most likely makes the window no longer visible change the
        // keyboard focus to the next available window.

so it's inteded behaviour, personally i don't see this justified (only relevant for non mouse driven focus policies & just activating the most top client is a bit arbitrary either) but wouldn't call it a bug either.

Marking as wish, Martin has to decide ;-P

@hvm
The toggleRaiseLower shortcut does not exhibit this behavior, if this fits you, you might as well close the wish and resolve martin from taking a random decision ;-)

Well the shortcuts are not consistent then, it would be nice for all of them to work the same. 

I'm not complaining though, you gave me a pretty good solution, it's just I really liked the workflow when I could use those 2 shortcuts. It's better because you don't have to think whether the window you have focused is at the bottom or top. Also, with toggleRaiseLower you can't lower a window in the middle of the stack (they get raised, you can lower them with a second keypress).

I'm also a little concerned that sometime later, the behaviour of toggleRaiseLower will change to match the other two :D

So, if it's not too much trouble, I'd like to keep the report open for now.

(In reply to comment #3)
> code comment:
>         // As this most likely makes the window no longer visible change the
>         // keyboard focus to the next available window.
> 
> so it's inteded behaviour, personally i don't see this justified (only relevant
> for non mouse driven focus policies & just activating the most top client is a
> bit arbitrary either) but wouldn't call it a bug either.

I've been using the lower shortcut for years under 3.x and the behavior change is certainly a little unexpected. I'd call it at least almost-a-bug... :)

Having two different behaviors for 'lower' ... one for 'toggle lower' and one for just 'lower' doesn't seem quite right. And as a side note: lower_and_lose_focus doesn't work for my workflow at all.

> Marking as wish, Martin has to decide ;-P
> 
> @hvm
> The toggleRaiseLower shortcut does not exhibit this behavior, if this fits you,
> you might as well close the wish and resolve martin from taking a random
> decision ;-)

The toggle is a good enough workaround for me, although I'd prefer the old behavior --- Just one user's opinion --- thanks!

Thank you! Finally someone who understand me :D

*** Bug 294019 has been marked as a duplicate of this bug. ***

https://git.reviewboard.kde.org/r/103975/

Uhm, doesn't MouseLowerOp refer to lowering the window with the mouse? I'm talking about lowering the window with the keyboard shortcut "lower window" from the kwin shortcuts.

Or are you saying that the keyboard shortcut somehow uses the same code to lower the window thus making the next active window the one under the mouse?

No, sorry - actually the code is more or less just doubled there.
The changes were introduced because of bug #182146

We'd however need a different heuristic for the keyboard shortcut - it's basically a matter of reading the users brains ... :-(

Why don't then have separate actions: Lower, and Lower and Blur (or Lower and Adjust Focus)?

Or keeping focus in the window under the mouse could be also good decision. 
If after you have lowered window it is still under the mouse then the window may stay active (nothing covers it at lease where mouse is => it is not confusing).
Otherwise, if another (second) window is now becomes the mouse (which means that it is covering the first window) it is not so confusing to switch focus to the second window. Especially if we have Focus under mouse policy.

When we do it with keyboard... well, it's harder, because some users may in this situation completely ignore mouse. And therefore it is better to have actions separated to allow users to tune settings (have Lower for mouse action and Lower and Blur for one hot key, and keep Lower for another hot key).

That's what I was saying. When I use the "lower window" keyboard shortcut I still expect that window to have the focus because I set all my focus policies to ignore the mouse. I'd really like the old (KDE's 3.5) behaviour back.

FTR
----

At least IceWM and OpenBox indeed act like the current shortcut implementation (on alt+esc)

This seems to be (and demanded as) however some sort of "inverse tabbox" and does actually not fit the shortcut title (see bug #182146 and following http://lwn.net/Articles/316860/) so to me it seems a feature request was implemented as behavioral change - between KDE 4.2.0 and 4.2.1 (so in a minor release...) and leading to an inconsistency regarding the toggling shortcut.

Since this means a regression and because the alt+esc shortcut seems a valid feature request (common among some WM, not compiz though) I'll propose a patch to introduce the current behavior as new feature and restore the former behavior.

However since this requires the addition of a new visible string (requires translation) this has unfortunately to wait for 4.9.

Changing the behavior right now and re-introduce the current behavior is not an option (to me) since it would mean another regression and I was educated in the sense that doing wrong to fix sth. wrong is still doing wrong.

OK. Good enough. I'll keep in mind to check it out when 4.9 comes out. Thank you for your patience regarding a tiny little detail like this :)

Also, make sure it's not the "toggle raise/lower" keyboard shortcut. It's the "lower window" shortcut. The toggle one maintains the old behaviour for some reason. Maybe that's what you meant but I wanted to be sure.

Git commit c4e133e5008f73f46da9654011bcc71748a92aaf by Thomas Lübking.
Committed on 13/02/2012 at 23:50.
Pushed by luebking into branch 'KDE/4.8'.

Focus window under mouse after MouseLowerOp
REVIEW: 103975

M  +23   -16   kwin/activation.cpp
M  +12   -8    kwin/useractions.cpp
M  +2    -0    kwin/workspace.h

http://commits.kde.org/kde-workspace/c4e133e5008f73f46da9654011bcc71748a92aaf

*** Bug 324297 has been marked as a duplicate of this bug. ***

re-opening as the shortcut wish for plain lower behavior w/o any focus alteration is still open - however i guess this is rather a candidate for "bring your own script"

What do you mean by "bring your own script" ?

writing a kwin script to lower the window and binding a shortcut to it

Hmm, I didn't know I could do that. I'm going to look into it, thanks.

Fixed by thirdparty script - install via "kcmshell4 kwinscripts" / "Get new scripts" -> "Lower active window"
http://kde-look.org/content/show.php?content=161046

wow, very nice. Thank you :)

I am glad we can add a third party script to fix this issue. But it is not common sense that you select in KDE system settings options to order the alt tab function by "recently used" and you have the current behaviour. 

"Recently used" does not imply whether the window is minimized or not. So I call this a bug, or at least a poor explanation of the "recently used" option for the alt tab function.

Regards.

Also, the third party plugin for kwin is not working as expected. It does not work if there are more than one windows maximized. 
I would consider reopening this bug, because it really breaks the work flow on Plasma Desktop.

I mean, the third party plugin does not work at all in Plasma 5.12.5.

Hmmmm, the plugin works but only using a shortcut to minimize. It would be a lot more preferable to be able to minimize with the mouse instead.

Actually I am not sure if this bug is about the thing that I have in mind. The thing I am referring to is explained in this post: https://forum.kde.org/viewtopic.php?f=289&t=143414