Hi,

I have a problem with window navigation. Alt+Tab window switching works but without any visual effects even though they are set.

In "Navigate Through Windows" in system settings, everything is greyed out and it says "Focus policy settings limit the functionality of navigating through windows.". Unfortunately, I haven't been able to find out what it is even talking about.

Desktop effects and compositing are turned on, the "Cover switch" effect is selected (I tried all of them and none work, not even "box switch").

I'm happy about any help!


Using KDE 4.4 from the Factory Repo on openSUSE 11.2.

well you are using focus (strictly) under mouse. Alt+Tab only provides effects if you are using click to focus or focus follows mouse. You find these settings in module "Window Behaviour" in dropdown "Policy"

Oh, ok! Checking it I notice that it's actually just "Focus under Mouse", and it doesn't work with "Focus follows Mouse" either.

Two questions: 1. Why? 2. Didn't this work in earlier versions of KDE 4?

Ok, I guess I have a third question. I have always liked that I don't have to use "Click to Focus" in Linux. Is there a way around this?

But it's cool to know what caused it and finally have some more eyecandy again, thanks!

alvanx wrote:Oh, ok! Checking it I notice that it's actually just "Focus under Mouse", and it doesn't work with "Focus follows Mouse" either.

It should work with Focus follows Mouse. I guess you have to restart systemsettings after applying the change. The other modules are not notified about config changes.

alvanx wrote:Why?

Focus under mouse limits the number of windows you can switch to with Alt+Tab. It doesn't make sense to switch to a window which is not under the mouse. With those focus policies the normal Alt+Tab is not even activated. But on each press of alt+tab the next best matching window is selected. So the code which activates the effects for alt+tab is never reached.

alvanx wrote:Didn't this work in earlier versions of KDE 4?

No, that has never worked. But the config options used to be enabled before 4.4.

alvanx wrote:Ok, I guess I have a third question. I have always liked that I don't have to use "Click to Focus" in Linux. Is there a way around this?

Using focus follows mouse has severe disadvantages. Focus (strictly) under mouse is even worse. Those two policies are referred to as "unreasonable" focus policies. But as said: alt+tab effects and focus follows mouse should work

You're right, it does work. Thank you for that lengthy explanation.

Just out of interest: What are those disadvantages you are talking about? I find "Focus follows Mouse" very practical say when I have two parallel windows open and I frequently scroll in both (which happens a lot actually). The only disadvantage I can think of is that popup windows (like password prompts, etc.) aren't autofocused when they come up.

alvanx wrote:What are those disadvantages you are talking about?

For example it's difficult to use all those Plasma popups which close themself when losing focus.

With respect I must take issue with you classing "Focus under mouse" as "unreasonable"... it might indeed, make life difficult for you as a Plasma/KDE developer, but for me as a user, it makes perfect sense. I frequently (bordering on "usually") type into windows that are not the current frontmost window (and often partially obscured). It also happens quite often that the mouse slides away from the window I am busy with, but not so far as to trigger focus shifting to another window, and that means that the focus of my attention/keyboard remains where I want it.

Then again, I am of a generation (gen-X-windows?) used to having many windows open in a desktop at once, and not so brainwashed by Microsoftian "every window maximised" ways of working

Just trying to add some "user perspective" on this...

focus (strictly) under mouse is not tagged "unreasonable" but as "unreasonable focus policy" because there's no actual focus management (focus chains etc. make little sense)

You may want to try "focus follows mouse" and set the (so far, gui promised for 4.11 - really "hidden" config key:
kwriteconfig --file kwinrc --group Windows --key NextFocusPrefersMouse true
qdbus org.kde.kwin /KWin reconfigure

what is quite similar but will allow focus chain and thus tabbox invocation and autofocus on new windows (limitable through focus stealing prevention)

Plasma extenders act annoying with mouse driven focus policies, but that actually points out some defects in their GUI concept (and is somewhat manageable with increased focus delays)

It is *not* necesary to pass the focus in order to wheel on a window - the wheel is always forwarded to the client by kwin.

PS and inc ase that isn't clear: "unreasonable focus policy" is diction in code and comments, ie. for developers - not in the GUI and therefore not an official statement on this (well, so far =)

I respect all the work that goes on behind the scenes with KDE, and the anomalies thrown up for "an unreasonable focus policy", but as a mere (long time) user killing Alt-Tab is a major pain. I've been so impressed with the update from opensuse 12.1 to 12.2, but this change in KDE behaviour is one of just two snags I hit. Seemingly trivial, it affects me many times a day. I'd often use this as a shortcut to cycle through to an open piece of reference documentation and then revert back, mouse position unchanged, to the email or task at hand. I think I've done something similar for more than twenty years on iterations through proprietary and free desktops. I can't see what change to my workflow could benefit from outlawing this by policy. Surely a keyboard instruction is othorgonal to the mouse policy?

Conversely, I sit at a keyboard swimming in functionality that I don't scratch. The things I missed leaving Solaris in the 90's were the front & back buttons on my 5c keyboard , and yet I have similar buttons that have sat next to my pinky for the last few years, on my ultra comfortable cordless logitech wave keyboard. I'm sure I could get the buttons working, but multimedia keyboards, and in fact pretty much any commodity (ie it had an M$ logo etched onto it in the mid 90's) keyboard seems to demand one jumping through a never ending series of hoops to get short-term relief until something else in the key-modifier/input/X/desktop stack breaks with a seemingly unrelated software update. Like many users, I guess I just can't be bothered and want to get on with work and will use familiar habits to make progress.

I don't see why Alt-Tab window cycling is mutually exclusive with yet another plasmoid or annoying nag widget, and this change seems to be a regression from a user perspective.

killing Alt-Tab is a major pain

I'm not entirely sure about what you mean by this, but assure that alt+tab has *never* (not even in KDE3 times, actually unsure about KDE2) worked with "Focus under Mouse" or "Focus strictly under mouse" policies.

The comments about those policies being "unreasonable" exist since KDE 3.0

Otherwise, Alt+Tab has not been withdrawn or sth. like that.
"Focus Follows Mouse" is the hybrid which behaves quite like "Focus under mouse" but also manages and prefers a focus chain.

Surely a keyboard instruction is othorgonal to the mouse policy?

No. Their outcome is not.
If the focus is supposed to be on the window under the mouse, it cannot be on some other random window at the same time.
It can however be if it only follows the mouse (ie. ex- and/or implicit crossing events)

I'm sure I could get the buttons working

X11 should support pretty much every key - at least evdev could theoretically map everything the kernel notices everywhere. That's however not a KDE issue (except maybe for the keyboard selection config dialog)

I don't see why Alt-Tab window cycling is mutually exclusive with yet another plasmoid or annoying nag widget

I don't know what that means or where you got it, but it's wrong. Alt+Tab cycling is mutually exclusive with two very specific focus policies (which make the desktop behave more or less like naked X11). That's it.
If sth. else does not work, ask for help and in doubt report a bug, but whatever plasmoids are on your desktop, the WM does not care the least.

After few hours of scratching my head asking myself why alt-tab stopped working
I found this thread. And I am extremely disappointed after having read it.
"Focus under mouse" is for me personally the most reasonable focus handling.
The reason is, I often send to the back the window which I don't need now
and want the window the mouse pointer is now on it to inherit the focus.
After several years using other Desktop Environment I gave KDE another
try and my first impression was extremely positive (4.9.2).
Than I had to learn that I'm using a "unreasonable focus policy" and so I
don't have rights to use one of the most important WM feature.
Whatever the technical reason might be. It's pity.
I totally agree win danielm.

Use "Focus follows mouse" - it'll do what you want.
The "technical" reason isn't technical at all. If the focus is where the mouse is, alt+tab will have nor reasonable effect (but for the cornercase of switching between overlapping windows with the mouse above both)

"Focus follows mouse" is not doing what I want.
If I have three windows on my screen, Settings overlapped by two overlapping Konsoles.
(I tried with three other windows as well)
If I press raise/lower key when on the topmost Konsole it goes to the back, second one
gets the focus (mouse is on it), I press raise/lower again, the console goes behind Settings window but
it keeps focus. Mouse pointer is on the top most window (Setting) but without focus.
I have to click it or "re-enter" it with mouse pointer to give it focus.
With "Focus under mouse" it work as expected.
The difference between those two is quite subtle but it is there.

What I expect from alt-tab (unless I misunderstood it completely), is to just walk through all windows
on my screen and expose each one after other with whatever special effects are defined, not less and not more.
And this despite any focus settings.
It's why I don't understand all those reasons given here for not doing that, sorry.

Update to a somewhat recent KDE:
https://bugs.kde.org/show_bug.cgi?id=255052

There's also
kwriteconfig --file kwinrc --group Windows --key NextFocusPrefersMouse true
to make FFM more like FUM - but it's not required for this action.

Once again: if the focus is determined by the mouse it /cannot/ be determined by some other action like alt+tab.
If you don't understand the logic conflict in this, i'm sorry but can't help you.

Please update KDE and use FFM (alongside above key or not) - FUM and FSUM are mostly provided for legacy reasons an more or less reflect the unmanaged (naked, no WM) behavior of X11.
They're most unlikely what you want to use and the can for absolutely sure NOT work with the tabbox - or they'd implicitly become FFM.