[Interest] FW: The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

[Jason H]

> Sent: Monday, March 22, 2021 at 6:54 PM
> From: eric.fedosejevs at gmail.com
> To: interest at qt-project.org
> Subject: [Interest] FW:  The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)
>
> Thank you for your informative reply Roland. I am curious whether any companies that you know of have considered switching to a cross-platform windowing library like SDL plus a lean immediate mode GUI (e.g. Dear ImGUI, Nuklear, Nanogui, or whatever else is current)? I really like the idea of doing this, since it eliminates all external dependencies, doesn't require any non-permissive licenses, and should work mostly unchanged until the end of time, as long as native GPU contexts are available.
> 
> I dabble in open-source desktop bioinformatics software. I'm currently using Qt5.15, but I can't see myself ever moving to Qt6 given the license situation and loss of Qt3D binaries. It was bad enough in Qt5 with the moribund desktop widgets and half-finished Qt3D. No interest in adopting a vendor-locked scripting language like QML, and I don’t want to use anything bloated or mobile-centric.
> 
> I guess I'll have to switch to something else over the next year or two once Qt5.15 starts to break with the loss of non-commercial LTS. I am trying to decide between switching to CopperSpice or SDL + ImGUI. The latter would be handy, since I can take a gradual approach, slowly moving functionality over to embedded SDL + ImGUI widgets in my existing Qt GUI until no more Qt is left. My main concern with doing so is that it will be a PITA to rebuild a large GUI with an immediate mode approach. I'll basically be building my own crappy retained-mode containers around ImGUI. It's too bad that there is no existing project that I'm aware of to create standard retained-mode wrappers around ImGUI etc.

I'm not so worried about QML being vendor specific. It should only be a binding language.  

At my new place, our product is on LVGL, a MIT licensed library. It's C, but there are C++ and Python bindings as well. It is every bit as verbose as you imagine C code would be, :-( but it runs on anything down to PIC/Arduino. 

It's amazing all the competition Qt is _enabling_ rather than capturing... And it's all because of license issues.