Qt5: GUI overlay plugins not working? #2133
Comments
|
Original comment by Jennifer Buehler (Bitbucket: JenniferBuehler). I'm having the same problem after updating to the new default branch just yesterday, which now uses Qt5 instead of Qt4. Also, when I add the plugin to the layout RenderWidget::render3DLayout, it works. My current guess is that it may have something to do with that the plugin doesn't get added to a layout. But on the other hand, it's weird that it's working for you to just add a child Widget which is then displayed on top of the parent. I would have guessed that Qt5 maybe doesn't like this any more... though admit I'm not sure, I've only used Qt4 before. Still working on fixing this up somehow now and will post updates here. Meanwhile, a question: Would it be OK to find a solution which involves Layouts? And did you also get the issue just after upgrading to Qt5? |
|
Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina). So I just tried it now with the gazebo8 beta debian package and no GUI overlays show. When I closed the issue, I was using a version built from source. As for a solution using layouts, I imagine that wouldn't be "overlayed" on top of the 3D scene anymore right? That sounds like a big change in behavior... |
|
Original comment by Jennifer Buehler (Bitbucket: JenniferBuehler). Yes, that's a bit of a behaviour change which would be nice to avoid. I'm still trying to get the overlay thing to work, maybe there's other Qt layout-like structures that allow overlaying. I'm just making a simple stand-alone (gazebo detached) example to reproduce the error and make sure the having no layout is the actual problem. |
|
Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033). after uncommenting out the Qt::WA_PaintOnScreen attribute, the gui overlays started showing again. It was causing some gui test failures during early stage of Qt5 integration but maybe the tests can be fixed. We should try bring back the flag. |
|
Original comment by Jennifer Buehler (Bitbucket: JenniferBuehler). Unfortunately, that doesn't solve it for me, still not showing :( I have been taking GLWidget apart to reproduce it in my simple standalone test (based on code above). I now have the structure as in MainWindow, RenderWidget and GlWidget, including all the layout stuff, and only removed the gazebo-specific things from GLWidget, to have a setup as similar as possible. But GLWidget must be the culprit, because it is possible to add the GUI plugins to RenderWidget's topToolbar, mainFrame and and bottomFrame without problems. The overlaying itself works, only GLWidget seems to block it, ignore it, or draw over it. |
|
Original comment by Jennifer Buehler (Bitbucket: JenniferBuehler). Alright, I am calling it a day on this issue, hit a few more dead ends. I'm thinking that the problem may be what is done with the window here in GLWidget, but I'm not sure as I'm not yet familiar with the code beyond this: // Create the OGRE render window
this->dataPtr->windowId =
rendering::RenderEngine::Instance()->GetWindowManager()->
CreateWindow(winHandle, this->width(), this->height(), ratio);If I comment the whole block and don't create a window (so that windowId remains -1), you can see the GUI plugin for the second before it crashes (crashes presumably because the stuff has been commented). When I do create the window but take out the render call in paintEvent, a black window is displayed, but the plugin is not visible. Any ideas? |
|
Original comment by Jennifer Buehler (Bitbucket: JenniferBuehler). Phew, this one was a pickle to find! I got a solution now, though not sure how universal this is or if it's only on my system. The problem was in WindowManager::CreateWindow, it affects "parentWindowHandle" which for me was causing the problem. If I use "externalWindowHandle" instead, everything works (I'm on xenial). I tried "currentGLContext" too but that just opens the GLWidget in a separate window. Unfortunately this works only with Qt::WA_PaintOnScreen enabled, otherwise I get a weird flickering. According to this (though old post), Qt::WA_PaintOnScreen should not be used any more, and as @iche033 pointed out, it was causing test failures on Mac... Let me know what you think in terms of posting a PR to fix this. Should we maybe #ifndef out Qt::WA_PaintOnScreen for Mac only? UPDATE: According to this it makes sense to use external window and not parent window:
We want to embed it in the GLWidget itself, so I'd guess externalWindowHandle is a valid choice, which is why it works. However one could also argue that GLWidget is a child of MainWindow, even though not a direct child because RenderWidget and RenderWidget::mainFrame are in-between parents... which lead me to find that mainFrame doesn't have a parent, which means the chain is broken... if this is fixed, I can actually use parentWindowHandle: this->mainFrame = new QFrame(this);I have updated pull request #2562 with this minor change, this works for me now, though Qt::WA_PaintOnScreen is still required, or it doesn't show up (no flickering though). New issue: The cessna and keyboard GUI plugins create the black square which is meant to be avoided by resizing to 0,0. Solution: resize to [1,1] and move to [-1,-1] works, but it's a bit hacky (included in pull request #2562). |
|
Original comment by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina). Great, the issue seems to be fixed for me on pull request #2562. I'm on Xenial though, we should get this checked on OSX. |
|
Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033). Thanks for digging into this! The changes works for me. One caveat I found when using externalWindowHandle is that anti-aliasing doesn't seem to work, e.g. if you insert a box and look at the edges, they are now jagged. So adding the parent to main frame is a nice solution. I've started jenkins jobs to test the |
|
Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033). pull request #2562 - > pull request #2631 - > |
|
Original comment by Shane Loretz (Bitbucket: Shane Loretz, GitHub: sloretz). Issue #2225 was marked as a duplicate of this issue. |
|
Original comment by Vahid Azizi (Bitbucket: vaazizi). sorry guys, this issue is solved or not? because the pull req is still open. |
|
Original comment by Florian Schoppmann (Bitbucket: Florian Schoppmann). Just a note for anybody wondering about macOS: Anything discussed above did not prevent that OpenGL would always draw above any GUI plugin on macOS. My pull request #2764 should finally fix this. |
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
When I open
timer_gui.world, the GUI overlays don't show.GUI plugins seem to be loaded correctly though,
KeyboardGUIPluginis correctly publishing key press messages insimple_arm_teleop.worldfor example.Maybe related, when I open Gazebo without any world, I see a weird white line on the top:
The text was updated successfully, but these errors were encountered: