[Interest] Squish for open source

[Vadim Peretokin]

Following the news that Qt has acquired the excellent UI-based testing
software Squish (https://www.qt.io/blog/quality-assurance-tools), could
that offering be extended to open source projects by QtC?

There's no real alternatives that I know of that can do UI-based testing
for Qt Widgets projects - or if I haven't looked hard enough, happy to hear
suggestions.

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

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

[Giuseppe D'Angelo via Interest]

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. 


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




QML was a bad idea trying to get around a legacy problem without
actually fixing the legacy problem. The legacy problem is the single
thread-i-ness of Qt. Back when Intel was selling 486 chips with a
manufacturing defect as SX


This is also false. SXs have never been defective CPUs.




All of this is why I'm so excited to read about the Vulkan stuff going
on with the CsPaint library and the Vulkan links I sent you earlier. On
the surface it seems like someone talked to people who write software on
big computers before work started. Need to dig deeper to be really
certain, but you communicate with a "loader" that can support many revs
of the API.


Are you aware that Qt has had Vulkan integration classes since 5.12 (?), 
and Vulkan can be used as a Qt Quick backend in Qt 6?


The ability of painting from multiple threads (or better, to build 
command buffers from multiple threads) doesn't magically solve the 
problem of manipulating data structures safely from multiple threads. 
The single threaded CPU-based _painting_ of the syntax highlighting has 
hardly ever been an issue; its _generation_ has, as it involves 
modifying a shared data structure (while also the user is modifying it) 
without races and without locking against the GUI thread. QTextDocument 
design is unlikely to fit the bill here; a different design sounds 
anything but easy, but the underlying graphics API has very little to do 
with this.


--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

[Bernhard Lindner]

On Mo, 2021-04-19 at 11:01 +0100, Rui Oliveira wrote:
> Well, let's then hope that Mr Volker Hilsheimer's statements hold to a 
> bright future.
> 
> As I said before, I wouldn't even mind to wait for the RHI backend on 
> Widgets if that meant a cleanup up effort of the error log.
> 
> Let's see what the future brings.

How patient do you plan to be? 

I've waited about 10 years now and Qt is going down the drain faster year after 
year (at
least from my point of view). The ratio between steps forward and backward is 
steadily
deteriorating. Only greed grows continuously :(

-- 
Best Regards,
Bernhard Lindner

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

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

[Rui Oliveira]

Well, let's then hope that Mr Volker Hilsheimer's statements hold to a 
bright future.


As I said before, I wouldn't even mind to wait for the RHI backend on 
Widgets if that meant a cleanup up effort of the error log.


Let's see what the future brings.

At this time, I guess I'll stick to Widgets for my particular application.

Thanks!

Em 18/04/2021 22:34, André Pönitz escreveu:

On Thu, Apr 15, 2021 at 11:25:08AM +0100, Rui Oliveira wrote:

I want to write a desktop application. This desktop application would not
involve displaying lists of things, which seems to be what all
tutorials/guides/courses are about, especially on the QML side. This
application would involve some "custom graphics", namely a FFT display,
and a "waterfall" display. You can google for "GQRX" and you'll know what
I want.

And then I looked at Qt, and:

First thing I have looked at were QWidgets. I feel comfortable staying in
the C++ domain. To implement said custom widgets I gave a shot to a class
inheriting from QOpenGLWidget. And honestly, the experience wasn't bad at
all!

But, I feel very hesitant to start a project on QWidgets. It feels like
starting a project on dead tech. Although, I did watch Giuseppe D’Angelo's
talk in Qt Desktop Days 2020 ([1]slides [1]), and looking at slide 19,
there seem to be prospects of evolution. My attention goes especially to
"Accelerate widget rendering & compositing through RHI". Will QWidgets
really have a RHI backend? And a QRhiWidget option? Or maybe just QWidget
and everything HW accelerated? I can dream...

I know QWidgets are no longer "interesting".

Depends whom you ask.

QWidgets are robust. QWidget based applications don't need glue code to talk
to C++. They have overall low maintenance need from a user's point of view.
A Qt 4.2 application from 2006 has good chance to require no or only marginal
changes to run with 2020's Qt 5.15.

Qt Quick/QML on the other hand needs significant glue when talking to C++
backends. Error detection at "compile" time is rarer than in the widget case.
There have been several rounds of major changes to the technology during the
last decade, with impact on user code. The language is not standardized, and
practically unused outside a Qt context (Ok, there's QBS. Anything else?),

I personally would expect more changes to come here, but overally with an
effect to make Qt Quick application development more similar to what widgets
were all the time: Ahead-of-time compilation, better integration with C++, use
of standard compilers, debuggers, profilers, static analyzers, ...


Even KDE moved on from them...

If I only could use sarcasm on this mailing list...


In summary, it would seem that my options for the desktop with Qt are two
self-competing technologies: one "half-dead", one "3/4-baked"... I'd
really love to be wrong.

I understand that this is the natural interpretation of most of the messaging
around Qt Widgets and Quick during the last decade.

I'd like, however, point out that comments like

 From: Volker Hilsheimer :
 "TL;DR: Qt Widgets will be with us for a long time, and we’ll continue to
 maintain them and +make sure that they continue to work and look great on
 future versions of the various operating systems as well. There’ll probably
 always be applications for which the widget concepts are a perfect fit."

have not been common in 201x, but do show up in 2021. Mark Twain comes to mind.


Andre', not speaking for his employer.

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

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

[Rui Oliveira]

Well,

About the automotive industry, the Qt website itself presents some use 
cases:

https://resources.qt.io/customer-stories-automotive

On the old bugs, I've come across this one while writing some code:
https://bugreports.qt.io/browse/QTBUG-6864
P2 importance! And 11 years old...

If the TQtC decided to spend 18 months doing nothing else than cleaning 
up the bugreports backlog, I'd 100% support it!


About threading techniques, I don't have much to say, I think it's one 
of those historical things...


Rui

Em 18/04/2021 13:50, Roland Hughes escreveu:


On 4/18/21 5:00 AM, Rui Oliveira wrote:

If you want to talk about "like" QQC... Do electron apps count? I do use
VSCode a lot. But I guess those are a league of their own.
No, Electron doesn't count. Electron is what replaces Qt in many many 
former Qt environments. There are a lot of text editors and other 
desktop apps written under Electron.


https://atom.io/

Actually quite a few text editors taking either Electron or pure 
JavaScript approach, assuming Wikipedia could be trusted


https://en.wikipedia.org/wiki/Comparison_of_JavaScript-based_source_code_editors 




I've also been monitoring:
https://bugreports.qt.io/browse/QTBUG-78634
https://bugreports.qt.io/browse/QTBUG-74407


Well, client of mine that using a commercial license that tipped the 
scales north of $600K emailed me off-list to rag about this decade old 
bug.


https://bugreports.qt.io/browse/QTBUG-12055

They lost half a staff day on this. Not one person lost half a day, 
the project team. I think they have north of twenty people on the 
project still. You can't have a medical device with random crashes so 
when one turns up, it's all hands on deck.


See this line - 
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/serialization/qtextstream_p.h#n72 
 



=

Issue is that it doesn't properly unregister the signal from QFile 
when you tell it to, so you think it would be done with it but nope, 
signal fires when QFile is closed and now you have a race if you 
continue to use that QFile object.  You can see in the code they 
_thought_ they were, but actually they were removing all connections 
to QTextStream private class signals... Of which there are none.  
Probably works "fine" if you are largely single threaded, but not for 
multiple threads.  As pointed out in that report, a mutex should have 
been ok for synchronization, save for this bug.


=

The fix has been known for a long time. Almost as long as the bug has 
been in the database.



I guess QML is more present in embedded? Or maybe some entreprise stuff
we don't know about...


Just phones and John Deere. I haven't spoken with anyone working on 
Ford projects in a while but last I heard QML was on its way out there 
too.


QML was a bad idea trying to get around a legacy problem without 
actually fixing the legacy problem. The legacy problem is the single 
thread-i-ness of Qt. Back when Intel was selling 486 chips with a 
manufacturing defect as SX


https://en.wikipedia.org/wiki/Intel_80486SX

We didn't have high end graphics. We were lucky to have 33Mhz and 
threading libraries were not robust. Many would only yield the single 
core when an I/O operation happened. That thread calculating Pi to 
2000 decimal places locked up your machine. Keep in mind that an 80 
MEG hard drive was just massive. Corporate desktops still tended to 
have 20 MEG drives and managers who didn't really need it had 40 MEG. 
Most people pull down stupid cat videos larger than that today. You 
need to understand that so you understand just how little I/O was 
really happening. There was nothing you could cobble together in the 
little computer world to store a Terabyte. You couldn't even really 
get to a Gig on a network of shared drives.


Single thread-i-ness design decisions weren't horrible then.

* You can only paint in the main event loop

* Data models used by Widgets have to exist in the main event loop

* Not everything is tested across threads (see above bug)

These short sighted decisions weren't unique to Qt. Poke around in 
Google books for PC Magazine and other programming magazine articles 
of the day and you will find things written about the 1,000 line 
switch statements that were the center of most every Windows program. 
Zinc and every other GUI library had a similar problem. Zinc didn't 
even have a hook in their event loop so you could give time to things 
like serial communications or other devices. You had to roll your own 
event loop to do that.


The world of JavaScript has done a lot of work solving "You can only 
paint in the main event loop".


https://stackoverflow.com/questions/36942555/does-the-electron-framework-allow-multi-threading-through-web-workers 



https://mozillagfx.wordpress.com/2017/12/05/off-main-thread-painting/

I haven't kept up on the whole "worker" thing JavaScript and browsers 
have going