Alternative GUI for FreeCAD: Overlayed Layout (Devs needed)

[ickby]

OK i see your point. Yes, making QML easily integrated into FreeCAD is something promising. IMHO it is quite easy to add a widget which shows QML UIs, and integrate that widget into the default widget based UI.
More problematic is the logic part: If you want to add any reasonable functionality into QML UIs with ease of use you need to expose the FreeCAD API to QML. Not sure how this can be done easily. Otherwise you need to implement the UI functionality in python or c++ with callbacks to this code for QML, but that is clunky and removes the ease of use of QML. IMHO this is the critical part of integration.

In my old code I omitted that, and did not implement any FreeCAD logic in QML, only the UI logic (animations etc.).

I definitely hope you come up with something, thats an interesting challenge!

[Pauvres_honteux]

Ooh, this sounds so intriguing!
We might finally get that illusive "the tree, the whole tree and nothing but the tree" GUI !
Crossing all my tentacles!!

[maxlem]

Hey guys,

Guess who's back from the dead. Not implying I have tons of time to invest but I *might* have a bit more 2 weeks from now. Still quite busy with my startup.

Also, meanwhile, I see pyside2 have made good progress and python is now a 1st class citizen in the Qt ecosystem.

So, I'm kinda throwing a line here. I know QtQml very very well. I also know python and C++ very very well. I'm also very familiar with CAD (mesh, nurbs) algorithmcs, I used to design specialized CAD software 3 year ago. What I need is someone who knows FreeCAD very well, so I don't get discouraged again with the boilerplate...

My absolute ideal would be someone who would take the lead while I review and make suggestions...

Another guy with a few hours a week to spare, and I might be back....

[maxlem]

ickby

agreed, the work you did with qt quick is quite dated, as i believe you even stated you did your work with a version of qt in the 4.x series, more than likely it was 4.8.x and above because from what i understand that was about the qt group added support for QML. and to the best of my knowledge your fork and experimentation is the only version of freecad that attempts to even use QML. i bring all this up because as great as the qt widgets are they are becoming dated, and aren't receiving the same amount of attention that the qml qt quick libraries are receiving obviously qt will continue to support widget based apps, ie. freecad for time being, but eventually i believe widgets will reach EOL. so putting in a little effort to explore QML and to see how some of it can applied to freecad seems worth some attention. i'm not saying the entire app has to be migrated to QML and that all support for widgets needs to stop, but having an understanding of qml and how it can work with freecad seem like a valuable effort of time.

i understand the realthunder fork is doing some great work with updating the ui and i don't discourage what he is doing at all, but doing a quick search through his fork i didn't notice any qml based gui elements, which makes me think he's doing some heavy lifting with customizing the stylesheet elements (qss files) of the app to achieve a lot of his updated ui. i haven't fully explored his fork or sifted through the commits so correct me if i'm wrong please.

for me personally i'm more interested in incorporating ui elements using qt quick and qml. if i get anywhere with it, i'll def post back and try best to explain what i'm doing and what i'd like to achieve.

cheers
chris

Hello ipatch,

I had a (very quick, diagonal) look at your github. Have you managed to build from source? Did you begin trying out to integrate qtqml?

[ipatch]

maxlem

I can successfully build the standard freecad/freecad source hosted on github, ie. the master branch on macos using dependencies provided by brew, but run the cmake, make, make install process without the dependency of a formula file thus allowing for more flexibility of specifying compilers, sdks, install paths and what not. I ended building the realthunder branch yesterday which was giving me some issues, but have since resolved. i haven't even begun to experiment explore the settings provided by the realthunder fork but look forward to seeing what it offers as i've seen several of the youtube videos showing of the features of the fork.

as for ickby's experimental branch all i have done is setup the remote for my fork of freecad, cloned the fork, and created some local branches, but haven't even attempted to build it yet. i know it relies on qt 4.7.x or above as that's when qt introduced qml, but other than that i haven't done anything else with it. when i get some more time i'll go about setting up the dependencies ie qt 4.x which i'll have to install for my version of macos, which i am sure won't be the most straight forward install. and may rely on getting the python 2.x dependencies rolling if the fork relies on those as well. so,

1. get the current fork/branch (ickby's qml) built with little modifications if any using the dated dependencies
2. make necessary mods to see if fork can use newer deps, possibly use qt5 and or python 3
3. begin to make sense of the bookmarks i've made exploring adding QML to an existing qt widget based app learn more

i hope that gives you an understanding of where i'm at, i think i bookmarked / added a lot of useful links to my freecad notes related to qt, qt widgets and qml, (i just got spend time going through them and pick out the useful bits) hopefully something tangible from them will bubble up sooner than later.

---

a few other things i'd like to get done related but not so related

- explore experiment with creating a standalone macos app bundle of freecad using native cmake tooling

> it'd be nice to have a standalone app bundle with all the dependencies built into the bundle thus not relying on my system deps during runtime, thus making using freecad a little less brittle, (homebrew updates deps at a rapid rate, which can make things stop working rather abruptly)

---

• i started working on a userscript for autoloading the next page of forum threads because clicking the little next page button really breaks the flow of reading multipage threads, and clicking back and forward is not the best, so i'd like to complete that userscript sooner than
  later.
• ---
  • i got the observable setup and the xhr ajax request going and loading next pages going, but need to wire up the xhr request to fire with the observable is triggered, and possible add some sytling to signify the page ie. how duckduckgo handles loading the next page of results.
  • ---
  • i also didn't setup an observable or xhr request for loading prior posts within a thread so if you start at say page 3 of a 10 page thread because you did a search or clicked a link that references a post within a thread and you want to scroll back through the thread history, it'd be nice to use the same technique to load prior posts within a thread.
  • ---
  • basically it's really close to complete but kindof got distracted / juggling other things AFK and and IFK, just need to block off some time and complete it, ie. sooner than later. if your interested in what i was working on, you can check it out here