1. OpenSourceRoboticsFoundation
  2. Simulation
  3. gazebo
  4. Issues
Issue #2133 resolved

Qt5: GUI overlay plugins not working?

Louise Poubel
created an issue

When I open timer_gui.world, the GUI overlays don't show.

GUI plugins seem to be loaded correctly though, KeyboardGUIPlugin is correctly publishing key press messages in simple_arm_teleop.world for example.

Maybe related, when I open Gazebo without any world, I see a weird white line on the top:

whiteline.png

Comments (18)

  1. JenniferBuehler

    I'm having the same problem after updating to the new default branch just yesterday, which now uses Qt5 instead of Qt4. The issue goes away when I add the plugin to the RenderWidget::splitter with RenderWidget::InsertWidget... then it appears below the render window.

    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?

  2. Louise Poubel reporter

    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...

  3. 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.

  4. Ian Chen

    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.

  5. 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. I have Qt::WA_PaintOnScreen still commented out, and it still worked with the overlaying in my separate example! I have not been able to figure out yet why it isn't working just the same with the GLWidget in Gazebo. It's strange that everything works fine in the simplified code... the bug must lie deeper inside somewhere.

    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.

  6. 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. It seems like the Ogre window stuff is overriding the plugin...

    Any ideas?

  7. 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. I haven't tested this on Windows or Mac.

    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 Ian Chen 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? Could you maybe test on your systems if it works for you with "externalWindowHandle" instead of "parentWindowHandle"?

    UPDATE:

    According to this it makes sense to use external window and not parent window:

    • externalWindowHandle: External window handle, for embedding the OGRE render in an existing window
    • parentWindowHandle: Parent window handle, for embedding the OGRE in a child of an external window (also, there is no mention in the types/values column of Mac support?!)

    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).

  8. Ian Chen

    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 Qt::WA_PaintOnScreen flag and see if the OSX test failures are still there

  9. Vahid Azizi

    sorry guys, this issue is solved or not? because the pull req is still open. I am over ubuntu 16.4 and my gazebo version is 7.8.1 and I installed binary version and I have same problem as here. is there a way to solve this issue by adding something inside gui plugin code because I don't want to upgrade to 8? Also I must mention I tried gazebo 8.1.1 but I had same problem there as well. I can see the gui sometimes when I resize the main gazebo window.

  10. Ian Chen

    both pull requests have been merged. The issue is to caused by integration with Qt5.

    gazebo7 uses Qt4 so it could be a different problem you're experiencing.

  11. Log in to comment