Native save/load file dialogs don't display when Gazebo is also running

[JStech]

Description

This originally came up in MoveIt Calibration (ros-planning/moveit_calibration#24), but it seems to be more general than that. If Gazebo is running, any time QFileDialog::getOpenFileName or QFileDialog::getSaveFileName is called, an entry is created in the dock, but no window is drawn. Meanwhile, the rest of the GUI freezes until the ghost dialog is closed (by right-clicking the dock entry and choosing close).

Including the DontUseNativeDialog option in the call to get(Open|Save)FileName is at least a workaround, if not a solution.

Your environment

• ROS Distro: Melodic
• OS Version: Ubuntu 18.04
• Source build, master

Steps to reproduce

Having just completed the "Getting started" tutorial,

1. run roslaunch panda_moveit_config demo.launch
2. in a separate terminal, run roslaunch gazebo_ros emtpy_world.launch
3. in RViz, add the MotionPlanning panel
4. go to the Scene Objects tab, and click "Import" or "Export"

Expected behaviour

A file-chooser dialog should open. If you skip step 2 and don't open Gazebo, the dialog does appear.

Actual behaviour

The dialog never appears. A dock entry is created for it, but no window appears.

Backtrace or Console output

The only relevant console output is

Gtk-Message: 10:44:13.792: GtkDialog mapped without a transient parent. This is discouraged.

but from what I can tell that's a Qt/Gtk issue that's not the problem (and would be difficult to resolve). The line is also generated when the dialog does appear.

[welcome[bot]]

Thanks for reporting an issue. Because we're a volunteer community, providing a pull request with suggested changes is always welcomed.

[simonschmeisser]

As you are probably running gnome (the ubuntu default), the native file dialog would indeed be Gtk based. So this message might be related. Maybe gazebo does something 'clever' with environment variables? I think native dialogs are started by running some xdg-... command internally?

[JStech]

Thanks for the info--I'm completely lost when it comes to GUI stuff. Is there an approach to debugging this that I should try? I attached to the process with GDB but quickly realized I didn't know what to look for (or even what thread was relevant).

This post made me think that Gtk warning was not relevant--also, like I said, it happens regardless of whether the dialog appears.

[freckletonj]

I can confirm that Gazebo 11 on Ubuntu 20 still has this problem. I find that if I change workspaces (Ctrl+Alt+Down) I can get the save dialog to show up, but, I still can't interact with it.

The advice of "just run it with sudo" is a little disappointing.

[slowrunner]

I see this "can't see save world as dialog" behavior with Gazebo 11.9.0.

Work-around: press cntI-alt-dn, cntrl-alt-uparrow to see dialog, and again to redisplay dialog after any clicks or chars typed.

I am using Gazebo 11 on Ubuntu 20.04 running in a VMware Fusion Virtual machine with 3 cores of processor, 8GB mem allocated of a 2018 Mac Mini 3.2GHz i7, with an LG Ultrawide on the internal Intel UHD Graphics 630 GPU, and with an external GPU running a Radeon RX 580 and Dell 4K P2415Q display

[manish-nayak]

I can confirm that Gazebo 11 on Ubuntu 20 still has this problem. I find that if I change workspaces (Ctrl+Alt+Down) I can get the save dialog to show up, but, I still can't interact with it.

The advice of "just run it with sudo" is a little disappointing.

I am also facing the same issue with Gazebo 11 on Ubuntu 20. I also don't find the sudo gazebo solution to be very helpful. But even with this solution, I am not sure how can we run it along with ros2. I mean sudo ros2 gazebo... doesn't work. I can't edit the world if I am using it along with ros.