Alternative GUI for FreeCAD: Overlayed Layout (Devs needed)

A forum for research and development of the user interface of FreeCAD

Moderator: agryson

User avatar
Kunda1
Posts: 5201
Joined: Thu Jan 05, 2017 9:03 pm

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

Post by Kunda1 » Fri Jul 26, 2019 4:06 am

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?
Want to contribute back to FC? Checkout:
#lowhangingfruit | Use the Source, Luke. | How to Help FreeCAD | How to report FC bugs and features

maxlem
Posts: 20
Joined: Fri Jul 26, 2019 2:32 am

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

Post by maxlem » 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

User avatar
Kunda1
Posts: 5201
Joined: Thu Jan 05, 2017 9:03 pm

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

Post by Kunda1 » Fri Jul 26, 2019 4:21 pm

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 ?
Want to contribute back to FC? Checkout:
#lowhangingfruit | Use the Source, Luke. | How to Help FreeCAD | How to report FC bugs and features

maxlem
Posts: 20
Joined: Fri Jul 26, 2019 2:32 am

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

Post by maxlem » Sat Jul 27, 2019 6:30 pm

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: 20
Joined: Fri Jul 26, 2019 2:32 am

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

Post by maxlem » Sat Jul 27, 2019 10:08 pm

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
Posts: 1678
Joined: Thu Mar 03, 2016 9:52 pm
Location: Texas

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

Post by kkremitzki » Sat Jul 27, 2019 10:31 pm

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: 20
Joined: Fri Jul 26, 2019 2:32 am

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

Post by maxlem » Sat Jul 27, 2019 11:49 pm

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
Posts: 2914
Joined: Wed Oct 05, 2011 7:36 am

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

Post by ickby » Mon Jul 29, 2019 5:39 am

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: 20
Joined: Fri Jul 26, 2019 2:32 am

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

Post by maxlem » Mon Jul 29, 2019 1:24 pm

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
Posts: 2914
Joined: Wed Oct 05, 2011 7:36 am

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

Post by ickby » Tue Jul 30, 2019 6:02 am

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