This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Programming: window activation under KWin4 problem

Tags: kde4, kwin, kwin4, activate, window, activatewindow, xsetinputfocus kde4, kwin, kwin4, activate, window, activatewindow, xsetinputfocus kde4, kwin, kwin4, activate, window, activatewindow, xsetinputfocus
(comma "," separated)
User avatar
pdabrowski
Registered Member
Posts
12
Karma
0
OS
Hello,

I'm using KDE 4.3 (under VirtualBox, disabled 3D effects).

I need to activate one of my Qt4 application's window.
However, if another window is already active, KWin acts strangely. It activates my window for a very short time, then returns the focus to the previously active window and marks my window as Demanding Attention (taskbar item flushes).

I tried both QWidget::activateWindow() and XSetInputFocus().

How do I activate my window under KWin4?
User avatar
bcooksley
Administrator
Posts
19765
Karma
87
OS
KWin includes technology to prevent focus being stolen by any application. What is the use case for forcing your application above all others and interrupting any work the user is doing?

Note that it is general accepted practice to not disrupt the user by stealing focus but to send them a notification ( using KNotification ) if needed to inform them of what requires their attention.


KDE Sysadmin
[img]content/bcooksley_sig.png[/img]
User avatar
pdabrowski
Registered Member
Posts
12
Karma
0
OS
I agree focus stealing prevention is generally a good idea.

But in this case focus change is what user expects, as it's a reaction for user pressed global hotkey.

I think there should be some way of forcing window activation.


EDIT:

The problem seems to be related to the way KWin handles the hotkeys.
Activation works perfectly when invocated randomly from the code.
However when I type the hotkey inside of another window, my window handles it and gets activated, but KWin thinks it has stolen the focus of the previous one. KWin should notice that the previous window did not actually received an event, and do not consider it focus stealing.

There is also a bug in current behaviour: focus is given back to the previous window, but QWidget::isActiveWindow() still returns true for my window. (KDE 4.3, I haven't tested later versions).
User avatar
pdabrowski
Registered Member
Posts
12
Karma
0
OS
I have solved the problem by checking how does Amarok 2.3 handle this.

If somebody ever needs this:
It calls KWindowSystem::activateWindow() which uses NETRootInfo::setActiveWindow() sending this X event:
Code: Select all
Atom net_active_window = XInternAtom( display, "_NET_ACTIVE_WINDOW", False );
XEvent e;
e.xclient.type = ClientMessage;
e.xclient.message_type = net_active_window;
e.xclient.display = display;
e.xclient.window = window;
e.xclient.format = 32;
e.xclient.data.l[0] = 2l;
e.xclient.data.l[1] = CurrentTime;
e.xclient.data.l[2] = None;
e.xclient.data.l[3] = 0l;
e.xclient.data.l[4] = 0l;
XSendEvent( display, DefaultRootWindow( display ), False, SubstructureRedirectMask|SubstructureNotifyMask, &e );
Quite obvious now. How could I doubt in KDE folowing freedesktop.org standards ;)


Yet I have to report a little plasma taskbar bug:
When activating window in the above way, KWin(?) sometimes marks it as Demanding Attention just before truly activating it. If you have your taskbar panel hidden, this results in showing and instantly hiding the panel. It's quite annoying.
Maybe the taskbar should wait several hundreds milliseconds before marking an item as Demanding Attention and showing itself?
User avatar
bcooksley
Administrator
Posts
19765
Karma
87
OS
I would recommend filing a bug at bugs.kde.org as there is quite clearly a bug in KWin / Plasma in that case.


KDE Sysadmin
[img]content/bcooksley_sig.png[/img]
User avatar
pdabrowski
Registered Member
Posts
12
Karma
0
OS


Bookmarks



Who is online

Registered users: bancha, Bing [Bot], Google [Bot], Sogou [Bot]