Is this possible?
-
That's doable, but it means you will have to implement a repeater for every possible combination of any types of parameters. Unless you heavily limit possible signal signatures I don't think that's practical.
-
That's doable, but it means you will have to implement a repeater for every possible combination of any types of parameters. Unless you heavily limit possible signal signatures I don't think that's practical.
-
@Chris-Kawa , Yep, thats what I was hoping to avoid, but if its unavoidable, then I'll just have to do it and release patches / updates as I add additional controls to the engine.
@SPlatten said in Is this possible?:
then I'll just have to do it and release patches / updates as I add additional controls to the engine.
Originally you wrote:
dynamic map capable of storing the information for any QT control or derived control and it’s signals.
I don't mean to pour cold water/put up obstacles gratuitously for your work. But if you are going to have to release patches for each signal, what happens if I derive my own
QWidgets and add my own new, dedicated signals? Which I do frequently! -
My project is to create an engine that allows anyone to develop GUI applications for any platform that the engine is available.
Is it NOT intended to allow developers to modify the engine itself. It will allow anyone using the engine to develop GUI applications with XML and JavaScript.
Kind Regards,
Sy -
My project is to create an engine that allows anyone to develop GUI applications for any platform that the engine is available.
Is it NOT intended to allow developers to modify the engine itself. It will allow anyone using the engine to develop GUI applications with XML and JavaScript.
-
That is something I will probably allow, so you can emit signals from JavaScript and connect them to slots in your own JavaScript. All signals that are available in the controls will be assessable via a subscription in XML.
@JonB, think about it as a developer, you want a GUI interface and there are a lot of controls available in Qt all of which you will be able to create and access using XML and JavaScript. If you want additional signals then you can create these in your JavaScript application.
-
@SPlatten Out of curiosity - how is your engine different from just using QML for example? I mean apart from the language syntax (QML vs XML). I'm asking because I rarely use these interpreted technologies (too much resource waste for my taste), but what you're describing sounds similar. Is it just that you prefer XML? There's also a QUiLoader class that can load XML based ui at runtime and you can expose that to a QJSEngine for example. Is what you're doing something more than that?
-
@Chris-Kawa , for starters, any changes you make to QML require a rebuild of the project that references it. The entire point of my offering is that the engine is static and cannot be changed, but the XML and JavaScript can be changed and reloaded into the engine with no recompilation required.
Its also multi-platform, the XML and JavaScript can be ported to any Operating System where the engine is available and with no changes it will work.
Kind Regards,
Sy -
@Chris-Kawa , for starters, any changes you make to QML require a rebuild of the project that references it. The entire point of my offering is that the engine is static and cannot be changed, but the XML and JavaScript can be changed and reloaded into the engine with no recompilation required.
Its also multi-platform, the XML and JavaScript can be ported to any Operating System where the engine is available and with no changes it will work.
@SPlatten said:
QML require a rebuild of the project that references it.
It does? I though you can just load it up from any file at runtime. Huh, I guess it just shows how little I use it :) Oh well..
-
@Chris-Kawa , originally thats exactly how I thought QML worked too, however having worked with it now for quite a while, I scratch my head and wonder how or why it evolved in the first place into what it is....because its like everything you can do in QML you can also do in C++, granted its a little simpler but you cannot do it without rebuilding the project.
-
@Chris-Kawa , for starters, any changes you make to QML require a rebuild of the project that references it. The entire point of my offering is that the engine is static and cannot be changed, but the XML and JavaScript can be changed and reloaded into the engine with no recompilation required.
Its also multi-platform, the XML and JavaScript can be ported to any Operating System where the engine is available and with no changes it will work.
@SPlatten said in Is this possible?:
QML require a rebuild of the project that references it.
It most definitely does not!!
I even expanded my main qml file to tricker a reload via F5 to quickly check visual changes (Sadly not a default feature)A rebuild is only needed, if you move your QML files in a resource file and load them from there, then a change requires recompiling. With local paths no recompile needed.
-
@Chris-Kawa , originally thats exactly how I thought QML worked too, however having worked with it now for quite a while, I scratch my head and wonder how or why it evolved in the first place into what it is....because its like everything you can do in QML you can also do in C++, granted its a little simpler but you cannot do it without rebuilding the project.
@SPlatten , @Chris-Kawa , also now @J-Hilk
Again, please don't take this as a negative comment! Bear in mind I know nothing about QML! :) But is https://doc.qt.io/qt-5/qml-qtquick-loader.html, https://qmlbook.github.io/ch14-dynamicqml/dynamicqml.html not a dynamic loader without compilation? -
@SPlatten , @Chris-Kawa , also now @J-Hilk
Again, please don't take this as a negative comment! Bear in mind I know nothing about QML! :) But is https://doc.qt.io/qt-5/qml-qtquick-loader.html, https://qmlbook.github.io/ch14-dynamicqml/dynamicqml.html not a dynamic loader without compilation? -
That's doable, but it means you will have to implement a repeater for every possible combination of any types of parameters. Unless you heavily limit possible signal signatures I don't think that's practical.
@Chris-Kawa said in Is this possible?:
That's doable, but it means you will have to implement a repeater for every possible combination of any types of parameters. Unless you heavily limit possible signal signatures I don't think that's practical.
@SPlatten I do understand where you are coming from and templates look like they should be able to do it. However, Qt does not play well with templates. Otherwise you might even be right with your approach. It would be something like templated slots. Would be really nice to have!
Unfortunately, C++ is still lacking some metaprogramming capabilities. In order to avoid too much code duplication for each possible combination of types in your signals' signatures I would in fact suggest using macros. You might want to have a quick look at so called X macros. Basically you would then
#definea list of signatures for your slots and then let a macro implement all the slots for this list. I would consider this use of macros cleaner than implementing the same over and over again. "Implementing" a new signature is then as easy as adding it to the list. Only disadvantage of this might be when you try to debug it (you cannot step through a multiline macro...).
