Open zflat opened 2 years ago
The method ignition::gui::App() returns a pointer of type ignition::gui::Application.
That's just a wrapper around qGuiApp:
Could you use qGuiApp
directly for your use case?
Can an abstract base class be defined and then ignition::gui::App() returns the base class?
Could you elaborate on what functionality would be on the new abstract class, and what would remain in gui::Application
?
Could the majority of this logic be extracted to a helper class that could also be used downstream?
Yes, I think that's a good idea. While implementing it, we should try to be backwards-compatible as much as possible, so we don't break existing users. For example, Application::LoadPlugin
could call the new PluginManager::LoadPlugin
(or any other name it has).
Could you use
qGuiApp
directly for your use case?
The issue is with ignition::gui
code that uses the App()
method. For example, see ign-gui/src/Plugin.cc
in the method PluginLoad
this->dataPtr->context = new QQmlContext(App()->Engine()->rootContext());
In order for plugin loading to work downstream, the qGuiApp
pointer must be to an object that can be cast to an Application
type. So it is not downstream code, but ignition::gui
code that is using App()
.
Can an abstract base class be defined and then ignition::gui::App() returns the base class?
Could you elaborate on what functionality would be on the new abstract class, and what would remain in
gui::Application
?
I think the abstract class would have public functions for the public functions currently implemented in Application
public: virtual QQmlApplicationEngine *Engine() const = 0;
public: virtual bool LoadPlugin(const std::string &_filename, const tinyxml2::XMLElement *_pluginElem = nullptr) = 0;
public: virtual bool LoadConfig(const std::string &_path) = 0;
public: virtual bool LoadDefaultConfig() = 0;
public: virtual void SetDefaultConfigPath(const std::string &_path) = 0;
public: virtual std::string DefaultConfigPath() = 0;
public: virtual void SetPluginPathEnv(const std::string &_env) = 0;
public: virtual void AddPluginPath(const std::string &_path) = 0;
public: virtual std::vector<std::pair<std::string, std::vector<std::string>>> PluginList() = 0;
public: virtual bool RemovePlugin(const std::string &_pluginName) = 0;
public: virtual std::shared_ptr<Plugin> PluginByName(const std::string &_pluginName) const = 0;
signals: virtual void PluginAdded(const QString &_objectName) = 0;
public slots: virtual void OnPluginClose() = 0;
Could the majority of this logic be extracted to a helper class that could also be used downstream?
Yes, I think that's a good idea. While implementing it, we should try to be backwards-compatible as much as possible, so we don't break existing users. For example,
Application::LoadPlugin
could call the newPluginManager::LoadPlugin
(or any other name it has).
Desired behavior
I would like to incorporate
ign-gui
and alsoign-rviz
QML components in an existing Qt Quick application. The existing application sets up aQGuiApplication
already and needs to do some different things than whatignition::gui::Aplication
does for the following:QQmlApplicationEngine
(see https://doc.qt.io/qt-5/qqmlapplicationengine.html#load-1).SIGINT
signal handlerImplementation suggestion
In order to use
ign-gui
QML components in a downstream application, I would like to suggest a couple of changes.ignition::gui::App()
returns a pointer of typeignition::gui::Application
. Can an abstract base class be defined and thenignition::gui::App()
returns the base class? ThenApplication
would be changed to inherit from the base class.Application
class performs a lot of plugin loading logic. Could the majority of this logic be extracted to a helper class that could also be used downstream? Ideally, theApplication
class would then only be specific to setting up and interacting withignition::gui::MainWindow
and other "top level" things like signal handlers and logging.ignition::gui::Application::AddPluginsToWindow
is specific to proably too specific toigntion::gui::MainWindow
to be extracted, but maybe it could be broken down some with common functionality extracted.Alternatives considered
I could subclass the
ignition::gui::Application
class as-is and override the constructor and other methods. I would have to work around the issues described here and I am not sure how feasible this solution is without testing it.Additional context
N/A