Mid-term alternative UI for Labrador?

[mi-hol]

That said, I was working with some students last year to develop a version based on ImGui Librador:
https://github.com/davidjstark/LabradorENG4701

Seems to be much more performant and stable than the main branch, and significantly less code/dependencies/tech debt.

Originally posted by @EspoTek in #282 (reply in thread)

[mi-hol]

I was working with some students last year to develop a version based on ImGui Librador:
https://github.com/davidjstark/LabradorENG4701

the commit title Refactoring codebase to abstract away the ImGui logic from our application logic. Supports Object-Oriented Design seems to capture the goal of this fork quite well. Did I get this right?

[mi-hol]

Concept explained on https://en.wikipedia.org/wiki/Immediate_mode_(computer_graphics)#Immediate_mode_GUI

Implementation for C++ on https://github.com/ocornut/imgui/wiki

Any thoughts?

[EspoTek]

I guess the real question is - is it worth proceeding with the Qt interface, or switching across to ImGui?

@turboencabulator
@mmehari

[EspoTek]

As annoying as this probably sounds, (and as much I viscerally loathe Qt 😝), I think the best plan short-term is to just stick with the UI we've got.

It'd be a fair amount of work to get the ImGui version up to speed with the Qt version, and work we do on the Qt version isn't wasted - most of the actual backend code doing the "heavy lifting" can easily be copy-pasted across.

[mi-hol]

I think the best plan short-term is to just stick with the UI we've got.

I'd share your view & comments, tried to acknowledged them by changing title to "Mid-term alternative UI for Labrador?".
@mmehari @turboencabulator any thoughts?

[mi-hol]

download stats of "old" Labrador via https://qwertycube.com/github-release-stats/

[EspoTek]

Wow, that's way more than I thought!

[mi-hol]

And this does not includes "clones" to build the App ie on RaspberryPi!

[mmehari]

I would also agree to hold it off for a while and keep using what we have.
Furthermore, we have a number of issues and features to complete and switching to a new UI might complicate the matter.
After the dust gets settled, we can tackle the problem.

[mi-hol]

While I tried to answer Keyl's question "what minimum Qt version we want to support?" I became aware of some support issues for QT. According to https://endoflife.date/qt what is supported becomes complicated.
The company recommends QT 6.8 (LTS) version but even then support for OSS will end soon (08 Apr 2025)!

"The KDE Project maintains a patch collection to support Qt 5.15 LTS for open-source users. Moreover, the code of commercial releases is made open within 12 months and some level of security support still seems to continue in the form of code patches. This does not reflect in the table above as we only track official releases from https://www.qt.io/."

[mi-hol]

I went to QT's company home page to better understand above but struggle.

https://www.qt.io/product/features?license-model=gpl-v3&development-platform=linux&target-platform=windows&coding-language-support=c%2B%2B&qt-edition=qt-community-edition&sdlc-core-activity=develop

Would my selection above allow us to download everything needed for development & distribution?

[mi-hol]

just stumbled over a project that used Qt5.12 and when migrating to Qt6.7 was unable to build an AppImage.
Instead of AppImage flatpak was chosen as distribution/deployment vehicle
probonopd/go-appimage#301 (comment)

[EspoTek]

We definitely want to stick with Qt 5 in the medium term. Moding to Qt 6 would require a pretty substantial rewrite, and at that point we'd be better off dumping Qt altogether and moving to ImGui.