Disable clipping of a QWidget by its parent.
I find myself in the situation that I have to create a QFrame which is not clipped by the bounding box of it's parent. Use case is that I need a custom menu which contains other widgets and not just Actions. As it says in the QWidget documentation:
bq. A widget is clipped by its parent and by the widgets in front of it.
However I have no clue how to disable this. Googling a bit and browsing the documentation I found out that there is a Qt::WA_PaintUnclipped flag. Setting this on the widget by using setAttributes(..) did not have any visible effect on the widget. Given that I have no idea how Qt's painting mechanism works I could use some help :)
Well when you just prevent the clipping, I guess your menu would still be clipped by the main window boundary. What you want is an additional window, not an additional widget in a parent window, like so:
@ QFrame *frame = new QFrame();
frame->setGeometry(20, 20, 400, 400);
See how I passed nothing to the QFrame constructor? That turns it into a new floating window.
The Qt::Tool flag makes sure an open instance of this thing doesn't keep the application running. What Qt::FramelessWindowHint does should be obvious: It tells the window manager to not draw any frame decoration.
Thanks for your answer. You suggest to just create a new window instead of a widget? Optically it's hard to tell that it's a new window if the flags are set as proposed and the signals, emitted from the frame window to the main window also update it even if the focus is set to the frame. I quickly tried it and it looks good. So the solution is that it is not possible (or not recommended?) to try to have a widget which should be drawn beyond the borders of it's parent?
I wonder how QMenu works then, because IIRC it has a parent and is drawn over the borders of its parent.
QMenu works exactly like that. It creates a new floating window independent of the main window paint event.
If Children were allowed/are allowed to paint beyond the parent or even window border, this would kill many optimizations such as efficient scrolling (by just moving a large portion of the content with a bitblit operation) and practically destroy the meaning of all bounding rectangles.
bq. QMenu works exactly like that.
Ahhh thx for enlightening me. But still when I click on the Window-Frame the main window looks disabled I wonder if there is a way to keep the other window on the top.
[quote author="jc-denton" date="1335811074"]But still when I click on the Window-Frame the main window looks disabled I wonder if there is a way to keep the other window on the top. [/quote]
I'm afraid I can't help you with that. Probably it's even impossible, since most operating systems don't allow multiple focuses. And as soon as you manipulate something in the frame, you'll probably want the focus there, not in the main window. This doesn't happen for normal popups since their controls don't take focus on click and even if they did, the popup closes right away, giving the focus back to the other window.
On a side note: You might want to set the widget attribute Qt::WA_DeleteOnClose on the frame, so you don't have to care about memory leaks (since we explicitly don't use Qt's parent-child-mechanism, which normally takes care of QWidget memory)
I have this problem that you refer to as: "Probably it’s even impossible, since most operating systems don’t allow multiple focuses" :)
My free floating QFrame act as some kind of tool window, containing UI elements. User can interact with it for sure. But as they click on it, the focus will shift from that main window. Currently I simply return back the focus to main window. But it gives unpleasant effect of titlebar flashing quickly.
I believe it's possible to be solved, as lots of Windows application have free floating window, in which while we click on controls inside it, the focus won't shifted.
Any idea on how to solve this?
"This is my question":http://stackoverflow.com/questions/24582525/how-to-show-clickable-qframe-without-loosing-focus-from-main-window?noredirect=1#comment38082228_24582525 in SO about this issue.