The invisible QApplication
-
@Moose2342 said:
I want a show() that doesn't show.
I'm quite new to Qt. Please explain why setting the widget geometry (X, Y) to negative values doesn't take the widget off screen .. effectively hiding the widget?
-
Hi
If a Widget is hidden it gets no paint events as far as i know.One thing you could test is the render() function
http://doc.qt.io/qt-5.5/qwidget.html#renderIt lets you draw a widget directly to pixmap so I think it can work with hidden
widget but never tested it.QPixmap pixmap(mywidget->size());
mywidget->render(&pixmap);I know u already use render() but I wonder if u tried calling it directly, not using paintevent at all?
One thing that could also be issue is that while hidden , it do not receive resize events
so might be of wrong size even if Render() does work.Maybe you already tested all this. Just asking :)
@mrjj Yes, I tried calling this directly. It only produces an empty buffer though. I suppose this is due to the widget in question being quite complex.
It is a QWebEngineWidget.
It creates a lot of underlying child widgets and they pass their sizes and status back and forth. It wasn't even straight forward hooking up to it's paint event at all.So when I trigger render on it, say from a QTimer without having the widget visible it simply paints a white screen into the buffer. At this point I can only assume that the size information are not correctly passed to the child widgets if it is invisible.
So far all my tests with manually generating events were inconclusive or negative. Personally I believe messing with the event loop too much will only bring complexity and no solution. My gut tells me a solution will work best if I can redirect the graphical output to the now legendary /dev/null without Qt knowing about it.
Thank you very much for the hint though!
Moose
-
@mrjj Yes, I tried calling this directly. It only produces an empty buffer though. I suppose this is due to the widget in question being quite complex.
It is a QWebEngineWidget.
It creates a lot of underlying child widgets and they pass their sizes and status back and forth. It wasn't even straight forward hooking up to it's paint event at all.So when I trigger render on it, say from a QTimer without having the widget visible it simply paints a white screen into the buffer. At this point I can only assume that the size information are not correctly passed to the child widgets if it is invisible.
So far all my tests with manually generating events were inconclusive or negative. Personally I believe messing with the event loop too much will only bring complexity and no solution. My gut tells me a solution will work best if I can redirect the graphical output to the now legendary /dev/null without Qt knowing about it.
Thank you very much for the hint though!
Moose
Well Qt will queue resize events if widget is hidden. ( as far as i know)
so if your widget does stuff in these events then it will not have happened.I was wondering if u played around with
http://doc.qt.io/qt-5.5/qcoreapplication.html#postEventIn theory , you could construct the same events and send to it.
But yes, it suddenly becomes complex and I agree with your gut feeling that a
simple solution exists once found :) -
Well Qt will queue resize events if widget is hidden. ( as far as i know)
so if your widget does stuff in these events then it will not have happened.I was wondering if u played around with
http://doc.qt.io/qt-5.5/qcoreapplication.html#postEventIn theory , you could construct the same events and send to it.
But yes, it suddenly becomes complex and I agree with your gut feeling that a
simple solution exists once found :)@mrjj
I have tested the resize events. Contrary to what I thought hide() or any other means of hiding it don't cause any such events. At least not that I see them.
About the postEvent, that does sound interesting. I will need those things anyway, once I start creating user interaction on the by then hopefully invisible widget.But to hide it in the first place (or making it work without show()ing it) I wouldn't know which events to send.
What I tried before was QShowEvent. After creating the widget and before I go into QApplication::exec() I tried sending one, hoping to fool the widget. It didn't work though.
The widget never went into paint(). And when I sent the paint myself it crashed somewhere in QtOpenGLs innards. Apparently some initial contexts have not been created. I guess show() is necessary for it to work.I'm currently trying to move the widget into its own process to live remotely on its own machine where I'm not bothered by the output. I was so hoping to avoid the network bridge for such a seemingly simple thing...
Cheers,
Moose -
Oh
So later the users will also click on the texture of the widgets
and it needs to react as the real widget would?
That is pretty advanced. :)what types of widget do u need to support ? i if may ask.
@mrjj
Well, that's the plan. :-)
At the moment I will be OK with basic interaction such as mouse wheel and perhaps clicks. No keyboard or other stuff yet.In the long run I am hoping to adapt more widgets as long as they are content with my basic means of interaction.
For now, QWebEngine is primary target as it gives me a modern web browser in-a-box with all capabilities I need. My research ha turned up no other implementation but Qt's here that can do this. Also, due to its complexity and overall weirdness (OpenGL, child widgets) I suppose if it works with that chances are it works with everything.At the moment I am also looking into Windows 10's new virtual desktops. If I can open an application on one of those I wouldn't have to bridge the network and could grab the buffer via IPC or shared memory or something. This desktop would be my /dev/null. As long as Qt doesn't notice it's not actually visible that is.
Cheers,
Moose -
@Moose2342 said:
Thats a fine plan :)
To boldly go .. ;)Yes, if you can get QWebEngine to work as hidden then most other
widgets will just work / you will have the code to do it.Oh, virtual desktops is a pretty good idea if not considered hidden by Qt when other desktop is active.
Far more fun than running on a other pc and need to handle that traffic too. -
@Moose2342 said:
Thats a fine plan :)
To boldly go .. ;)Yes, if you can get QWebEngine to work as hidden then most other
widgets will just work / you will have the code to do it.Oh, virtual desktops is a pretty good idea if not considered hidden by Qt when other desktop is active.
Far more fun than running on a other pc and need to handle that traffic too.@mrjj
Thanks! To boldly go indeed. As a final little update in the matter I would like to add that my approach with the Windows 10 virtual desktops seems to work. I have created a shared memory server which runs the QApplication and renders into a shared memory buffer. This buffer is now consumed where the app-in-a-box used to live. And to my great relief Qt, being oblivious to new Windows features, seems not to notice that the application is actually invisible, so events are processed fine. Let's just pray this stays that way.As a welcome side effect my actual application now suffers a lot less performance impact from creating and running the Qt app since it has only to access the buffer. Next step are the user events.
Thanks for your input!
Cheers,
Moose -
Ok. super :)
Thank you for the feedback. it's good to know that being on other desktop is not the
same as being hidden.Good luck with user interaction :)
