Alternative GUI for FreeCAD: Overlayed Layout (Devs needed)

A forum for research and development of the user interface of FreeCAD
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

Re: Alternative GUI for FreeCAD: Overlayed Layout (Devs needed)

Post by Kunda1 »

Welcome to the forum, @maxlem
Interesting story.
maxlem wrote: Fri Jul 26, 2019 2:46 am What I have in mind would look more like a rewrite. Python is much more fun and fast-paced.
A rewrite of this specific 'layout' branch ? or are you referring to something else?
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
maxlem
Posts: 26
Joined: Fri Jul 26, 2019 2:32 am

Re: Alternative GUI for FreeCAD: Overlayed Layout (Devs needed)

Post by maxlem »

Well, I see lot of people complaining about FreeCad ui in general, I'm a qtquick-for-cad specialist, this layout project is the only qtquick inroad i know of, si here I am.

What I want: learn FreeCAD and be able to improve it

What I need: guidance as to where my efforts would be best spent
User avatar
Kunda1
Veteran
Posts: 13434
Joined: Thu Jan 05, 2017 9:03 pm

Re: Alternative GUI for FreeCAD: Overlayed Layout (Devs needed)

Post by Kunda1 »

maxlem wrote: Fri Jul 26, 2019 3:53 pm Well, I see lot of people complaining about FreeCad ui in general, I'm a qtquick-for-cad specialist, this layout project is the only qtquick inroad i know of, si here I am.

What I want: learn FreeCAD and be able to improve it

What I need: guidance as to where my efforts would be best spent
The way I've seen it work is people start to dig and then they ask questions or help with solving a bug or they ask specific technical questions. Mentors aren't hand-holders here...it's more like: 'if you take the time to ask a question that your researched well (which we'll be able to tell by the quality of the question) then we'd enjoy trying to provide a direction on how to solve it'

The issue also to is that we're in the midst of deciding the best way to document FreeCAD since the codebase is a mixture between c++ and python. As I was reading in a recent thread doxygen is better suited for c++ where as something like sphinx is better suited for python. In other words, you'll be navigating some undocumented waters in this process, most likely.

Perhaps if you get started studying some of ickby's work using the old pyside to create the proof of concept that is demonstrated in the first post of this thread? And start asking questions ?
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
maxlem
Posts: 26
Joined: Fri Jul 26, 2019 2:32 am

Re: Alternative GUI for FreeCAD: Overlayed Layout (Devs needed)

Post by maxlem »

Sorry if my post sounded like I wanted hand-holding. I was rather looking for an educated point of view on where my time should be best spent. This is not hand holding, this is vision. I don't have a good vision on where the FreeCAD community wants to go to improve the ui.

Yes I can begin by having ickby's prototype working, and then port it to PySide2/qtquick2. If you think its best, well that is all the guidance I need.

Will try building the aforementioned fork soon.
maxlem
Posts: 26
Joined: Fri Jul 26, 2019 2:32 am

Re: Alternative GUI for FreeCAD: Overlayed Layout (Devs needed)

Post by maxlem »

So I tried building ickby's fork (https://github.com/ickby/FreeCAD_sf_master)

I followed https://www.freecadweb.org/wiki/CompileOnUnix for ubuntu, used the daily ppa, but qt4/python2 instructions have been removed. I installed the single command qt5 build instruciton and tried anyway.

cmake failed to find shiboken.

maybe the build instrucitons should be contained in the .md so that they are versionned.

so, I'll try to help with the pie-menu issue instead
User avatar
kkremitzki
Veteran
Posts: 2511
Joined: Thu Mar 03, 2016 9:52 pm
Location: Illinois

Re: Alternative GUI for FreeCAD: Overlayed Layout (Devs needed)

Post by kkremitzki »

The code is old enough at this point that compiling it is probably close to impossible, but if you study the commits exclusive to that branch it may be possible to re-implement the same logic.
Like my FreeCAD work? I'd appreciate any level of support via Patreon, Liberapay, or PayPal! Read more about what I do at my blog.
maxlem
Posts: 26
Joined: Fri Jul 26, 2019 2:32 am

Re: Alternative GUI for FreeCAD: Overlayed Layout (Devs needed)

Post by maxlem »

Yes, I could do that. I may, actually. Yet I fear it may not be possible without significant changes for FreeCAD core. The way I know to render opengl in a QtQuickItem is using QQuickFramebufferObject and using a QQuickFramebufferObject::Renderer derivation as a renderer. This way your 3d viewport is rendered as the texture of a QQuickItem, and this makes everything very simple. There are other ways, but, none that I know of that is not just looking for trouble. It's also plenty fast, no GPU-CPU transfers afaik.
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: Alternative GUI for FreeCAD: Overlayed Layout (Devs needed)

Post by ickby »

hello. Nice that you want to pick this up! I try to help as much as possible based on my experiance from the old try.
Yet I fear it may not be possible without significant changes for FreeCAD core
Actually it was suprisingly limited to get it working. Lookjing through my own commits I can't really remember everything, but I think I got it working in a few days.

I couldn't find where I added in the QML main object, maybe as a replacment for the MDI area, maybe I changed the MDI area to be a qml mai object... For making the 3d view a qml item some changes to quarter have been nesseccary, chaning the base class, and then rendering the scene graph.

Most likely for QT5 things work differently... I think the most important thing is to change everything in a manner that the user in the end can decide if he wants the standart interface or the new dynamic one. I think all core changes can be done "UI neutral" and than a simple switch from standart ui layout to qml can be included into the preferences.
]The way I know to render opengl in a QtQuickItem is using QQuickFramebufferObject and using a QQuickFramebufferObject::Renderer derivation as a renderer
That could be a good idea. If I remember correctly the drawback of my method was that every 3d render triggert a ui redraw, and every ui redraw triggered a 3d render (as everythign was drawn in a single opengl rendering pass). The problem with that is for large models the ui gets sluggish as the 3d rendering may not be possible with 30Hz... it is rather bad to link ui redrawing with 3d performance. So your idea could decouple that.
maxlem
Posts: 26
Joined: Fri Jul 26, 2019 2:32 am

Re: Alternative GUI for FreeCAD: Overlayed Layout (Devs needed)

Post by maxlem »

Hi ickby,

Thanks for the reply. I actually went through both qtquick 1 (QDeclarative) and qtquick2, and as far as I remember (I did the qdeclarative opengl viewport back in 2013 or so), QDclarative was closer architecturally to QWidget than QtQuick is. Under QtQuick, all items are collected and batch rendered in a different thread.

I will look closer to your suggestions later. The end solution will obviously use https://doc.qt.io/qt-5/qwidget.html#cre ... wContainer. And, hopefully, the FreeCad API will help me talking to the non-qtquick sections of the application through a QObject-API. Like QWidget, QtQuick is based on QObject and does everything through signals and slots, so all should be well.

I still suspect I will have an hard time reaching the holy grail: rendering FreeCad 3d viewport in a QQuickFramebufferObject::Renderer::render() call. That would unlock the whole power of qtquick2.
ickby
Veteran
Posts: 3116
Joined: Wed Oct 05, 2011 7:36 am

Re: Alternative GUI for FreeCAD: Overlayed Layout (Devs needed)

Post by ickby »

And, hopefully, the FreeCad API will help me talking to the non-qtquick sections of the application through a QObject-API. Like QWidget, QtQuick is based on QObject and does everything through signals and slots, so all should be well.
It depends on how you want to interact with the system. My approach was to not rebuild the UI functionality, just use QML for the layout. That means I reused all the widgets, the tree, property editor etc.: I exposed them as QML types and only changed them slightly to fit visually in. Then in QML I arranged them, added headers for control etc. The advantage for that is that all the complicated UI code did not to be redone. The disadvantage of course was that QML did not have access to any freecad object, so one could not create a real new UI widget.

IMHO if you want to grand QML access to FreeCAD objects and allow manipulation you will have a hard time. You need to port FreeCAD objects and its property system over to a QObject based one... this would be a treamendous effort with IMHO little chance of success.
I still suspect I will have an hard time reaching the holy grail: rendering FreeCad 3d viewport in a QQuickFramebufferObject::Renderer::render() call. That would unlock the whole power of qtquick2.
Yeah, that is definitely the first step. Using the coin3d rendering is actually straigth forward, but of course framebufers are tricky. I highly recomend looking at the View3dInventorViewer code, as it does support rendering to a framebuffer: https://github.com/FreeCAD/FreeCAD/blob ... Viewer.cpp. This could bring you a long way already, maybe even allow simply reusing of the viewer and wrap the QML part around.
Post Reply