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.fedosej...@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-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 >
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest