What strikes me the most is the integration capabilities of QML. One can argue you can do all this with our python binding into our components (PySide, Pivy, ....) but in practice you need a very deep knowledge of all the frameworks and lots of FreeCAD internals, like ViewProviders and many more... So very little people actually do it. In fact, if you want to do 2D and 3D in FreeCAD you are better of with C++ (maybe I'm a bit biased
A small thought experiment:
You have a project and get a list of positions in a 3D design (maybe collisions or points of interests). You want to write a small extension in FreeCAD to show that points to the user with a little 3D object and a small dialog/ui with a list. Do some camera handling some actions (maybe dismiss some of this points).
So nowadays in FreeCAD you would have to make commands, a feature and a ViewProvider for that feature (either C++ or Python). You would have to use Pivy/Coin3D to set up a custom scene graph to show up the 3D elements. Interaction with the 3D objects is nearly impossible. For the dialog you would have to create a .ui file or put the widget together by hand. Also a tedious task! It will cost you hours of work and you have to circumvent a lot of pitfalls. You use lot of frameworks which has different philosophy and you write tons of boiler plate code.. I have to say - not very attractive to developers (or power users).
So, and what can QML do about it?
You can put all the declarations and interaction in one QML file! You can declare the dialog with a view lines of code. You can create a 3D component. exchanging highlighting of elements in a list and the 3D view is only one line which makes the connection.
Whats also is quit impressive, is the turnaround time! Such FreeCAD extensions can be changed and tested by just reevaluating the QML file, which makes a tremendously fast development!
Also the QML/Java script metaphor is quit settled, so not so much special knowledge is need for devs..
Hard to implement?
Quit not. Since we use Qt all around FreeCAD it would integrate quit nicely. What we would need for the start is simple wrappers for Document, 3D-View, and our Gui::Command facility. Werner and me anyway thought about making a proper Qt-Model for the document to have good binding to the tree view.
You can use all well defined Qt widgets one-O-one in QML, e.g. InputField. You can just connect the signals and slots...
Other areas QML would improve development:
Managing overlays on the 3D View:
Its basically (I think) whats on Ickbies mind.
Sure we can write a Window-Manager for the 3D View and hard code flag and dialog overlays. But its like always on Gui's, for the next use case you need a special treatment of Flag "A" and Dialog "C". So if we do the handling of this components declarative, we need only provide a model interface for the 3D view and the rest can be done in a QML file. And the dev/user has full control about the overlays. Can even add fancy stuff like video or other things we not even think about!
At the moment we have lots of custom tools to add Menus, Toolbars, Task-Watchers and so on. Its quit a own implementation to declare
a workbench Gui. QML is just build for such a use case!
Think of a Workbench Gui is defined by QML? You could easily integrate all FreeCAD widgets and anything else Qt has to over quit simple. With a view lines of code you can create a complete customized FreeCAD Gui for special projects or limited user interactions. And we can throw away all our special Gui declaration code!
Feature Edit dialogs:
With QML we can put all the user interaction, like Dialogs, 3D or even menus and dialogs at the 3D objects, in one QML file and make it easily changeably and accessibly. Our Features has anyway a well defined object oriented Property interface, which should be easy accessibly via QML. Even the onChange on Properties can be easily translated into the signals and slots...
In my last projects I did with FreeCAD I made a frighting experience: Writing the data-structures and algorithms was quit fast and fun. Writing the Gui was tedious and need ten times more time! One reason is the compile/startup/data-load time of FreeCAD is quit long now, and thats quit a problem with Guis, since you do lot of small changes there.
So locating the Gui and user-interaction in one place and make the turnaround much faster will greatly benefit the dev process!
Generally I think hard-coded Gui's will not take us into the future....
But so far I will just do some investigations
, I'm not positive it will technically work that way! You never know till you tired trying