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
