Lesson learned
Just learned that the window flags Qt::FramelessWindowHint | Qt::WindowStaysOnTopHint isn't enough in X11 (seems to work on WinXP). You also need to add the Qt::Tool window flag. Just so that you know.
Labels: Qt
Just learned that the window flags Qt::FramelessWindowHint | Qt::WindowStaysOnTopHint isn't enough in X11 (seems to work on WinXP). You also need to add the Qt::Tool window flag. Just so that you know.
Labels: Qt
12 Comments:
furthermore, on mac there's also different set of flags.
Do you know which?
We are just struggling with that on a Mac. showFullScreen on the mac still leaves the global menu bar that pops up when you move the mouse to the top edge.. Not sure how to get rid off that.
Just so that you know, I don't know what you're trying to do exactly, but I can tell you're very likely trying to do something wrong. The proper usage of Qt::WindowStaysOnTopHint on X11 is no usage. If you want to randomly play with window flags until it appears to work, don't come complaining if something doesn't work with KWin.
I want to achieve a frameless window on top of every other window across all platforms. Can you tell me how that is done with out using WindowStaysOnTopHint?
That's not a good description. With X11 windows you don't say what you want, you say what things are. So, what is that window supposed to be?
Hej, Johan :) Those flags are not enough. If the WM you're running on does not want to, your window won't stay on top no matter what. Try playing with QEvent::ActivationChange and raising the window instead.
The window is an on-screen numerical keyboard. I guess that tool makes it inter over my application, and the frameless removes the frame. Do you know where this is documented? (I'm probably blind)
So this is just for relation of two windows _inside_ one application? Qt::WindowStaysOnTopHint is _global_. It is enough to specify one window as having the other as parent, as for relevant window types such as the tool window the window is kept on top of the other one.
And please ignore the QEvent::ActivationChange nonsense. Window managers are called managers for a reason - if you wanted the same for a window globally, the X11 way would be using a window manager that doesn't suck - with KWin it is just removing the decoration and setting keeping above in the window specific settings (just like any other option the user desires).
Yes, I probably should write some doc on this. I'm just afraid nobody would really bother much with it anyway and only remember the kitten again.
@helder
of course, no code will ever be enough. You could write a WM that ignored all sorts of requests and did the opposite. Same with the activation change. If you listen for it and raise the window, there is no guarantee that the WM will actually do that.
But there is a reasonable expectation that when you tell the window manager to do something, it will get it done. And I think we don't have to worry about whatever obscure wm out there, but just the major ones (metacity and kwin).
@lubos So, what is that window supposed to be?
I develop specialized interfaces for people with disabilities. Some of these are always on top and full screen to serve as an "overlay" to the rest of the desktop, or to obscure the whole desktop.
Lubos, yes, it is for windows of the same application. I've got a full screen window running underneat an on-screen keyboard. The keyboard outputs through a custom FPGA block, so it is not really a keyboard in X11s sense.
Anyway - I was just wondering if there was a proper way to do this. Hinting to Qt that the window is supposed to stay on top seemed natural to me - telling Qt that it is a tool window seemed less natural. Especially since the frameless hint worked flawlessly.
Now, the target system will be running Qt for Embedded Linux, so this isn't really a huge problem, I just wanted to show the customer something that is as close to the end product as possible from a LiveCD.
Helder - that would have been my last resort, but Qt::Tool seems to do it...
Post a Comment
<< Home