Creating custom widgets based on constructors with parameters without default values
-
You can register custom widgets so they can be constructed automatically but you will need to wrap in a factory design and handle it yourself before returned the created object to the outside world.
I have noticed another software development challenge for this programming interface because I came along the need to pass references to specific widget constructors in a hierarchy (and not only to a single widget).
But if you separate the presentation from the actual data its possible to use UI files and fixup the full object after the UIloader have instantiated the included widgets.
I am curious to know how such an approach would look like.
Not really as its implied by the compiled nature of c++.
I have got additional imaginations.
I cannot imagine a method/system for a pre-existing binary to be able to use future unknown classes in static code generation as parameters for construction of Widgets describe in UI files.
I hope that this file format can take the desire into account to handle object construction also without default values.
Say you had a Widget
MyThing(QWidget parent, MyData * data)My concrete use case would be “
ResultsView(QStandardItemModel& sim, QWidget* parent)
”.Where should Creator get the Mydata from ?
- The extra data will be passed during the usual control flow by the affected classes.
- The development tools would need to be extended once more.
Only option would be to default construct one …
- Can any further software design options be considered?
- Will parameter packs eventually become relevant here?
-
Hi
I have noticed another software development challenge for this programming interface because I came along the
need to pass references to specific widget constructors in a hierarchy (and not only to a single widget).The normal solution for using RAII (https://en.wikipedia.org/wiki/Resource_acquisition_is_initialization)
is to avoid using Designer and construct the GUI in code. That way anything is possible.I am curious to know how such an approach would look like.
The basic structure would be like (pseudo code)
CustomWidget * CreateMyClass(QStandardItemModel &SomeModel) { QUiLoader loader; QFile file(":/forms/myform.ui"); file.open(QFile::ReadOnly); QWidget *myWidget = loader.load(&file, this); CustomWidget *realOne=qobject_cast<CustomWidget *>(myWidget ) if ( ! realOne) { reportError();return nullptr;} // safety check realOne->setModel(SomeModel); // fixup the data return realOne; }
My concrete use case would be “
ResultsView(QStandardItemModel& sim, QWidget* parent)
”.But to use & would demand that the model would stay alive for the lifespan of ResultsView
and where should Creator put it? Generate some global variables ?Where should Creator get the Mydata from ?
- The extra data will be passed during the usual control flow by the affected classes.
- The development tools would need to be extended once more.
I cannot see this be possible. You would have to register hooks for all classes
that could specify as text templates how the constructor should look and be generated.The only workaround i know is to setup any models/data members after the
setupUI() call in the constructor.Only option would be to default construct one …
- Can any further software design options be considered?
- Will parameter packs eventually become relevant here?
I doubt such feature will be added.
However we are a user forum and the Qt devs hang out at
http://lists.qt-project.org/mailman/listinfo -
The normal solution for using RAII is to avoid using Designer
This suggestion is also interesting. But it would be nicer if such a development tool can still be used because it usually helps for the desired user interface modelling to some degree.
and construct the GUI in code.
This is another design option in principle.
That way anything is possible.
- I have got doubts because Qt's software build process depends on tools which show further software limitations.
- I got the impression that a tool like the meta-object compiler could hinder progress on the reported design goals.
But to use & would demand that the model would stay alive for the lifespan of ResultsView
- Yes, of course. - Should the model be usually set before corresponding widgets (or views) will display the provided data?
- How often do circumstances occur that the desired model setting can be performed only in the implementation of a view constructor?
and where should Creator put it?
There are some design choices available.
Generate some global variables ?
- This can be an usable option occasionally.
- I would prefer to manage model objects by the application instance (or even by a dedicated model manager).
I cannot see this be possible.
At the moment?
You would have to register hooks for all classes
I propose to reconsider this idea.
that could specify as text templates how the constructor should look and be generated.
You are right that extra information needs to be transferred somehow. - I got another software development idea.
It seems that the current tools support mostly default-constructible objects for graphical user interface displays.- Can the macro “Q_OBJECT” support another parameter for passing the desired constructor selection?
- How are the chances to determine the needed constructor parameters by source code introspection automatically?
The only workaround i know is to setup any models/data members after the setupUI() call in the constructor.
I published a different (or similar?) development approach just because the information source for the model data is already known.
I doubt such feature will be added.
Would any users here like to comment on existing bug reports or feature requests?
-
Can improvements be achieved for the tool “user interface compiler” anyhow?
Why not? As always with open source, you can modify it according to your need (with respect to the license, of course).
If your improvements look reasonable for the developers, they might be added to further versions too. If you have such intentions, you should really discuss them with the developers on the Qt development mailing list.
Regards
-
Hi @elfring,
Different users have different needs and write different software.
As said by @mrjj before, all can be done in code without designer. You can even create basic dialogs in Designer and complete them in your code. You can extend Designer with own widgets. You can write your own code generator...
So much possibilities :)
-
…, all can be done in code without designer.
I would appreciate if the visual design tool can work together with available user interface compilers to get the creation of non-default-constructible widgets (including views) working in a safe and convenient way.
Does this aspect require another update for the Qt program “uic” (or even a replacement)?You can even create basic dialogs in Designer and complete them in your code.
Will any more examples be published where such approaches can be insufficient for safe application object configurations?
-
You can write your own code generator...
- Have you ever heard about concrete approaches to perform the desired data processing for Qt Designer's UI file format (or the QML file format) by a corresponding C++ class template library?
- Will source code introspection take the handling of non-default-constructible widgets (including views) better into account then?
-
…, all can be done in code without designer.
- Can Qt users (or developers) become more interested in the support for object construction without default parameters?
- Would you like to see extensions for data format descriptions and corresponding development tools?
-
@elfring said in Creating custom widgets based on constructors with parameters without default values:
Can Qt users (or developers) become more interested in the support for object construction without default parameters?
You should ask Qt developers ( @aha_1980 already gave you the link), not in this user forum...
-
@elfring
Hi- I am curious on how the clarification will evolve
Me too.
As what you wish for - takes a huge amount of code and forces a preconceived structure on the users
and its going from very complicated and involving to plain impossible in scope :)In 30 years of programming, i have not seen any WYSIWYG editor that supported adding
unknown classes to static code generation for GUI instance construction.