Version: 2.4.3 OS: Linux In split view konsole should honour the focus policy of the desktop so if I have focus under mouse the the shell under the mouse should get input. However konsole only allows click to focus Reproducible: Always Steps to Reproduce: set focus under mouse on desktop, get konsole with split view - you need to click to focus on a particular shell Actual Results: set focus under mouse on desktop, get konsole with split view - you need to click to focus on a particular shell Expected Results: focus should follow mouse OS: Linux (x86_64) release 2.6.35.4-12-desktop-matt Compiler: gcc
What rule should be applied here? The current rule is that the _window_ below the mouse pointer gets focus. From what I understand, the _widget_ below the pointer should receive focus. If we change the rule, we have to be consistent and change it everywhere.
I'm not sure I understand this comment. My point is that the window and the pane should follow the main KDE focus rule (in my case focus under mouse) but the panes in konsole do not follow this rule (obviously the window as a whole does follow this policy). The Panes in konsole require click to focus even though the kde policy is focus under mouse. To be clear I think that is the kde focus policy is "under mouse" then the konsole pane under the mouse should get focus. As it is you have to click the pane to set the focus when moving the mouse between panes.
So currently in KDE, the focus policy is applied on the window level, not widget level, right? That explains the behavior quite well.
Sorry - I see the confusion - yes the focus policy should apply at this level (widget level) I guess if this means the separate panes get focused under the mouse... I can confirm this bug for kde 4.6
I think this is a wish and can only be implemented by kwin.
KWin cannot handle focus assignment inside toplevel windows. You'd have to read that setting from the kwin config so the only thing kwin could do here was to eg. set a property on the root window about the focus policy and/or emit a dbus signal clients could listen to. In case anyone wonders: tab focussing is handled by the widget style and anything but QEvent::MouseButtonPress will currently cause issues in at least some applications (notably konqueror) -> sending back to konsole
Well, I think it is overkill to provide this convenience in a terminal emulator which is natually keyboard biased. And konsole already provides the "Next View Container" action for switching focus to next view container(default shortcut is Shift+Tab). So I will close it as WONTFIX.
I disagree - you are simply refusing to honour the desktop focus policy. Surely there is a mouseover event that the pane can detect?