Builds on top of Qt to provide widgets which are useful when developing robotics applications, such as a 3D view, plots, dashboard, etc, and can be used together in a convenient unified interface.
Home Page: https://gazebosim.org
License: Apache License 2.0
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
As of pull request #50, GeometryWidget supports box, cylinder, sphere and mesh. We should support all types in ignition::msgs::Geometry.
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
See widgets introduced on pull request #81
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
We're currently using tinyxml2::XMLElement pointers on some functions which handle configuration files, such as loadPlugin(const std::string &_filename, const tinyxml2::XMLElement *_pluginElem). It would be interesting not to make users create tinyxml elements to use Ignition GUI.
On another part of the API, we're passing an xml file as a string, see Plugin::ConfigStr(). It was done that way due to the fact it isn't straightforward to deep-copy tinyxml elements.
Now I'm leaning towards moving to std::string for passing configuration files everywhere. This way, each plugin can parse the string to the format of their choice. For example, if a plugin wants to use json, they can embed that into our XML:
<plugin filename="PluginThatUsesJson">
{
"example": {
"banana" : "raspberry"
}
}
</plugin>
All Ignition GUI-specific configurations will need to be passed as arguments inside <plugin>. Currently, we handle nested elements like <title> or <title_bar> before passing the configuration forward to the plugin, these will become arguments.
Original report (archived issue) by Pei JIA (Bitbucket: jiapei100).
➜ pkgconfig ll ignition-rendering1*
-rw-r--r-- 1 root root 384 Jan 31 05:24 ignition-rendering1-ogre2.pc
-rw-r--r-- 1 root root 384 Jan 31 05:24 ignition-rendering1.pc
➜ pkgconfig pwd
/usr/local/lib/pkgconfig
➜ pkgconfig -- BUILD ERRORS: These must be resolved before compiling.
-- Missing: ignition-rendering1 (Components: ogre)
-- END BUILD ERRORS
CMake Error at /usr/local/share/cmake/ignition-cmake2/cmake2/IgnConfigureBuild.cmake:66 (message):
Errors encountered in build. Please see BUILD ERRORS above.
Call Stack (most recent call first):
CMakeLists.txt:124 (ign_configure_build)Did anybody meet the same issue? How to successfully build ign-gui (gz11) with Ogre2.x and without Ogre1.x ?
Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
The example image.config is broken. It is currently causing test failures:
Apply the following patch, build and run the test, which will only test image.config:
diff -r 83190ef569c4b4871bc1afa039232ddd5317d661 test/integration/Examples_TEST.cc
--- a/test/integration/Examples_TEST.cc Thu Mar 07 11:14:34 2019 -0800
+++ b/test/integration/Examples_TEST.cc Thu Mar 07 13:30:12 2019 -0800
@@ -40,9 +40,9 @@
ignition::common::DirIter endIter;
for (common::DirIter file(exampleConfigPath); file != endIter; ++file)
{
- // TODO(louise) Investigate why TopicEcho crashes on shutdown
- if ((*file).find("pubsub") != std::string::npos)
- return;
+ // only test image.config to observe failure
+ if ((*file).find("image") == std::string::npos)
+ continue;
Application app(g_argc, g_argv);
app.AddPluginPath(std::string(PROJECT_BINARY_PATH) + "/lib");
Expected behavior:
test passes
Actual behavior:
test fails
Reproduces how often:
100% of time
1.0.0
Original report (archived issue) by Andrés Fortier (Bitbucket: andres_fortier).
After merging https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-gui/pull-requests/43 and integrating it with another project, we realized that we may want to use those shortcuts for other actions in the app. After discussing a bit with @caguero and @nkoenig we concluded that it would be nice if either:
Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
The example pubsub.config is broken. It is currently disabled from testing in INTEGRATION_Examples_TEST; otherwise it causes a seg-fault.
Apply the following patch, build and run the test, which will only test the pubsub.config:
diff -r 83190ef569c4b4871bc1afa039232ddd5317d661 test/integration/Examples_TEST.cc
--- a/test/integration/Examples_TEST.cc Thu Mar 07 11:14:34 2019 -0800
+++ b/test/integration/Examples_TEST.cc Thu Mar 07 13:30:12 2019 -0800
@@ -40,9 +40,9 @@
ignition::common::DirIter endIter;
for (common::DirIter file(exampleConfigPath); file != endIter; ++file)
{
- // TODO(louise) Investigate why TopicEcho crashes on shutdown
- if ((*file).find("pubsub") != std::string::npos)
- return;
+ // only test pubsub.config to observe failure
+ if ((*file).find("pubsub") == std::string::npos)
+ continue;
Application app(g_argc, g_argv);
app.AddPluginPath(std::string(PROJECT_BINARY_PATH) + "/lib");
Expected behavior:
test passes
Actual behavior:
test fails
Reproduces how often:
100% of time
1.0.0
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
Plot_TEST has been failing on OSX because it fails to find Plot as child of the main window, even though debug statements indicate the plugin was properly loaded.
I don't have a way to immediately test this on OSX to check if the plugin itself works, so I'm skipping the tests for now until this can be investigated.
Original report (archived issue) by mingfei sun (Bitbucket: mingfeisun).
It seems that the material theme for the main window is “Light”, which may cause the visibility issues. See
The visibility problems when displaying ign gazebo in Ubuntu Bionic:
I temporally changed the code as follows: this->materialTheme = “Dark”; after recompiling, it works ok. But it’s not flexible. May I ask if there are any solutions to solve this problem?
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
This causes an empty window to appear, when it should print out a help menu because the -v option is missing a value.
ign gui -v -c ../examples/config/topicInterface.config
Plugins in Ignition GUI can be positioned in one of 2 ways:
Currently, the only docked layout supported by Ignition GUI consists of a single vertical split, and multiple horizontal splits on the right, which is quite limited.
This issue is about adding a 2nd split to the left where plugins could also be docked.
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
[Description of the issue]
UNIT_WorldStats_TESTExpected behavior:
Test passes
Actual behavior:
Test fails to find the rendering plugin:
[Dbg] [Application.cc:87] Initializing application.
[GUI] [Dbg] [Application.cc:404] Create main window
[GUI] [Msg] Loading plugin [WorldStats]
loaded plugins : 0
[GUI] [Err] [Application.cc:334] Failed to load plugin [WorldStats] : couldn't load library on path [/home/ian/depot/ign_ws/build/ign_gui/lib/libWorldStats.so].
/home/ian/depot/ign_ws/src/ign-gui/src/plugins/WorldStats_TEST.cc:43: Failure
Value of: app.LoadPlugin("WorldStats")
Actual: false
Expected: true
Reproduces how often:
💯 % of the time
ign-gui1
See discussion on pull request #186
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
Currently, a collapsible item that contains nothing is clickable and expands a small empty box when selected.
Instead, the collapsible item should be disabled.
Original report (archived issue) by Carlos Agüero (Bitbucket: caguero, GitHub: caguero).
I'm a publishing an Ignition.msgs.Scene message with a few models and links. It takes more than 10+ seconds to load all the fields in the TopicInterface plugin. My preliminary profiling points to MessageWidget::Parse().
Here's how to reproduce it:
Terminal 1:
#!c++
caguero@flaco:~/delphyne_ws/src/ign_gui$ ign gui -c examples/config/topicInterface.config
Terminal 2:
Paste the content of this snippet.
Currently, floating plugins can only be placed below the toolbar.
It would be nice to also support adding small plugins, usually consisting of some buttons, on top of the toolbar. We may be able to do this with the current floating plugins, just making sure that's a valid XY position and that their Z can be above the toolbar.
Gazebo-classic has the KeyboardGUIPlugin, which is a GUI plugin that filters all key presses on the main window and publishes them using transport. This is very convenient for other plugins to react to key presses.
The topic used on classic was ~/keyboard/keypress and the message type was msgs::Any with an integer value representing the key. This has confused users in the past, so we should be sure to document it well.
Many ign-gui tests are failing like this on GitHub actions:
qt.qpa.screen: QXcbConnection: Could not connect to display
Could not connect to any X display.
We should prevent these tests from running when no display is detected. As a reference, this is how Gazebo-classic detects it: https://github.com/osrf/gazebo/blob/6fd426b3949c4ca73fa126cde68f5cc4a59522eb/cmake/CheckDRIDisplay.cmake
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
On the gif below, I didn't release the mouse while dragging. I'd expect the orbit target to remain the same, around the red box, but the target seems to move to other points while dragging.
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
QML modules are loaded at runtime, so there is no warning for the user at compile time. It could be helpful for downstream developers to throw errors/warnings at compile time.
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
See https://osrf-migration.github.io/ignition-gh-pages/#!/ignitionrobotics/ign-rendering/issues/28 (gazebosim/gz-rendering#28)
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
And tests that relied on that fail.
/mnt/TERA/code/ign-gui/src/GeometryWidget_TEST.cc:144: Failure
Expected: (edits.size()) > (0), actual: 0 vs 0
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
Original report (archived issue) by Andrés Fortier (Bitbucket: andres_fortier).
Right now you can pick from the "Plugins" menu in the main window any registered plugin. It would be nice if we could restrict which plugins could be selected from that dropdown.
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
All file dialogs are picking up the material design style but it isn't a good fit. I think it would be best for this dialog to just use the system style of each user.
I've tried adding the following to the end of style.qss in the hope that it would clear up the style for all its descendants, but that didn't seem to do the trick, so this will need some deeper investigating.
QFileDialog *
{
}
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
It would be nice to allow docked qtquick widgets to collapse. For example, a user may have many docked widgets but only wants 1 fully expanded.
Original report (archived issue) by Andrés Fortier (Bitbucket: andres_fortier).
I would like to create a layout that has a main widget (which is a plugin) that can't be detached nor closed, while leaving the rest of the widgets as they are by default (detachable and closeable). Is that possible? I'm ok if that requires either changing the code in the plugin or in the app (or both).
Plugins in the main window, when undocked, have a transparent background which makes them less readable if they in front of some other plugin.
There are two possible implementations in my mind to solve them:
The color palette option in the toolbar is easily accessible and noticeable but on the other hand color palette placed in the settings menu seems like the right way to do. I would like inputs on this issue to go ahead with the actual implementation.
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
Add automated tests which build / load all examples in the /examples folder:
https://github.com/ignitionrobotics/ign-gui/blob/2a09f7e6cff885ecd7318f6d2601badbd5ac5051/examples/
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
After inserting a plugin using the drop-down menu in the QTQuick version of ign-gui, I would expect the drop-down to close. Right now the menu stays open, and the user has to click away to close the menu.
I think it feels more natural for the drop-down menu to close after a plugin has been inserted. The downside is that a user who wants to insert multiple plugins will need to click the drop-down menu multiple times.
We could keep the current behavior, where the menu stays open after a plugin is clicked. However, I think it's more likely that a user wants to insert a single plugin rather than multiple at any one time.
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
We often want to display information to users, and ideally that would be displayed in a unified way across the app. On material design terms, we should have a snackbar.
Many plugins will want to display some text information to users, such as errors, warnings and other information. But if each plugin displays it in a different way, the user's experience is not as fluid. Having a central snackbar that can receive notifications from any plugin would be ideal.
Currently, plugins are either displaying all their notifications on the console, or opening dialogs.
Additional references:
Original report (archived issue) by Deanna Hood (Bitbucket: d_hood).
Objective is a widget that lets you load various "displays" (something that paints on the render window, e.g. a grid). Each display will have some common properties (e.g. checkbox for toggling visibility), and potentially some custom properties specific to its plugin (e.g. colour of a grid).
Subtasks:
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
@iche033 mentioned on pull request #62 that we should call Fini on the ignition-rendering engine before terminating the program so it shuts down properly.
I tried calling fini when the engine has no more scenes like this:
diff -r 17c6c8bc83ab46edfadd765870d150e87d868e4e src/plugins/Scene3D.cc
--- a/src/plugins/Scene3D.cc Tue Dec 26 08:53:22 2017 -0800
+++ b/src/plugins/Scene3D.cc Tue Dec 26 09:27:22 2017 -0800
@@ -90,6 +90,8 @@
engine->DestroyScene(scene);
// TODO: If that was the last scene, terminate engine?
+ if (engine->SceneCount() == 0)
+ engine->Fini();
}
}
But if after doing this, we try to open a new scene plugin (i.e. re-init the engine), the program crashes with this backtrace:
/usr/local/lib/libignition-rendering-ogre.so.0(_ZN8ignition9rendering9OgreScene13CreateContextEv+0x75) [0x7f49e1e5c731] /home/louise/code/ign-rendering/src/ogre/OgreScene.cc:339
/usr/local/lib/libignition-rendering-ogre.so.0(_ZN8ignition9rendering9OgreScene8InitImplEv+0x3a) [0x7f49e1e57faa] /home/louise/code/ign-rendering/src/ogre/OgreScene.cc:124
/usr/local/lib/libignition-rendering-base.so.0(_ZN8ignition9rendering9BaseScene4InitEv+0x1d1) [0x7f49e18de6a7] /home/louise/code/ign-rendering/src/base/BaseScene.cc:70
/usr/local/lib/libignition-rendering-base.so.0(_ZN8ignition9rendering16BaseRenderEngine12PrepareSceneESt10shared_ptrINS0_5SceneEE+0xc8) [0x7f49e18daea6] /home/louise/code/ign-rendering/src/base/BaseRenderEngine.cc:214
/usr/local/lib/libignition-rendering-base.so.0(_ZN8ignition9rendering16BaseRenderEngine11CreateSceneEjRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x785) [0x7f49e18daae5] /home/louise/code/ign-rendering/src/base/BaseRenderEngine.cc:193
/usr/local/lib/libignition-rendering-base.so.0(_ZN8ignition9rendering16BaseRenderEngine11CreateSceneERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x86) [0x7f49e18da2e0] /home/louise/code/ign-rendering/src/base/BaseRenderEngine.cc:167
/usr/local/lib/ign-gui-0/plugins/libScene3D.so(_ZN8ignition3gui7plugins7Scene3D10LoadConfigEPKN8tinyxml210XMLElementE+0x1199) [0x7f49e24ed8e7] /home/louise/code/ign-gui/src/plugins/Scene3D.cc:170
/usr/local/lib/libignition-gui0.so(_ZN8ignition3gui6Plugin4LoadEPKN8tinyxml210XMLElementE+0x93d) [0x7f4a1557b765] /home/louise/code/ign-gui/src/Plugin.cc:100
/usr/local/lib/libignition-gui0.so(_ZN8ignition3gui10loadPluginERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPKN8tinyxml210XMLElementE+0x15c8) [0x7f4a154cebe1] /home/louise/code/ign-gui/src/Iface.cc:553
/usr/local/lib/libignition-gui0.so(_ZN8ignition3gui10MainWindow11OnAddPluginE7QString+0x1d7) [0x7f4a154f041d] /home/louise/code/ign-gui/src/MainWindow.cc:268
/usr/local/lib/libignition-gui0.so(_ZN8ignition3gui10MainWindow18qt_static_metacallEP7QObjectN11QMetaObject4CallEiPPv+0x19d) [0x7f4a1559fd97] /home/louise/code/ign-gui/build/include/ignition/gui/moc_MainWindow.cpp:88
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN11QMetaObject8activateEP7QObjectiiPPv+0x7ea) [0x7f4a1228fd2a]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN13QSignalMapper6mappedERK7QString+0x35) [0x7f4a1229a1a5]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN13QSignalMapper3mapEP7QObject+0x202) [0x7f4a1229b6f2]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN11QMetaObject8activateEP7QObjectiiPPv+0x7ea) [0x7f4a1228fd2a]
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN7QAction9triggeredEb+0x42) [0x7f4a1309f412]
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN7QAction8activateENS_11ActionEventE+0xf8) [0x7f4a130a1898]
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 [0x7f4a130a1e1f]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN7QObject5eventEP6QEvent+0xf1) [0x7f4a12290c01]
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN7QAction5eventEP6QEvent+0x22) [0x7f4a130a2122]
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0x8c) [0x7f4a130a905c]
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x256) [0x7f4a130ae516]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0xdb) [0x7f4a1226138b]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x2c6) [0x7f4a12263786]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5 [0x7f4a122b73c3]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x2a7) [0x7f4a0f33f197]
/lib/x86_64-linux-gnu/libglib-2.0.so.0 [0x7f4a0f33f3f0]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c) [0x7f4a0f33f49c]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x5f) [0x7f4a122b77cf]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x10a) [0x7f4a1225eb4a]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN16QCoreApplication4execEv+0x9c) [0x7f4a12266bec]
/usr/local/lib/libignition-gui0.so(_ZN8ignition3gui13runMainWindowEv+0x205) [0x7f4a154d09bb] /home/louise/code/ign-gui/src/Iface.cc:659
/usr/local/lib/libignition-gui0.so(_ZN8ignition3gui9runConfigERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x3ee) [0x7f4a154c9be1] /home/louise/code/ign-gui/src/Iface.cc:226
/usr/local/lib/libignition-gui0.so(cmdConfig+0x81) [0x7f4a154eabe9] /home/louise/code/ign-gui/src/ign.cc:53
/usr/lib/x86_64-linux-gnu/libffi.so.6(ffi_call_unix64+0x4c) [0x7f4a158b2e40]
/usr/lib/x86_64-linux-gnu/libffi.so.6(ffi_call+0x2eb) [0x7f4a158b28ab]
/usr/lib/x86_64-linux-gnu/ruby/2.3.0/fiddle.so [0x7f4a15ab9758]
/usr/lib/x86_64-linux-gnu/libruby-2.3.so.2.3 [0x7f4a180427ef]
/usr/lib/x86_64-linux-gnu/ruby/2.3.0/fiddle.so [0x7f4a15ab9585]
/usr/lib/x86_64-linux-gnu/libruby-2.3.so.2.3 [0x7f4a1802450b]
/usr/lib/x86_64-linux-gnu/libruby-2.3.so.2.3 [0x7f4a180324a3]
/usr/lib/x86_64-linux-gnu/libruby-2.3.so.2.3 [0x7f4a180334d3]
/usr/lib/x86_64-linux-gnu/libruby-2.3.so.2.3 [0x7f4a1802819c]
/usr/lib/x86_64-linux-gnu/libruby-2.3.so.2.3 [0x7f4a1802d142]
/usr/lib/x86_64-linux-gnu/libruby-2.3.so.2.3 [0x7f4a17f13cfd]
/usr/lib/x86_64-linux-gnu/libruby-2.3.so.2.3(ruby_exec_node+0x1d) [0x7f4a17f156fd]
/usr/lib/x86_64-linux-gnu/libruby-2.3.so.2.3(ruby_run_node+0x1e) [0x7f4a17f1783e]
/usr/bin/ruby [0x40087b]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7f4a17b02830] ../csu/libc-start.c:291
/usr/bin/ruby(_start+0x29) [0x4008a9]
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
I'm getting deprecation warnings that 'Advertise' is deprecated, and I need to dig through the code to find out what's the substitute
Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
The ign test cmake logic was fixed in pull request #102, but it fails on homebrew, so it is currently disabled.
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
We should not use nested collapsible widgets, as is found in Scene widget.
Instead, a child element should replace the parent element and offer a back button to return to the parent.
You can try this out on your android phone. Go to "settings" and start navigating down through the menu. Each child menu replaces the previous.
See also: https://material.io/guidelines/patterns/navigational-transitions.html#
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
This test mentioned in the title fails about 4 out of 10 times for me. Here is the output:
/data/ignition/ign-gui/src/VariablePillContainer_TEST.cc:185: Failure
Value of: var02->mapToGlobal(varCenter).y()
Actual: 52
Expected: var02Global.y()
Which is: 15
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
From pull request #24:
It's a nice thing to support tests without installing. For example, installing may pollute my computer with a version of code that I don't want. However, I still want to review a pull request.
I think you can accomplish this with clever usage of path information. Gazebo's tests of its command line tools might be a place to look for an example.
Original report (archived issue) by Andrés Fortier (Bitbucket: andres_fortier).
Disclaimer: I know this is a weird issue and may be difficult to debug, esp. as I am the only one on a group of 4 devs seeing it. However I'm running out of ideas on what this may be, hence I created the issue. Any help will be much appreciated.
We have an application that defines a set of custom plugins. After updating ign_gui (and other dependencies) the plugin load procedure started to segfault. The details:
this->dataPtr is not a nullptr, it seems to have garbage (I think because at no point is dataPtrinitialized to nullptr - https://github.com/ignitionrobotics/ign-gui/blob/70f1809c2524f76bf2c69b946567a67f455850e0/include/ignition/gui/Plugin.hh#L109).Plugin constructor (https://github.com/ignitionrobotics/ign-gui/blob/70f1809c2524f76bf2c69b946567a67f455850e0/src/Plugin.cc#L37) is not being called for our plugin. I tried changing the Plugin source code to:Plugin::Plugin() : dataPtr(new PluginPrivate)
{
std::cout << "!!! INIT !!! " << std::endl;
}
and tested with different plugins. The result is that all the plugins shipped with ign_gui call the constructor, but those defined outside (i.e. in an app that use ign_gui as a library) don't call it.
dataPtr having garbage, as it is the only place where it is initialized.dataPtr is private I can't think on a workaround on our side to fix it.$ gdb visualizer
[...]
Reading symbols from visualizer...done.
(gdb) r
Starting program: /home/andres/OSRF/DrakeFrontEnd/delphyne_ws/install/bin/visualizer
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Msg] Visualizer 0.1.0
[New Thread 0x7fffde049700 (LWP 24813)]
[New Thread 0x7fffd408d700 (LWP 24814)]
[New Thread 0x7fffd3875700 (LWP 24815)]
[New Thread 0x7fffd3074700 (LWP 24816)]
[GUI] [Msg] Applying stylesheet [:/style.qss]
[GUI] [Msg] Loading plugin [libRenderWidget.so]
[New Thread 0x7fffc23b6700 (LWP 24818)]
[New Thread 0x7fffc1bb5700 (LWP 24819)]
[New Thread 0x7fffc13b4700 (LWP 24820)]
[New Thread 0x7fffc0bb3700 (LWP 24821)]
[New Thread 0x7fffbbfff700 (LWP 24822)]
Thread 1 "visualizer" received signal SIGSEGV, Segmentation fault.
ignition::gui::Plugin::DeleteLaterRequested (this=0x7250b0) at /home/andres/OSRF/DrakeFrontEnd/delphyne_ws/src/ign_gui/src/Plugin.cc:150
150 return this->dataPtr->deleteLaterRequested;
(gdb) bt
#0 ignition::gui::Plugin::DeleteLaterRequested (this=0x7250b0) at /home/andres/OSRF/DrakeFrontEnd/delphyne_ws/src/ign_gui/src/Plugin.cc:161
#1 0x00007ffff7b884e6 in ignition::gui::addPluginsToWindow () at /home/andres/OSRF/DrakeFrontEnd/delphyne_ws/src/ign_gui/src/Iface.cc:589
#2 0x00007ffff7b8e35b in ignition::gui::MainWindow::OnAddPlugin (this=<optimized out>, _plugin=...) at /home/andres/OSRF/DrakeFrontEnd/delphyne_ws/src/ign_gui/src/MainWindow.cc:269
#3 0x00007ffff7bba5a4 in ignition::gui::MainWindow::qt_static_metacall (_o=<optimized out>, _c=<optimized out>, _id=<optimized out>, _a=<optimized out>)
at /home/andres/OSRF/DrakeFrontEnd/delphyne_ws/build/ign_gui/include/ignition/gui/moc_MainWindow.cpp:88
#4 0x00007ffff6fc7d2a in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5 0x00007ffff6fd21a5 in QSignalMapper::mapped(QString const&) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6 0x00007ffff6fd36f2 in QSignalMapper::map(QObject*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7 0x00007ffff6fc7d2a in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8 0x00007ffff760b412 in QAction::triggered(bool) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9 0x00007ffff760d898 in QAction::activate(QAction::ActionEvent) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#10 0x00007ffff778fe52 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#11 0x00007ffff77960ec in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#12 0x00007ffff779a060 in QMenu::mouseReleaseEvent(QMouseEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#13 0x00007ffff7657fc8 in QWidget::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#14 0x00007ffff779aab3 in QMenu::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#15 0x00007ffff761505c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x00007ffff761ac19 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#17 0x00007ffff6f9938b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x00007ffff7619b32 in QApplicationPrivate::sendMouseEvent(QWidget*, QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#19 0x00007ffff767291d in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#20 0x00007ffff7674b7b in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#21 0x00007ffff761505c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#22 0x00007ffff761a516 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#23 0x00007ffff6f9938b in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#24 0x00007ffff53ad4e1 in QGuiApplicationPrivate::processMouseEvent(QWindowSystemInterfacePrivate::MouseEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#25 0x00007ffff53af1a5 in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#26 0x00007ffff5392f08 in QWindowSystemInterface::sendWindowSystemEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#27 0x00007ffff7ead200 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#28 0x00007ffff4a98197 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#29 0x00007ffff4a983f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#30 0x00007ffff4a9849c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#31 0x00007ffff6fef7cf in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#32 0x00007ffff6f96b4a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#33 0x00007ffff6f9ebec in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#34 0x00007ffff7b86790 in ignition::gui::runMainWindow () at /home/andres/OSRF/DrakeFrontEnd/delphyne_ws/src/ign_gui/src/Iface.cc:659
#35 0x000000000040163e in main (argc=<optimized out>, argv=<optimized out>) at /home/andres/OSRF/DrakeFrontEnd/delphyne_ws/src/delphyne_gui/visualizer/visualizer.cc:102
class RenderWidget : public ignition::gui::Plugin {
Q_OBJECT
public:
/// \brief Default constructor.
explicit RenderWidget(QWidget* parent = 0);
[...]
}
and
RenderWidget::RenderWidget(QWidget* parent)
: Plugin(), initializedScene(false), engine(nullptr) {
[...]
}
And of course, let me know if you need more info. Any pointers / hints will be greatly appreciated.
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
The feature added on pull request #109 only works nicely if all subsequent messages maintain the number of repetitions, their order and their names. If either of these changes, the collapsible is not renamed and the widget becomes inconsistent.
A failing test case has been added and commented out. Possible solutions I can think of:
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
Support some icon set like QtAwesome
Original report (archived issue) by Alexis Pojomovsky (Bitbucket: apojomovsky).
Hi guys,
this is my first appearance here so let me introduce myself. My name's Alexis Pojomovsky and I'm currently working in the Delphyne project, as part of the team from the external contractor Ekumen.
That being said, I'd like to report an issue we experimented when attempting to load a ".config" file that loads the system's default qt style.
To accomplish this, we found that we can use an empty stylesheet as part of the config file, but by doing that, we found that if we do this:
#!xml
...
<stylesheet>
</stylesheet>
...
the system fails with this: IOError: [Errno 11] Resource temporarily unavailable
On the other hand, if we add a comment line like this, the system works as expected:
#!xml
...
<stylesheet>
/* comment */
</stylesheet>
...
It's not a big deal, and definitely does not prevent us from keep working, but we thought I'd be good to let you know about it (if you're not already aware of it).
FYI @clalancette
Gazebo-classic has a featureful plotting tool so users can visualize various types of data coming from simulation.
We initially ported that tool to Ignition back in ign-gui0, when we were still using QWidgets. Since we moved to QML, we need a new plotting tool using QML's QtCharts.
Here are some user stories ordered from the most important to the least important. The users are defined as follows:
ign-gazebo users are ign-gui users.ign-gui pluginsign-gazebo plugins. Some ign-gazebo developers are also ign-gui developers (if they write ign-gazebo GUI plugins).Some stories:
Based on the user stories above, here's a list of features to be implemented:
These features should be implemented on Ignition GUI, so they can be used by users that are not using Ignition Gazebo.
Additional features that are only needed in Ignition Gazebo.
Keeping track of them here just to have it all in one place.
@AmrElsersy has started implementation at https://github.com/AmrElsersy/Ignition-plotting. That will be refactored and moved to ign-gazebo / ign-gui.
The current plan is to split the implementation into a few parts:
ign-gui plugin which lists all ign-transport topics currently published. #69
ign-gui0's TopicViewer, see this PR:
ign-gui plugin.ign-gui and is not a plugin by itself, similar to IgnSpinBox, but including some C++ logic.ign-gui plugin which plots ign-transport topics.
PlottingInterfaceTransportTopics.ign-gui plugin.ign-gui plugin which plots ign-gazebo components.
PlottingInterfaceComponentInspector.ign-gazebo GUI plugin (has access to components).Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
There is a deprecation warning on homebrew with qt 5.13 complaining that QSortFilterProxyModel::filterChanged has been deprecated and that QSortFilterProxyModel::invalidateFilter should be used instead:
src/SearchModel.cc:152:9: warning: 'filterChanged' is deprecated: Use QSortFilterProxyModel::invalidateFilter [-Wdeprecated-declarations]
this->filterChanged();
^
/usr/local/opt/qt/lib/QtCore.framework/Headers/qsortfilterproxymodel.h:143:5: note: 'filterChanged' has been explicitly marked deprecated here
QT_DEPRECATED_X("Use QSortFilterProxyModel::invalidateFilter") void filterChanged();
^
/usr/local/opt/qt/lib/QtCore.framework/Headers/qglobal.h:294:33: note: expanded from macro 'QT_DEPRECATED_X'
# define QT_DEPRECATED_X(text) Q_DECL_DEPRECATED_X(text)
^
/usr/local/opt/qt/lib/QtCore.framework/Headers/qcompilerdetection.h:649:55: note: expanded from macro 'Q_DECL_DEPRECATED_X'
# define Q_DECL_DEPRECATED_X(text) __attribute__ ((__deprecated__(text)))
^
1 warning generated.
https://build.osrfoundation.org/job/ignition_gui-ci-ign-gui2-homebrew-amd64/3/warnings10Result/
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
When resizing the scene 3D plugin, I can see using top that the memory almost doubles each time the window is resized.
I traced it down to these lines on Scene3D. If I comment out SetImageWidth, SetImageHeight and SetAspectRatio, the issue doesn't happen.
The comment on the code, setting the size should cause the render texture to be rebuilt led me to OgreRenderTarget::RebuildImpl. There are some "destroy" functions which are not implemented there.
I started trying to implement them here (gazebosim/gz-rendering@1af343b), but the memory leak is still happening.
@iche033 , any tips?
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
The test fails as follows:
23: /Users/jenkins/workspace/ignition_gui-ci-pr_any-homebrew-amd64/ign-gui/src/MessageWidget_TEST.cc:1034: Failure
23: Value of: widget->PropertyWidgetCount()
23: Actual: 22
23: Expected: count
23: Which is: 15
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
After running make for the first time, running it on the second time gives the following error:
doc/CMakeFiles/doc.dir/build.make:57: recipe for target 'doc/CMakeFiles/doc' failed
make[2]: *** [doc/CMakeFiles/doc] Error 1
CMakeFiles/Makefile2:181: recipe for target 'doc/CMakeFiles/doc.dir/all' failed
make[1]: *** [doc/CMakeFiles/doc.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2
This is probably related to the doc changes done on pull request #61
Original report (archived issue) by Louise Poubel (Bitbucket: chapulina, GitHub: chapulina).
Qt provides its own plugin framework. It might be a good idea to use that instead of Ignition Common's, since in theory it is especially tailored for Qt.
There is some urgency sorting this out since there is a pull request landing into ign-common's default branch soon which will break compatibility with Ignition GUI.
Some things to be figured out:
Does Qt provide the same features as Ignition, such as:
How much effort would it be to support the ign-gui case with ign-common's new plugin loader? Is it worth the trouble?
Original report (archived issue) by Nate Koenig (Bitbucket: Nathan Koenig).
We should pick a consistent background, such as #ededed.
Original report (archived issue) by Deanna Hood (Bitbucket: d_hood).
The original report had attachments: scene3d_too_large.png
Sometimes windows are allowed to become taller than what the monitor can display. This cuts off the bottom of the window so you can't see the contents of some widgets, but more of an issue is that it cuts off the ability for the user to make the window smaller (for which you need to mouse-over the bottom of the window).
This can happen when collapsible widgets (e.g. Grid3D) are expanded, but it can also just happen if the default window size specified in the config file is too large. I've attached an example of the scene3d.config example which is too large for my laptop's builtin display of 1600x900.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.
