Hi Shawn, > On 28. Nov 2024, at 13:15, Shawn Rutledge via Development > <development@qt-project.org> wrote: > > >> On Nov 28, 2024, at 09:08, Fabian Kosmale via Development >> <development@qt-project.org> wrote: >> - Some are already (indirectly) exposed via Q_PROPERTY; should anyone decide >> to expose those Widgets to QML (or some other language binding working on >> the meta-object system), this would cause some friction because there will >> be name clashes (QWidget::geometry() vs the geometry property). > > Indeed; given that the UI designer application, and QUiLoader, are able to > dynamically instantiate every kind of widget, and all the interesting > properties are, well, properties, it seems doubtful that there are many > things that you couldn’t already do in a scripting language either. And some > property setters are already slots, which already makes them invokable, and > is also a bit redundant already (if QProperty can set the property, the main > reason for making the setter into a slot besides is to be able to connect a > signal to it, right?)
QUiLoader seems to have a fixed list of Widgets it can instantiate? (“widgets.table”) And for custom widgets it expects you to implement QDesignerCustomWidgetInterface. And then for the properties, most is there you are right and I was starting to think it should all be easy, but pretty important stuff like “QWidget::show()” is not covered by a property sadly. I will investigate how much of the important stuff is missing first, maybe just setting up a list of classes and their Constructors, plus the important QWidget functions is small enough that I no longer wish for Q_INVOKABLE all the things :) Cheers, Marcus -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
