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. Best, Eric -----Original Message----- From: Interest <interest-boun...@qt-project.org> On Behalf Of Roland Hughes Sent: Monday, March 22, 2021 11:05 AM To: Jason H <jh...@gmx.com> Cc: interest <interest@qt-project.org> Subject: Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...) On 3/22/21 9:22 AM, Jason H wrote: > Roland, what did those companies move to? That's what myself and Konrad have been comparing notes on. "The market" hasn't settled on "one thing." The set-top boxes all went to RDK along with Opera browser. The "Explore this computer"/Kiosk market seems to have all dumped Qt for Electron due to the licensing. The Intel one went that way at least. A good number of Qt based things are now hanging out on the CopperSpice forums and asking for porting help. CopperSpice not quite there yet as far as a locked down API but good enough for a lot of things. You have to mentally shift design gears though because there is no CoW. One has to get used to using references and pointers again because those big objects will actually get copied. A few have gone with that DOT-NOT-anywhere thing of Microsoft. The medical device world is really kind of flailing around right now. Nobody is willing to pay for Qt given the new license and death of perpetual license. The ex-wife ransoming of the children didn't sit well either. NONE of them will pay royalties. > Some other inexplicable decisions are why there isn't Qt for Raspberry Pi as > a supported platform? A debian package would go along way to introduce people > to Qt there in the hobbyist sector, but it's a compile-it-for-yourself > situation. That compile it yourself thing isn't smooth either. _Most_ of the on-line instructions only successfully build a tiny subset of Qt. Then you end up picking up host libraries for things like PostgreSQL. Been there. Done that. Got the hat, T-shirt, bumper sticker, and water bottle. > There is no grass roots support for Qt as a result. KDE has __not__ helped that issue over the years. The continued abadonware (blogilo anyone?) https://apps.kde.org/en/blogilo KWord? now forcing that God-awful Calligra on everyone. KMail. The continually updating and corrupting database. Right now there is only one distro with a descent KDE implementation and that is Manjaro. Adding insult to injury, the Juffed editor seems to be in every repo and if one installs it the thing trashes your Qt environment. > And with the licensing issues of late, they've ensured that there won't be. > This means that they have to rely on and cater to the big spenders boys in > the market. You know. The medical device world has some pretty big spenders. When they can buy a one & done license and use it perpetually across multiple product lines with only a tiny support contract they usually bite the bullet. I've worked on devices where they paid around $600K for Qt. They honestly didn't even need to get a commercial license for what they were doing. They bought it just to remove a possible future issue. There is no way in God's green earth they are going to pay royalties though. $600K is an awful lot for one dude writing a phone app. When you are going to create N different medical devices where unit sales will be 50K to 3 million units for each device, $600K is not much. It's an overhead cost that ends up being amortized across millions of units. When the ex-wife wants $5/unit on top of a license fee that is the end of Qt in the medical device world. So far I have not found two medical device projects that started __after__ the license FUD of killing off OpenSource LTS, etc. that have used the same libraries. Some are trying Electron (it's not actually in anything yet that I know of) others are kicking the tires on CopperSpice. Other things people are kicking tires on right now: U++ BSD license https://www.ultimatepp.org/ OpenZinc LGPL http://openzinc.com/Overview.html Nana Boost Software License http://nanapro.org/en-us/ RDK Unknown - license must apply for license but says there is no charge https://rdkcentral.com/ Chromium Embedded Framework BSD license https://bitbucket.org/chromiumembedded/cef/src/master/ What __has__ changed in the medical device industry is all UI is now being designed client server on paper. Only the really good companies were doing that before. The rest were just making one big Qt application. Most new designs (and some old ones) are optically isolated via a publish-subscribe message queue. UI <--> MessageQ <--> Devices Zinc is still an application framework but it was mostly UI back in the day. I don't know if Wind River fixed the event loop so devices could be plugged in. What was unique about Zinc was the fact it was/is a wrapper library. Other than under DOS and raw OS/2 (sans PM) it provided a common wrapper subset for the OS level UI stuff. Zinc has both an OpenSource and commercial version. For years (and possibly still) Wind River systems used it as their default UI library after acquiring it. Now it seems to be spun back out on its own. Having a UI library in your commercial embedded OS was a big selling point back in the day. I haven't heard any real feedback about U++. I spent about 10 minutes with U++ myself some time back. There is a bit of a stiff curve with it and you __have__ to use TheIDE. Nana (and several other library only UI libraries) are getting looked at because they are just that. You aren't locked into a framework and said framework's event loop. The rest of the things being looked at are basically browser based. Not everyone has gotten comfortable with the new architecture that MUST be used. There is still a lot of one device == one app thinking out there. The serialization and deserialization combined with message queue does add quite a bit of overhead on under powered processors. This is especially noticeable when said hardware has lowsy dynamic memory allocation. I don't bother following the phone app market, so cannot help you there. -- Roland Hughes, President Logikal Solutions (630)-205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
