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

Mon Mar 22 19:52:46 CET 2021

Hello Eric,

I might be interested in using a solution like that. Also ImGui from my
point of view is a little bit too lightweight compared to Qt UI.
What is your opinion about: https://github.com/mitsuba-renderer/nanogui?

Anyway if you start a project like that I will be interested.
Best Regards,

Marcell

<eric.fedosejevs at gmail.com> ezt írta (időpont: 2021. márc. 22., H, 18:56):

> 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-bounces at qt-project.org> On Behalf Of Roland
> Hughes
> Sent: Monday, March 22, 2021 11:05 AM
> To: Jason H <jhihn at gmx.com>
> Cc: interest <interest at 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 at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210322/8de8e905/attachment.html>