QML in FreeCAD

[jriegel]

Ickby did a great job to switch our 3D viewer and Quarter to a new foundation. That lead me to (re)investigate QML again. I found this video which got me quit exited:

https://www.youtube.com/watch?v=Ng1PuboEeYo

Its a integration of QML with the Coin3D scene graph which makes it possible to code 3D artifacts and dialogs in QML and let them talk to each other. Also the integration of QML dialogs in the 3D space is shown.

Though or a good integration of QML into FreeCAD we would need to expose a lot of interfaces into the QML space which would duplicate our python interface. So besides Python/PySide/Pivy we would have QML/Javascript. Normally I would say it makes no sense to have two competing metaphors, but that damn demo was quit compelling... Writing dialogs/logic/3D with QML in a HTML style way is pretty cool.

So I will do a test implementation and see what I got to fly....

[ralvejd]

<OT>
Fun coincidence regarding IPO.Log.
We are doing a pilot study at work about IPO.Log and Siemens Teamcenter integration.
The main output, Bill of Materials (BOM), Bill of Processs(BOP), Time analysis(SAM) and Work instructions.
I only participate in the project with feedback as a user.
We should hopefully see where it goes in the end of this year.
We already use Teamcenter for virutuell build in early phases, so the step to add more functionality feels quite natural.
</OT>

[xat]

Hi,

On the same subject, the Qt project just added a new QOpenGLWidget to Qt 5.4.

http://blog.qt.digia.com/blog/2014/09/1 ... nglwidget/

It has the same API as the old QGLWidget but:
- it unifies code with QTQuick/QML
- i has better performances
- permit natie incluson of qt wdget with transparency
...


I suppose it would permit to use QML object in the 3d view too.

[ickby]

I did not watch the whole video, but to be honest I don't see that much benefit in this, definitly not enough for the effort needed. Maybe it is possible to generate the QML interface from the xml files in the freecad source automaticly, but if one needs to do this by hand... man that would be alot of work! And the only benefit over a normal python script would be the the easy integration of menus and stuff into the 3d scene. This is now possible anyway with the new quarter based implementation, and even more versatile as you can use QML and normal widgets.

EDIT_: just saw that thex add the menus/qml controls not ontop of the 3d scene but into the 3d scene, that is a cool gimmick still, I realy don't see any real life benefit of this, but maybe my phantasie is just not yet fueled by enough coffee

@xat: nice, I did not look into qt5 until now. Maybe if we switch one day to qt5 we can use this new widget, however, the integration of QWidgets into the 3d scene is already possible wth the latest changes in the source. (even if not that 100% reliable for all cards/drivers as one example has shown, that would be definitly a advantage of a qt native implementation)

[jriegel]

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!

Workbenches:
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 general:
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

[ickby]

Ah I see, you think in a bigger picture. Well, that sounds definitly awesome. I suppose in the end you would like to have something simple to create like this?

Code: Select all

 Workbench {
     name: "Awesome"
     icon: arrow

    ViewProvider { 
         name: "myToolViewprovider"
         scene {
            node: box
         }
     }

     Command {
         name: "doSomethingAwesome"
         onClicked: { documentObject.MyProperty = 1}
     }
 }

[yorik]

But, however cool the overlay widgets are, Is it really powerful for "real stuff" where you need to interact inside the 3D itself? how would that work with the 3D view? coin also has a kind of signal/slots system (called Fields IIRC), no? Could there be a way to make that communicate with qt? Imagine a qt slot that turns off a coin node!

[jriegel]

Besides the first Video I posted, here is another example of the interplay between 2D and 3D:
https://www.youtube.com/watch?v=kvWeE3kurEQ

The Gui of the this software is completely written in QML...

[maxlem]

see my other post

Hi there. I'm looking for a linux oss cad software to design some robotics. I learned a bit of PRO engineer a few years ago, but I'm pretty green as a CAD software user. Where it gets interesting is that I use to actually develop a custom CAD software aimed at the orthopedic market. The ui was qtquick 1, then we moved to qtquick 2. The core was in C++ and OpenCL. Right now I work somewhere else but I still use qtquick 2, but with PyQt5.

So there it is, I'm kind of dipping my toe. I don't have much time but I may be able to do a lot with very little effort if guided right. I would learn FreeCAD as a bonus.

What I have in mind would look more like a rewrite. Python is much more fun and fast-paced.

I could also menthor someone for the qtquick/python side of things.

So here I am, I can confirm that it is possible to use QML to obtain tight 2D-3D interraction, and yes the concept of a property binding is very powerfull. I have a long list of lessons learned, though. You must be disciplined to use QML for its strengths and keep away from its weaknesses. It also can prove to be challenging to debug.

Still, it is very agile language for ui. And if you look at where most advanced ui (mobile os) are going, the concept of binding is everywhere, and I have not found a more elegant MVVM implementation that Qt's. It is also getting quite mature.

[maxlem]

Meanwhile, I'm looking for a python macro that managed to use QtQuick5, I'm not sure it's possible since I don't know FreeCAD's core. QWidgets and QtQuick can't be mixed and match that easily.