Re: [Interest] L Word

[eric.fedosejevs]

So basically open source/standard Qt was considered appropriate for safety 
critical devices prior to the introduction of Safe Renderer in 2017, but now 
only commercial Qt with Safe Renderer is appropriate for that purpose.

 

Before anyone says otherwise, Qt was widely used in safety critical 
applications before Safe Renderer existed. See for example the text from 
introductory blog post about Safe Renderer:

“Industries such as automotive, medical and industrial automation, where Qt is 
the leading UI framework, can now satisfy safety critical requirements with Qt 
easier than before.”

 

From: Benjamin TERRIER  
Sent: Monday, May 3, 2021 11:46 AM
To: Matthew Woehlke 
Cc: eric.fedosej...@gmail.com; Qt Interest 
Subject: Re: [Interest] L Word

 

 

Le lun. 3 mai 2021 à 17:33, Matthew Woehlke mailto:mwoehlke.fl...@gmail.com> > a écrit :

On 03/05/2021 11.23, eric.fedosej...@gmail.com 
  wrote:
> I find this whole argument that Qt is not appropriate for functional 
> safety very puzzling. Aren’t vehicle dashboards QtC’s main market
> these days? What are vehicle dashboards if not safety critical?

Are they? I thought it was infotainment systems. There's quite the 
difference between those two. (At least in most cars; Teslas I think may 
be starting to blur that distinction, and to an extent that likely 
alarms some people.)

 

Qt is also used for vehicle dashboards.

But yet Qt is not to be used for functional safety.

That's the sole reason for the existence of Qt Safe Render, which is suited for 
functional safety.

 

The idea is that Qt is used to display 3D eye candy, while Qt Safe Render 
displays critical information.

Meaning that if Qt fails/crashes it has 0 consequences to functional safety 
because the Qt Safe Renderer is still displaying what's important for the 
functional safety.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] L Word

[eric.fedosejevs]

Prime billing on QtC's front page is a picture of the combined 
dashboard/infotainment system for the 2019 Mercedes-Benz A-Class.

Dashboard is definitely safety critical in eyes of regulators. Infotainment 
system too if is integrated with backup cam.

-Original Message-
From: Matthew Woehlke  
Sent: Monday, May 3, 2021 11:33 AM

On 03/05/2021 11.23, eric.fedosej...@gmail.com wrote:
> I find this whole argument that Qt is not appropriate for functional 
> safety very puzzling. Aren’t vehicle dashboards QtC’s main market 
> these days? What are vehicle dashboards if not safety critical?

Are they? I thought it was infotainment systems. There's quite the difference 
between those two. (At least in most cars; Teslas I think may be starting to 
blur that distinction, and to an extent that likely alarms some people.)

Oh, fun story... before it died entirely, my Prius's dashboard would sometimes 
fail completely. The car still *moved*, but I had no idea how fast I was going, 
or how much fuel I had left :-D. Fun times... and an interesting point of 
discussion for whether or not the dashboard is, in fact, "safety critical".

-- 
Matthew

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] L Word

[eric.fedosejevs]

I find this whole argument that Qt is not appropriate for functional safety 
very puzzling. Aren’t vehicle dashboards QtC’s main market these days? What are 
vehicle dashboards if not safety critical?

 

If Qt is no longer appropriate for embedded medical devices, why is it still 
appropriate for vehicle dashboards?

 

From: Interest  On Behalf Of Benjamin TERRIER
Sent: Thursday, April 29, 2021 11:27 AM
To: Bob Hood 
Cc: Qt Interest 
Subject: Re: [Interest] L Word

 

 

 

On Thu, 29 Apr 2021 at 15:15, Bob Hood mailto:bho...@comcast.net> > wrote:

On 4/29/2021 4:02 AM, Bernhard Lindner wrote:



Obviously, Qt has nothing to do with this type of software engineering. And 
it's obviously
not suitable for functional safety (at least not if you take it seriously).


If this statement is true and Roland's statement that TQC actively courted that 
industry is also true, then it seems to me that he has a valid grievance, 
regardless of how he presents it.

 

TQC actively courted that industry, but it does not mean that they intended Qt 
to be part of the functional safety stack.

As a proof to my above statement I bring you the Qt Safe Renderer. It is a 
commercial product from TQC targeted to functional safety industry, so yes TQC 
has courted this industry.

However, it also means that Qt itself was never meant to be a part of the 
functional safety stack and is not supposed to mess with it.

The issue at hand here is not that Roland has a valid grievance or not. At 
least some of the issues he raised are valid.

The issue is that his emails are numerous and have a very low signal/noise 
ratio, that he is borderline insulting to anyone who is out of his industry and 
that in the end it lowers the value users are getting from this mailing list.

And personally I'd add that he is so badly advocating for his grievance that 
I'd prefer him not to advocate for the points where I agree with him.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

[eric.fedosejevs]

> From: Interest  On Behalf Of Vlad 
> Stelmahovsky
> this Slack client clone created using C++/QML (Desktop app, built for 
> Linux/Windows/macOs)
> https://user-images.githubusercontent.com/11473810/55072233-d58ce380-508a-11e9-9e6a-b6b80fc83dd6.png?raw=true

Thank you for an actual example of a desktop application using QML! Though it 
does look like a bit of a mess and not at all like a useful mouse-oriented 
desktop productivity application.

> From: Interest  On Behalf Of Volker 
> Hilsheimer
> Sent: Thursday, April 22, 2021 4:51 AM
> Widgets can draw into a framebuffer texture that can be used, and that allows 
> for some integration, but that doesn’t give you great performance.

Computers have been blitting onto screens at high refresh rates since Pong. On 
what target device is blitting performance a limitation? If there are target 
devices so low powered that they struggle to blit, how is the situation 
improved by adding an entire Javascript runtime backend? And can you not almost 
entirely solve this problem by rendering widgets directly from textures?

> From: Interest  On Behalf Of Volker 
> Hilsheimer
> Sent: Thursday, April 22, 2021 8:24 AM
> We currently have no specific plans to make QWidget render through RHI, and 
> neither the video nor my earlier emails suggest that this is on the roadmap. 
> It generally makes very little sense to draw with a pen into a freshly wiped 
> out Vulkan surface > 60 times per second.

Why are QWidgets not rendering almost everything directly from texture? Except 
when styles are changed, there should almost never be a need to blit a widget. 
There is nothing intrinsic about widgets (vs. quick controls) that requires 
them to be blitted onto a freshly wiped surface 60 times per second, only 
inertia and a lack of desire to make any improvements to the widget backend in 
over a decade.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

[eric.fedosejevs]

I took another look at the showcase and am still having trouble finding any
substantial desktop application built with QML.

 

Desktops may now be a niche corner of the market, but they are still where
most productivity occurs. Software is still being actively developed and
sold for desktops and there remains a demand for a cross-platform desktop
GUI solution.

 

Can QML be that solution? I am not sure because I cannot find any examples.

 

From: Jérôme Godbout  
Sent: Wednesday, April 21, 2021 9:23 AM
To: eric.fedosej...@gmail.com; interest@qt-project.org
Subject: Re: [Interest] Guide me through the Qt offerings for GUIs

 

You might want to give the showroom a look, some of them are Qml based:

https://showroom.qt.io/

 

Some use the Felgo layer:

https://felgo.com/resources/success-stories

 

http://en.esotericsoftware.com/forum/Facial-Animation-in-Qml-and-pushing-pas
t-the-Spine-limits-3788

http://en.esotericsoftware.com/spine-runtimes#Qt%2FQML

 

 

https://opsensmedical.com/products/optomonitor/

https://www.kdab.com/development-resources/videos-webinars/demo-videos/

 

https://www.learnpyqt.com/examples/

 

Note: this is a personal point of view, strongly opinion ahead from that
point

 

as for the Desktop application, the line is blurring more and more everyday
(iPad and surface pro are good example that “desktop” is no more like it
used to be for most people). The workstation is more for a specific corner
case now a day. I would not limit myself to a few platforms, mobile and
desktop are becoming a mix bag and removing platform is a bad future choice
I think. I never liked the “native” look and feel, I prefer my user to be in
my app feel across platform instead, they don’t get lost when using it on
mobile, Mac OS or Windows… it doesn’t matter. Facebook, messenger, Google
application, Apple application all tends to be this way too. The OS is just
a low level tool/helper in the end, the actual work is made inside your
application, the end user often care very little about the OS, as long as
they can find and launch their app and do their stuff easily.

 

Jérôme Godbout, B. Ing.


Software / Firmware Team Lead
O: (418) 682-3636 ext.: 114  

C: (581) 777-0050 
  godbo...@dimonoff.com

  

  dimonoff.com

1015 Avenue Wilfrid-Pelletier, 

Québec, QC G1W 0C4, 4e étage

 

 

From: Interest mailto:interest-boun...@qt-project.org> > on behalf of
eric.fedosej...@gmail.com 
mailto:eric.fedosej...@gmail.com> >
Date: Wednesday, April 21, 2021 at 8:37 AM
To: interest@qt-project.org 
mailto:interest@qt-project.org> >
Subject: Re: [Interest] Guide me through the Qt offerings for GUIs

Where are the examples of real QML desktop applications on The Qt Co.
website? I did a quick walk through the customer showcase and cannot find
them.

From: Interest mailto:interest-boun...@qt-project.org> > On Behalf Of Giuseppe D'Angelo
via Interest
Sent: Monday, April 19, 2021 8:36 AM

This is false, as a quick walk through the customer showcase on TQC's
website will show.

On 18/04/2021 14:50, Roland Hughes wrote:
> I guess QML is more present in embedded? Or maybe some entreprise 
> stuff we don't know about...
> Just phones and John Deere. 

___
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

Re: [Interest] Guide me through the Qt offerings for GUIs

[eric.fedosejevs]

Where are the examples of real QML desktop applications on The Qt Co. website? 
I did a quick walk through the customer showcase and cannot find them.

From: Interest  On Behalf Of Giuseppe D'Angelo 
via Interest
Sent: Monday, April 19, 2021 8:36 AM

This is false, as a quick walk through the customer showcase on TQC's website 
will show.

On 18/04/2021 14:50, Roland Hughes wrote:
> I guess QML is more present in embedded? Or maybe some entreprise 
> stuff we don't know about...
> Just phones and John Deere. 

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QtQuick over Qt3D (Qt 5.15)

[eric.fedosejevs]

Hi Konstantin,

 

Welcome to the hell that is 3D in Qt.

 

To understand the problems that you are facing, you need to know a little 
history. Other users can perhaps provide additional insight or correct any 
errors, since my recollection and understanding of these matters is probably 
not perfect.

 

Qt3D was introduced in 2016 to much fanfare and was going to be the primary 3D 
solution for Qt. The idea was that Qt3D would provide a high-performance core 
capable of modern 3D graphics. Then, in 2017, Qt Co. had a philosophical shift 
and realized that rather than offering 3D functionality through LGPL/C++ (which 
could also be used by those darned open-source users), they could make more 
money in the short-term by locking in John Deere/others into subscription-based 
commercial licensing to display their little tractor animations. Because of the 
KDE agreement, they could not simply modify the license on Qt3D going forward, 
so they had to start from scratch with a new GPL/QML package: enter QtQuick3D.

 

The result was that Qt3D was mostly abandoned in a half-finished and unpolished 
state and development efforts shifted to QtQuick3D. In doing so, Qt Co. shot 
themselves in the foot in the long-term, of course, since, as you have probably 
noticed, in the absence of a public C++ interface, QtQuick3D is not 
particularly useful for "complex use cases". As a result, "complex users" have 
either stuck with native OpenGL or have bashed their heads on the wall trying 
to adopt Qt3D, and the dream of modern 3D graphics in Qt applications has died.

 

Because some customers had already switched to Qt3D, and moreover because Qt 
Co. needs to maintain the illusion that Qt3D is not dead (KDE agreement 
concerns), every few years, Qt Co. will claim that Qt3D is still alive and will 
be improved (just like widgets!). But the proof is in the pudding: Qt3D is no 
longer included in the Qt6 binary distribution, only in source form. This just 
so happens to be the absolute bare minimum that Qt Co. must do to avoid giving 
KDE the right to release all of Qt under a BSD license.

 

This brings us to your use case. As you have noticed, the Qt3D examples are 
outdated and many are broken. This is by design to discourage use. In Qt6, you 
can’t even use Qt3D unless you build it from source (not sure about the state 
of the Qt3D examples, I’m sticking with Qt5). QtQuick3D (like QtQuick as a 
whole) has no public C++ interface, even though exposing the internal classes 
would be trivial. This is also by design to lock commercial users into QML.

 

So what to do? The answer depends on whether your 3D needs fall into the 
category of "complex use", e.g. more than little tractor animations. If not, 
and if you're okay with GPL/commercial licensing, you're honestly probably 
better off switching to QtQuick3D.

 

Otherwise, you have a few options. If you’re completely committed to Qt3D, but 
not completely committed to QtQuick for your overlay, you may want to use Dear 
ImGUI on top of Qt3D (Lazlo has a mostly working example on top of Qt3D: 
https://github.com/alpqr/imgui-qt3d). You can also use Dear ImGUI directly on 
top of RHI for Qt5.12+ (https://github.com/alpqr/qrhiimgui). I haven’t dug into 
the code, but you may be able to repurpose these samples to instead blit/render 
QtQuick over top of Qt3D/RHI, without the need to create a billboard.

 

I would seriously ask yourself whether you want to be developing a new 
application with Qt3D, however. If you’re doing anything more than displaying a 
model or two, there are various open source 3D graphics engines/frameworks 
under active development with better performance and features that you can 
embed into a Qt widget (I’d suggest Magnum, Ogre, and BGFX, depending on 
desired level of abstraction – all have working ImGUI overlay examples).

 

Cheers,

Eric

 

From: Interest  On Behalf Of Konstantin 
Shegunov
Sent: Monday, March 29, 2021 5:29 AM
To: Interests Qt 
Subject: [Interest] QtQuick over Qt3D (Qt 5.15)

 

Hello,
I want to overlay a QtQuick UI over a Qt3D scene I'm having, however (here 
comes the "but") I want to do it from C++. I don't want to get into 
instantiating Scene3D at all, I want to drive the Quick scene from Qt3D, not 
vice versa (i.e. I don't want to render the 3D content to an FBO, and I don't 
intend to depend on the QML engine to setup the Qt3D parts). Sound(ed) like a 
simple-enough task at first, but I'm having the worst time figuring it out.

To start, I've set the Qt3D things up and I can show my mesh. For the second 
part, I read a lot of the sources around Scene3D, Scene2D and Qt3D examples but 
it doesn't appear this "obvious" thing to do is covered anywhere, 
notwithstanding half the Qt3D examples being broken (either segfaulting or not 
building at all).

I was initially intending to get some ideas from Scene3D, but it appears it 
works directly with the private classes for one, and for two it forces 
synchronous rendering that's 

Re: [Interest] the path forward - that 7 year thing - was, willy-nilly

[eric.fedosejevs]

The FitBit and its many fly-by-night knockoffs are a great example. Its “food 
plan” app will probably soon have privileged access to all of your kitchen 
appliances. And it can even be used to monitor when the supervisor at your 
local nuclear power plant goes on his daily constitutional.

 

From: Roland Hughes  
Sent: Friday, March 26, 2021 9:52 AM

 

Because even something like a FitBit, if it connects to the Internet, can be 
used as part of a swarm for an attack.

 

From: Roland Hughes  
Sent: Friday, March 26, 2021 9:52 AM
To: eric.fedosej...@gmail.com; interest@qt-project.org
Subject: Re: [Interest] the path forward - that 7 year thing - was, willy-nilly

 

 

On 3/26/21 9:23 AM, eric.fedosej...@gmail.com 
  wrote:

There are much worse possible outcomes than spoiled food. “App-controlled” 
smart ovens are now all the rage. Even if there are safety measures to prevent 
remotely burning down your house, what fraction of ovens in a community do you 
need to simultaneously preheat to bring down the entire electrical grid? 
Probably not too many. The grid is designed for small and continuous changes in 
demand, not large and coordinated changes due to an IoT attack. Once the grid 
is down, it can take a long time to bring back up due to a lack of investment 
in black start capacity.

 

https://www.welivesecurity.com/2018/09/06/madiot-home-appliances-power-grids/

 

Qt Co. is in for quite the surprise when new regulations are introduced and 
Agile development/subscription toolkit licensing are driven out of the IoT 
market. But is current management capable of looking that far ahead?

 

Agreed. I just didn't want to go too deep on the "why" said regulation is 
coming. Every country that currently has regulations on medical and SAFETY 
devices will impose regulation on the IoT market and it will be the same 
draconian (by some descriptions) stuff imposed on the human/animal life world. 
Why? Because even something like a FitBit, if it connects to the Internet, can 
be used as part of a swarm for an attack.

Thank God none of the nuclear power plants in America have any connection to 
the Internet. At least the control systems don't.

https://blog.ucsusa.org/edwin-lyman/6-things-to-know-about-the-2020-cyberattack-and-nuclear-power-plants

The electrical grid, however, is not so well protected.

I was in a 20-something floor apartment that weekend day when a Chicago power 
station detonated. Just a few blocks away from where I was at "they" actually 
talked someone into holding a fire hose and continuously spraying that power 
station to keep it from going up.

Power station may be the incorrect term. I didn't look up the proper name. Am 
to this day floored that someone could be talked into spraying water on 
electrical equipment with something like a Terawatt of power going through it.

 

-- 

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

Re: [Interest] the path forward - that 7 year thing - was, willy-nilly

[eric.fedosejevs]

There are much worse possible outcomes than spoiled food. “App-controlled” 
smart ovens are now all the rage. Even if there are safety measures to prevent 
remotely burning down your house, what fraction of ovens in a community do you 
need to simultaneously preheat to bring down the entire electrical grid? 
Probably not too many. The grid is designed for small and continuous changes in 
demand, not large and coordinated changes due to an IoT attack. Once the grid 
is down, it can take a long time to bring back up due to a lack of investment 
in black start capacity.

 

https://www.welivesecurity.com/2018/09/06/madiot-home-appliances-power-grids/

 

Qt Co. is in for quite the surprise when new regulations are introduced and 
Agile development/subscription toolkit licensing are driven out of the IoT 
market. But is current management capable of looking that far ahead?

 

From: Interest  On Behalf Of Roland Hughes
Sent: Friday, March 26, 2021 7:44 AM

 
The Wild Wild West days of IoT are coming to a hard close. It's not just the 
DDOS attacks. With connected refrigerators, hackers can turn the things off 
while people are at work (post pandemic) and spoil the majority of food in a 
city the size of Chicago, New York, LA, etc. If they choose to do it in every 
major city at once it leads to massive food insecurity.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] The willy-nilly deletion of convenience, methods

[eric.fedosejevs]

From: Interest  On Behalf Of Volker Hilsheimer
Sent: Wednesday, March 24, 2021 4:06 AM

>For feedback regarding the licensing changes made that context (including 
>5.15), I’d suggest you go back to the respective email thread if you just want 
>to vent, or call your sales rep in The Qt Company.

Translation: open source users should just shut up and go away. Bold move, 
let's see how it works out for you.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator is so buggy and so slow...

[eric.fedosejevs]

Not sure if it's an option for you guys, but I've been very impressed by the 
rapid pace of improvement of Qt/CMake/Git/Linux x-compilation tools in MSVC 
over the past couple of years. They have all gone from being semi-supported 
add-ons to fully-integrated and functional in the IDE (including even a nested 
QtDesigner window). I've been working on a CMake/QWidget project and have not 
had to open up QtCreator itself in about half a year.

MS has also really improved its support game. I'm just a lowly open-source 
"Community Edition" user and my bug reports have all been reproduced/addressed 
within a day or two.

Best,
Eric

-Original Message-
From: Interest  On Behalf Of Max Paperno
Sent: Tuesday, March 23, 2021 7:42 AM
To: interest@qt-project.org
Subject: Re: [Interest] Qt Creator is so buggy and so slow...


> On 3/18/2021 8:38 PM, Alexander Dyagilev wrote:
>> Hello,
>>
>> Often it just stops to suggest code, syntax highlighted stops working 
>> (at least for a part of the code) for no apparent reason.
>>
>> It takes apporx. 10 seconds to parse c++ file for c++ tools to start 
>> working. If you open/close/open same c++ it can stop parsing it until 
>> app restart.
>>
>> App restart often helps to fix these bugs, but they do return in a 
>> small amount of time...
>>
>> Any suggestions?
>>

I often disable the "new" clang-based parser when I'm working on a project of 
any significant size/complexity.  The extra hinting and some other features it 
provides are nice, but not really worth the expense. 
8 x 3.5GHz cores I guess aren't enough to parse my code in real time.  I can 
edit 4K video in real time on this computer, but not really use the 
clang-parsing in QtC on a "big" project where it would be most useful. 
All my "valuable feedback" on the issue was summarily ignored, and 
unfortunately the old code model is no longer maintained (despite some pleas to 
keep it current), and has some minor issues.  But it's fast and still works 
good enough (last I checked). The clang parser/analyzer can then be run 
manually as needed to catch any possible outlier issues.

I absolutely can't stand having to restart my editors (tools) all the time.  
And this stuff typically happens when I'm right in mid-flow of work.  It's like 
being 25' up on a ladder with a screw gun that only sometimes works...  yea 
that's getting tossed in the rubbish bin.

Cheers,
-Max
___
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] FW: FW: The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

[eric.fedosejevs]

Neat, thanks for the tip. Have you heard of anyone using LVGL for desktop 
development? It looks like it should be pretty easy to throw something together 
using the SDL2-based device simulator as a starting point. Might give it a 
whirl and see how it compares to ImGUI.

From: Jason H  

> I'm not so worried about QML being vendor specific. It should only be a 
> binding language.  

> At my new place, our product is on LVGL, a MIT licensed library. It's 
> C, but there are C++ and Python bindings as well. It is every bit as 
> verbose as you imagine C code would be, :-( but it runs on anything down to 
> PIC/Arduino.

> It's amazing all the competition Qt is _enabling_ rather than capturing... 
> And it's all because of license issues.


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

[eric.fedosejevs]

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  On Behalf Of Roland Hughes
Sent: Monday, March 22, 2021 11:05 AM
To: Jason H 
Cc: interest 
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