Hi all,

I hope I've got the right board here. Please let me know if not.

I've got an application that is not able to bring its own windows forward on KDE, unless "focus stealing prevention" is turned all the way off. This application is a bit of an oddball, since various parts of it are written using different GUI frameworks. So, for example, some windows are Qt-based, some are Java-based, and some are raw X11.

The problem we've got is if one of our Qt windows tries to open a Java window, the new Java window will come up "behind" the Qt window. So, maybe the user selects a "bring up the preferences dialog" menu. But, that preferences dialog (Java) comes up BEHIND the original window (Qt). Remember, both of these windows are from the same application! The same is true for, say raw X11 windows not coming up over Java, or any of the other combinations.

What I believe is going on is that KDE is erroneously concluding that our Java windows are coming from a different application than our Qt windows are, which in turn are coming from a different application than our X11 windows are.

It might be worth noting that each of these GUI frameworks is making its own call to "XOpenDisplay". In other words, there are three separate Display connections used by this single program.

So, my question: is there anything we can do, perhaps at XOpenDisplay time, that will let KDE be able to figure out that these windows are all from the same application? Or, can anyone tell me where in the KDE source code I can look to try to understand how KDE determines what windows come from what applications? Even just a pointer to the "focus stealing prevention" code, or its documentation, would be a big help.

Thanks for any insight you can give,
Tom

The seperate "XOpenDisplay" calls are very likely the cause of this. I would recommend talking to the KWin developers, who created and maintain this feature on their mailing list, kwin@kde.org

Thanks to bcooksley for pointing me to the KWin list.

I did get help over there, and I just wanted to follow up here in case anyone else is having a similar problem, and finds this page.

Thomas Lübking (from the KWin list) was kind enough to respond with some pointers:

> > The problem are likely different class properties on all windows.
> >
> > Check "xprop | grep -i class" on the windows in question.


In our case, the classes indeed did not match, but that was not the only
problem. I found the relevant source code in kwin/group.cpp in the
function Client::belongToSameApplication.

It turns out we had mismatches in the following properties, all of which
need to agree in order for KWin to allow focus "stealing":

_NET_WM_PID
_WM_CLIENT_MACHINE
WM_CLASS
WM_CLIENT_LEADER


I hope this information can help if anyone else bumps into a similar issue.


Thanks again!
Tom

Just in case somebody reads this when looking for a solution on how to do that in a KDE application, i.e. when the KDE application is the one opening the child window.

The only thing you'll need is the Window ID of the "parent" window, which you can then use with KWindowSystem::setMainWindow() to setup all hints correctly so your widget is associated as a child window of the given parent.

http://api.kde.org/4.x-api/kdelibs-apid ... 26f2969f52

Cheers,
_