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

[Roland Hughes]

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