subject:"\[Interest\] Guide me through the Qt offerings for GUIs"



On 4/22/2021 2:06 PM, Rui Oliveira wrote:

In my particular case (and it's not unique to me at all), I have a
series of devices that I'd like to support, which have completely
different and unrelated controls. This might be my "stuck mindset"
talking, but I've seen this problem solved as I explained: "bring your
own controller", and yes, a widgets object and a "logic" object with
pointers to each other.


It's not a stuck mindset it's an x86 mindset.

"Everything needs to be linked into one program."

Fugetaboudit

Everybody should have to take COBOL and CICS when getting there 
programming degree. Much like the Kevin Bacon game, everything in IT 
eventually boils down to a CICS transaction.


User launches CICS application. CICS engine throws screen up on terminal 
while actual application runs in a batch queue. User tippy-tap-types 
away at terminal. Eventually they hit one of the limited function keys 
like  or they hit the funky little enter key. Either a partial 
or full screen of data gets sent as a message on the CICS message queue 
for the batch job. Eventually batch job wakes up, reads message, does 
something with it. Maybe that something sends a different screen or 
additional data back to the terminal, maybe not.


The first thing you need to do is decide what type of message you are 
going to use?


1) Serialized CoA (Common Object Array) most common in embedded world.

2) JSON

3) XML

4) Roll Your Own

After that you need to write yourself, buy, or find a publish subscribe 
message queue. You also need to decide if the queue depth for each 
message type will be one or N. It may sound horrible, but a depth of one 
is very common.


This message queue runs as its own little daemon/process on the system.

As each piece of your application comes up it looks for this message 
queue via some known name or other method. They connect to it and 
subscribe to the messages they want to receive. Most will make you 
announce the messages you intend to broadcast.


Each device runs as its own process/daemon. Your UI runs as its own 
process/daemon. It also connects to the message queue. There is no 
business logic in the UI. There is none of the "glue" layer stuff others 
have been chatting about. If it needs data in certain columns and sorted 
order it sends a CoA message asking a service for it. *If* a service is 
subscribed it will assemble the data as requested and publish a 
different CoA message.


You **always** publish without wait. Absolutely nothing waits for a 
response. Maybe something has already subscribed to your message, maybe 
it hasn't. You issue the request and cease to care at that point. If you 
are working in a SAFETY environment you publish the message and launch a 
timer that will trigger some kind of error log/indicator if a response 
is not marked as received within a certain window. You **never** 
actually wait for the response.


Devices come, devices go. When a device connects it needs to publish 
"Hey I'm Here!" It may connect and publish before the UI is alive. When 
the UI connects the first message it publishes is "Sound Off!" telling 
all of the subscribing devices to say "Hey I'm here!"


Nobody cares if anybody actually listens.

This back of the matchbook architecture works for large scale business 
systems spread across multiple business class operating systems and 
architectures all the way down to tiny medical devices.


No matter how much people hate green screens, we will never get away 
from CICS. When you try to get away from it you create tragedy.


If it helps, think about it this way:

A happy successful robust application has a whole lot of processes that 
simply don't care. Like a musician playing a song in a room all by 
themselves, they don't need an audience. If they have an audience, 
great! If not they are still going to play.





--
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com

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

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


Olá João!

Doing logic with QML? hehe I can hear the voice of Jesper Pedersen from 
KDAB saying "your business logic stays in C++" 
(https://www.youtube.com/watch?v=JxyTkXLbcV4 pretty good series, actually).


I'm just kidding, Qt itself has examples in Qt Creator making a game 
without any C++ logic 
(https://doc.qt.io/qt-5.12/qtquick-tutorials-samegame-samegame1-example.html 
and parts 2 and 3).


Thanks for your insights! I see that those who use QML love it, it seems 
to be a consistent feeling.


I'll keep that in mind. Now I guess I need to learn software 
architecture that covers both what I want to do and good practices with 
GUI work.


Thanks,
Rui

Em 22/04/2021 20:33, joao morgado via Interest escreveu:

Olá Rui

Just to share my experience with Qt widgets and QML. I had a simple 
desktop calculator app with Widgets and OpenGL graphics.
I had a c++ mindset and was ok doing that. When QML come around it was 
a bit strange and I had to leave my confort zone.
Eventually QML syntax become so pleasent to me and I found myself 
really enjoyng developing with qml / javascript.
I ported my app to QML based on the OpenGL under QMLexample. I started 
porting in the QML early days so I had to do a lot of "widgets" in qml 
from scratch wich was a bit of work. My app looks a lot better in QML 
and works for android and iOS with consistent look  and feel in all 
plataforms.

Also I find the qml development much faster than c++.

I also developed a game in qml. It has almost no relevant UI, but I 
had a very pleasent experience using javascript and qml features for 
the game logic (hello qml bindins, hello qml timer sintax). I never 
had performance problems, as some people say that javascript is slower 
than c++, but at the end of the day I think it also has a lot to do 
with your code algorithm and the type of app your developing. Btw I 
never had developed with javascript before, but if you are a c++ 
developer you will have no problems at all.


If I had to start a new app today for desktop I would go for QML. Your 
app is for desktop today, but you never know when your users will 
start asking for a mobile or tablet version.


Cheers
João


Em quinta-feira, 22 de abril de 2021 19:41:06 GMT+1, Konstantin 
Shegunov  escreveu:



On Thu, Apr 22, 2021 at 7:19 PM Giuseppe D'Angelo via Interest 
mailto:interest@qt-project.org>> wrote:


You should create a C++ layer (call it a "presentation" layer)
that sits
between your (possibly non-Qt) business logic and the UI. That layer
contains stuff like item models, QObjects that expose the relevant
business logic APIs, type wrappers, and so on.


Registering a struct/data class with the meta type system and/or 
marshaling it over QVariant, just so it can be visible in QML isn't 
that. Or things as natural (with C++) as having the UI raise some 
encapsulated piece of data in a signal (say some struct, say QColor or 
QVector3D) which the backend responds to isn't it either. As a matter 
of fact, how do you tie your existing backend to QML? Say we have this 
nice encapsulated UI that's completely decoupled from the business 
logic, how do I tie a specific object from the Quick scene and connect 
the notifications back to C++? I can't do it from the business logic 
(i.e. controller side), I have to expose the backend to the QML engine 
and do it from there, am I wrong? Basically you say it's fine that the 
UI drives the controller (incl. object creation)?


We can agree on the principles, gladly, but this is really a gross 
oversimplification of the problem.


While building this layering may be super tedious (YMMV), in the long
run, it makes your application more robust, not less. The fact
that QML
_forces_ you to have this stuff becomes somehow a good thing.


Forces you? Do you mean, perhaps, that JS is somehow not supported, or 
maybe that Component.createObject is somehow hidden and/or inaccessible?


On widgets, well, raise your hand if you didn't at least once
connect a
QPushButton to a slot declared in the widget that contains the
button,
and perform some business logic from there (yay business logic in
the UI!).


Yes, it is done, and not without an honorable mention of the 
documentation, where the view-controller idiom is used extensively.  
But then, raise your hand if you at least once didn't use an `if` (or 
some other JS piece of code) in a QML file. I can pull out for you 
numerous cases of it being done, probably too numerous to count even 
in the examples. Shooting yourself in the foot is not restricted to 
one language or another, nor to the technological solution in use is 
my point. You can make a holy mess of any piece of code on any 
language you choose, and QML certainly doesn't force you to do 
anything you don't *really want to*.



In other words, being "entirely" in C++ has also its downsides.


Most certainly. One of the major downsides is it being much more 
complex and

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

2021-04-22 Thread joao morgado via Interest

 Olá Rui
Just to share my experience with Qt widgets and QML. I had a simple desktop 
calculator app with Widgets and OpenGL graphics. I had a c++ mindset and was ok 
doing that. When QML come around it was a bit strange and I had to leave my 
confort zone. Eventually QML syntax become so pleasent to me and I found myself 
really enjoyng developing with qml / javascript. I ported my app to QML based 
on the OpenGL under QMLexample. I started porting in the QML early days so I 
had to do a lot of "widgets" in qml from scratch wich was a bit of work. My app 
looks a lot better in QML and works for android and iOS with consistent look  
and feel in all plataforms.Also I find the qml development much faster than c++.
I also developed a game in qml. It has almost no relevant UI, but I had a very 
pleasent experience using javascript and qml features for the game logic (hello 
qml bindins, hello qml timer sintax). I never had performance problems, as some 
people say that javascript is slower than c++, but at the end of the day I 
think it also has a lot to do with your code algorithm and the type of app your 
developing. Btw I never had developed with javascript before, but if you are a 
c++ developer you will have no problems at all. 
If I had to start a new app today for desktop I would go for QML. Your app is 
for desktop today, but you never know when your users will start asking for a 
mobile or tablet version. 
CheersJoão

Em quinta-feira, 22 de abril de 2021 19:41:06 GMT+1, Konstantin Shegunov 
 escreveu:  
 
 On Thu, Apr 22, 2021 at 7:19 PM Giuseppe D'Angelo via Interest 
 wrote:

You should create a C++ layer (call it a "presentation" layer) that sits 
between your (possibly non-Qt) business logic and the UI. That layer 
contains stuff like item models, QObjects that expose the relevant 
business logic APIs, type wrappers, and so on.


Registering a struct/data class with the meta type system and/or marshaling it 
over QVariant, just so it can be visible in QML isn't that. Or things as 
natural (with C++) as having the UI raise some encapsulated piece of data in a 
signal (say some struct, say QColor or QVector3D) which the backend responds to 
isn't it either. As a matter of fact, how do you tie your existing backend to 
QML? Say we have this nice encapsulated UI that's completely decoupled from the 
business logic, how do I tie a specific object from the Quick scene and connect 
the notifications back to C++? I can't do it from the business logic (i.e. 
controller side), I have to expose the backend to the QML engine and do it from 
there, am I wrong? Basically you say it's fine that the UI drives the 
controller (incl. object creation)?

We can agree on the principles, gladly, but this is really a gross 
oversimplification of the problem.


While building this layering may be super tedious (YMMV), in the long 
run, it makes your application more robust, not less. The fact that QML 
_forces_ you to have this stuff becomes somehow a good thing.


Forces you? Do you mean, perhaps, that JS is somehow not supported, or maybe 
that Component.createObject is somehow hidden and/or inaccessible?


On widgets, well, raise your hand if you didn't at least once connect a 
QPushButton to a slot declared in the widget that contains the button, 
and perform some business logic from there (yay business logic in the UI!).


Yes, it is done, and not without an honorable mention of the documentation, 
where the view-controller idiom is used extensively.  But then, raise your hand 
if you at least once didn't use an `if` (or some other JS piece of code) in a 
QML file. I can pull out for you numerous cases of it being done, probably too 
numerous to count even in the examples. Shooting yourself in the foot is not 
restricted to one language or another, nor to the technological solution in use 
is my point. You can make a holy mess of any piece of code on any language you 
choose, and QML certainly doesn't force you to do anything you don't *really 
want to*.


In other words, being "entirely" in C++ has also its downsides.


Most certainly. One of the major downsides is it being much more complex and 
unforgiving, which doesn't necessarily mean it's 
better.___
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


I agree absolutely with these observations, in principle.

But this seems to be "easy" when we're talking about an application 
displaying data, with a fixed set of controls. Flashback to all the QML 
tutorials using model/view + delegates.


In my particular case (and it's not unique to me at all), I have a 
series of devices that I'd like to support, which have completely 
different and unrelated controls. This might be my "stuck mindset" 
talking, but I've seen this problem solved as I explained: "bring your 
own controller", and yes, a widgets object and a "logic" object with 
pointers to each other. I've "stolen" this idea from projects I've 
seen.  Add wish to have a plugin system, forcing an even more dynamic 
system, and I don't know how to solve the problem without this 
architecture.


And this is the only way I can think of doing it. I would really like to 
know other way, so if anybody has pointers, I'd be glad to hear them.


And if I need to chain parameters on my hardware, how do I do it without 
calling a method on the hardware object from a signal connected to a 
slider? Again, keeping it isolated from the rest of the system, because 
I don't know, not even at compile time, the controls needed. It's not 
like I can just do it with a "Flux" architecture.


Maybe I'm absolutely terrible at software design. I'm not a software 
engineer.


Rui

Em 22/04/2021 17:17, Giuseppe D'Angelo via Interest escreveu:

On 22/04/2021 17:06, Rui Oliveira wrote:
Q_INVOKABLE, Q_PROPERTY, etc... The Qt stuff crawls into what would 
otherwise be just business logic because you need to access something.


I've linked this before: 
https://stackoverflow.com/questions/66618613/qml-c-classes-with-bring-your-own-component


Which again, is absolutely trivial do to with C++ and polymorphism. 
And a pointer/reference instead of adding macros in 20 places  and 
the Q_PROPERTY lines...


Basically we're coupling the whole backend to the GUI framework.



Wait, this sounds precisely what you shouldn't do.

You should create a C++ layer (call it a "presentation" layer) that 
sits between your (possibly non-Qt) business logic and the UI. That 
layer contains stuff like item models, QObjects that expose the 
relevant business logic APIs, type wrappers, and so on.


(Possibly even more layers. Like an cake. Or an ogre)

This way

* the business logic is agnostic of the UI framework used above (could 
be Widgets, could be Qt Quick, could be HTML)


* you can do UI testing by swapping out the business logic with a 
testing one


* you can test the business logic without the UI

and so on.


While building this layering may be super tedious (YMMV), in the long 
run, it makes your application more robust, not less. The fact that 
QML _forces_ you to have this stuff becomes somehow a good thing.



On widgets, well, raise your hand if you didn't at least once connect 
a QPushButton to a slot declared in the widget that contains the 
button, and perform some business logic from there (yay business logic 
in the UI!).


And/or thought "ok, I should add a controller for the UI layer that 
talks to these other 5 objects, and does this and that, and gets 
triggered by the button... or I could just #include 
"Component_Deep_Into_Business_Logic.h" and just call a method on it.". 
You know, "a little goto never hurt anyone". (Velociraptor ensues)



In other words, being "entirely" in C++ has also its downsides.

HTH,

___
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

On Thu, Apr 22, 2021 at 7:19 PM Giuseppe D'Angelo via Interest <
interest@qt-project.org> wrote:

> You should create a C++ layer (call it a "presentation" layer) that sits
> between your (possibly non-Qt) business logic and the UI. That layer
> contains stuff like item models, QObjects that expose the relevant
> business logic APIs, type wrappers, and so on.
>

Registering a struct/data class with the meta type system and/or marshaling
it over QVariant, just so it can be visible in QML isn't that. Or things as
natural (with C++) as having the UI raise some encapsulated piece of data
in a signal (say some struct, say QColor or QVector3D) which the backend
responds to isn't it either. As a matter of fact, how do you tie your
existing backend to QML? Say we have this nice encapsulated UI that's
completely decoupled from the business logic, how do I tie a specific
object from the Quick scene and connect the notifications back to C++? I
can't do it from the business logic (i.e. controller side), I have to
expose the backend to the QML engine and do it from there, am I wrong?
Basically you say it's fine that the UI drives the controller (incl. object
creation)?

We can agree on the principles, gladly, but this is really a gross
oversimplification of the problem.

While building this layering may be super tedious (YMMV), in the long
> run, it makes your application more robust, not less. The fact that QML
> _forces_ you to have this stuff becomes somehow a good thing.
>

Forces you? Do you mean, perhaps, that JS is somehow not supported, or
maybe that Component.createObject is somehow hidden and/or inaccessible?

On widgets, well, raise your hand if you didn't at least once connect a
> QPushButton to a slot declared in the widget that contains the button,
> and perform some business logic from there (yay business logic in the UI!).
>

Yes, it is done, and not without an honorable mention of the documentation,
where the view-controller idiom is used extensively.  But then, raise your
hand if you at least once didn't use an `if` (or some other JS piece of
code) in a QML file. I can pull out for you numerous cases of it being
done, probably too numerous to count even in the examples. Shooting
yourself in the foot is not restricted to one language or another, nor to
the technological solution in use is my point. You can make a holy mess of
any piece of code on any language you choose, and QML certainly doesn't
force you to do anything you don't *really want to*.

In other words, being "entirely" in C++ has also its downsides.
>

Most certainly. One of the major downsides is it being much more complex
and unforgiving, which doesn't necessarily mean it's better.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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



On 4/22/21 8:15 AM, eric.fedosej...@gmail.com wrote:

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.


Just a point of interest.

That work of art UI I posted a link to earlier had no GPU. This is 
common in the embedded world when people are pushing for days (not 
minutes) of battery life. We pre-loaded all our images, did our own 
caching, and blitted everything.


When this conversation talks about QML performance in the embedded world 
it is talking about that subset of the embedded world which splurges for 
GPU.


--
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] Guide me through the Qt offerings for GUIs


On 22/04/2021 17:06, Rui Oliveira wrote:
Q_INVOKABLE, Q_PROPERTY, etc... The Qt stuff crawls into what would 
otherwise be just business logic because you need to access something.


I've linked this before: 
https://stackoverflow.com/questions/66618613/qml-c-classes-with-bring-your-own-component


Which again, is absolutely trivial do to with C++ and polymorphism. And 
a pointer/reference instead of adding macros in 20 places  and the 
Q_PROPERTY lines...


Basically we're coupling the whole backend to the GUI framework.



Wait, this sounds precisely what you shouldn't do.

You should create a C++ layer (call it a "presentation" layer) that sits 
between your (possibly non-Qt) business logic and the UI. That layer 
contains stuff like item models, QObjects that expose the relevant 
business logic APIs, type wrappers, and so on.


(Possibly even more layers. Like an cake. Or an ogre)

This way

* the business logic is agnostic of the UI framework used above (could 
be Widgets, could be Qt Quick, could be HTML)


* you can do UI testing by swapping out the business logic with a 
testing one


* you can test the business logic without the UI

and so on.


While building this layering may be super tedious (YMMV), in the long 
run, it makes your application more robust, not less. The fact that QML 
_forces_ you to have this stuff becomes somehow a good thing.



On widgets, well, raise your hand if you didn't at least once connect a 
QPushButton to a slot declared in the widget that contains the button, 
and perform some business logic from there (yay business logic in the UI!).


And/or thought "ok, I should add a controller for the UI layer that 
talks to these other 5 objects, and does this and that, and gets 
triggered by the button... or I could just #include 
"Component_Deep_Into_Business_Logic.h" and just call a method on it.". 
You know, "a little goto never hurt anyone". (Velociraptor ensues)



In other words, being "entirely" in C++ has also its downsides.

HTH,
--
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


On 22/04/2021 15:57, Jérôme Godbout wrote:
I wonder if it would be possible to totally declare the QtQuick scene 
from C++ without any Qml files actually, with Qt6 you got C++ binding 
and the Qml is compiled to C++ anyway. Maybe I miss something but it 
could be possible to actually only write C++ to create the actual scene?!




"Could" it be possible? Certainly yes, but Qt Quick never wanted to 
provide a public C++ API, only a public QML one. (Why? No idea, wasn't 
there in the room when it was decided; likely, having the freedom of 
rearrange the C++ implementation, which clashes against the strong 
API/ABI promise of Qt. Only the QML API is stable.)


AFAICR, QSkinny is an example of creating Qt Quick scenes from C++.

Of course, scene creation is just one of the aspects, you'd also then 
really want to reimplement C++ the other goodies you get in QML (e.g. 
bindings, Behavior, etc.), some of which are now coming in Qt 6.x.


HTH,
--
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

2021-04-22 Thread Eric Fedosejevs

I do not disbelieve you, but I live in the world of trust but verify. I
have an aging widgets application and I am trying to decide what to replace
widgets with as they undergo their slow ignoble LTS-free death.

I have been searching for years for an example of a substantial QML based
desktop productivity application without success. I want to know that it is
both possible and straightforward to build such an application before I
devote my time to it. I don't particular like having to use a scripting
language, but I can stomach it if it works well. However, the lack of
examples leads me to conclude that even if it is possible, it must be a
royal pain.

So, I'm now testing out Copperspice and leaning in that direction instead.

On Thu, Apr 22, 2021, 10:11 AM Vlad Stelmahovsky 
wrote:

> We have such applications in house but I can't share it due to NDA
> And why? QML is highly customizable, so I don't see any points why its not
> possible to create robust QML apps for desktop
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

On Thu, Apr 22, 2021 at 6:10 PM Rui Oliveira  wrote:

> Basically we're coupling the whole backend to the GUI framework.
>
You always have some coupling between the logic and the GUI, no matter what
you use, but I do get the gist.

> I'd prefer to write C++ than to learn Loaders and whatever else there
> is... But seems that people do love QML a lot (again, shouts out to KDE).
>
Funny that you mentione the `Loader`, which is sort of no-op item from the
C++/desktop dev perspective. What I mean by that is that the `Loader` is
the archetype of the 'QML engine is really a glorified object factory',
which I mentioned. The only reason it is there is to delay the creation of
a QtQuick item. This would've been rather trivial to do in a C++
environment, you just create and add the object to the scene whenever it's
needed, no need to wrap this in a `QObject`, but not so trivial to do if
you want to leverage it in a 'declarative' (or rather JS) context. Note
that the component doesn't go away too, because at some point you may want
to unload said scene item, which instead of just deleting, being the
obvious choice, you set the relevant property to the loader, which detaches
it from the scene.

> Opinions, I guess.
>
I don't see anything wrong with that, as long as we have a civil discussion
(not a troll fest) about it.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

2021-04-22 Thread André Pönitz

On Wed, Apr 21, 2021 at 05:42:50PM +0200, Jason H wrote:
>You probably won't  -- it's too new. Unless you call automotive
>Infotainment consoles success stories.
>The lack of proper QtQuick Controls (v2) held it back for a while.
> 
>Personally, I think the exsting QtQuick element should be scrapped and
>just focus on QML versions of the existing Widget functionality. I love
>the QML syntax, hate that it's not just a layer on top of widgets.
>That said, I still really like both.

If it is *just* the appearance and you don't insist on matching QML syntax
exactly you can throw a few hundred lines of syntactic sugar on top of
QWidgets and make something like 

CommonOptionsPageWidget() 
{
Settings  = ...;
using namespace Layouting;

Column col1 {
s.useAlternatingRowColors,
s.useAnnotationsInMainEditor,
s.useToolTipsInMainEditor,
s.closeSourceBuffersOnExit,
s.closeMemoryBuffersOnExit,
s.raiseOnInterrupt,
s.breakpointsFullPathByDefault,
s.warnOnReleaseBuilds,
Row { s.maximalStackDepth, Stretch() }
};

Column col2 {
s.fontSizeFollowsEditor,
s.switchModeOnExit,
s.showQmlObjectTree,
s.stationaryEditorWhileStepping,
s.forceLoggingToConsole,
s.registerForPostMortem,
Stretch()
};

Column {
Group {
Title("Behavior"),
Row { col1, col2, Stretch() }
},
s.sourcePathMap,
Stretch()
}.attachTo(this);
}

compile in plain C++, without any background engine interpreting this at
runtime or similar.

Modulo some namespacing hassle it would also be possible to use something like

PushButton {
text = "Press me!",
onPressed = [] {
qDebug() << "Ouch";
},
...
};

if you really wanted.

On the other hand, there's also a point where things get too fancy
syntax-wise.

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

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

2021-04-22 Thread Jason H



> Sent: Thursday, April 22, 2021 at 4:50 AM
> From: "Volker Hilsheimer" 
> To: "Bernhard Lindner" 
> Cc: "interest@qt-project.org" 
> Subject: Re: [Interest] Guide me through the Qt offerings for GUIs
>
> > On 21 Apr 2021, at 22:39, Bernhard Lindner  
> > wrote:
> > 
> > 
> >> Personally, I think the exsting QtQuick element should be scrapped and 
> >> just focus on QML
> >> versions of the existing Widget functionality. I love the QML syntax, hate 
> >> that it's not
> >> just a layer on top of widgets.
> > 
> > +100
> > 
> > Why this wasn't done from the start is one of the hardest puzzles! I ask 
> > myself this
> > question every time I read the three letters "QML" :-) 
> 
> 
> Indeed, it’s an obvious knee-jerk reaction to have when looking at Qt and 
> wondering why there are several UI frameworks.
> 
> But there are several reasons why things are as they are. Some of them:
> 
> * imperative painting
> 
> Paint-event based drawing with a “pen” is not easily reconcilable with how 
> GPUs like to work. Without a persistent scene graph that is uploaded to the 
> GPU, much of the performance you get from a GPU is lost. An animation at 
> 60fps is ideally just a draw call on the GPU with some different 
> transformations, not a completely new upload of a completely reconstructed 
> scene graph for each frame.
> 
> 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.
> 
> 
> * integer coordinates and clipping
> 
> Widgets work with integer coordinates, which starts to be problematic now 
> that we have high-DPI displays. And widgets clip are clipped to their parent 
> geometry, which was the right choice for those UIs, but is very limiting and 
> requires a lot of complex code to solve conceptually simple problems. Hello 
> macOS focus ring.
> Quick items do not clip and are not clipped, which gives a lot more freedom 
> in how shapes are combined and structured.
> 

The painting problem I understand, and as I understand it, the biggest reason 
for the break?. It's different world. But Integer coordinates don't seem like 
such a big deal.

> * declarative vs imperative APIs
> 
> Many widget classes don’t have a declarative-friendly API. Plenty of widget 
> properties have side effects on other properties, so the order in which 
> properties are set matters. That doesn’t work well in a declarative world.
> 

I don't buy this. You can do declarative to imperative mapping. Isn't this what 
the QtQuick compiler does?

> * weight
> 
> Widgets are heavy, often very complex objects. They often come with all bells 
> and whistles. QPushButton always has the data structure to support 
> QPushButton::setMenu, even if probably <1% of buttons out there ever use that 
> feature. That’s ok on desktop machines, it’s not ok on embedded systems.
 

I have a hard time buying this one as well because you've added GL, which 
requires additional hardware. Sure emulate it in software if you dare, but it's 
worse than painting.

> * complexity and hard to customize
>   
> Inheritance and reimplementing are nice concepts on paper and works great if 
> you build your own custom widget from a reasonably abstract base class. But 
> if you have ever tried to subclass e.g. QTreeWidget to modify how certain 
> interactions work, then you know how hard it can be to not break the complex 
> states that the default implementations rely on.

The "inheritance" in QML is outstanding. Super simple and effective.
 
> 
> So, making widgets work in a declarative, GPU friendly world where ease of 
> customisation is more important than standard look’n'feel would have required 
> many changes to widgets. Those would have been impossible to make without 
> invalidating or breaking a lot of code out there, and still not given us the 
> UI components we would have needed.
> 
> I’m sure there are opportunities to share more code between widgets and quick 
> world esp on the UI framework classes, and with Qt 6 we have taken some steps 
> into that direction. But whether the benefits outweigh the risks and effort 
> requires a case-by-case evaluation.

I think that's a false choice. 

Anyway, I hate using QML for any kind of text input because it's so crunchy 
even today. Why do I have to set `selectByMouse: true`? 

I don't understand why the layout system, one of the best, most awesome things 
about old Qt, what make me fall in love with Qt (aside from the clean API), was 
abandoned. I don't see why traditional layouts had to be yeeted even if the 
widgets had to be replaced. The painting issue I get. Sur

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


"Anything that's non-trivial ends up with (a) huge boilerplate wrapper(s)."

Q_INVOKABLE, Q_PROPERTY, etc... The Qt stuff crawls into what would 
otherwise be just business logic because you need to access something.


I've linked this before: 
https://stackoverflow.com/questions/66618613/qml-c-classes-with-bring-your-own-component


Which again, is absolutely trivial do to with C++ and polymorphism. And 
a pointer/reference instead of adding macros in 20 places  and the 
Q_PROPERTY lines...


Basically we're coupling the whole backend to the GUI framework.

I'd prefer to write C++ than to learn Loaders and whatever else there 
is... But seems that people do love QML a lot (again, shouts out to KDE).


Opinions, I guess.

Rui

Em 22/04/2021 15:37, Konstantin Shegunov escreveu:
On Thu, Apr 22, 2021 at 4:59 PM Jérôme Godbout > wrote:


I wonder if it would be possible to totally declare the QtQuick
scene from C++ without any Qml files actually, with Qt6 you got
C++ binding and the Qml is compiled to C++ anyway. Maybe I miss
something but it could be possible to actually only write C++ to
create the actual scene?!


It will have been (even in Qt5) if the classes were public. In the end 
the QML engine is really a glorified object factory. There are other 
problems with that though, one such example is the tree control: 
GPL/Commercial for QtQuick, while with widgets you get that directly 
with the same license as the whole library (there are other such cases 
too, if I'm not mistaken) ... and the mentioned already "native" 
look'n'feel.


I would not actually do this myself but it might attract some user
that are scare of declarative


Many of us avoid it not because we are 'scared' as such, but because 
of other more practically-relevant reasons.


I stop using QWidgets a few years ago and I don’t miss it a bit,
haven’t seen anything I could not achieved into Qml yet, some are
a bit trickier than they should but in the end prototyping and
modifying the GUI is so quick, I often make the change live when
I’m working with my graphic designer and KDAB GammaRay (just need
to apply those change after).


Well, I can build a nuclear power plant at home - probably I can 
achieve it, but the fact of the matter is, should I? There are a 
couple of considerations here. Firstly a lot of code is already 
written with the widgets and even with best practices it's generally 
not trivial to do a 'face-lift'. Secondly, QML fails to sell its point 
to desktop devs due to its C++ integration being a great PITA already. 
Anything that's non-trivial ends up with (a) huge boilerplate 
wrapper(s). And while graphics performance does matter, it's not 
typically the driving force on desktop, where usually we value 
convenience over performance (on desktop you rarely are pressed for 
resources). In fairness, exposing the property bindings natively to 
C++ is a step, no doubt about it.


___
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

On Thu, Apr 22, 2021 at 11:56 AM Volker Hilsheimer 
wrote:

> * declarative vs imperative APIs
>
> Many widget classes don’t have a declarative-friendly API. Plenty of
> widget properties have side effects on other properties, so the order in
> which properties are set matters. That doesn’t work well in a declarative
> world.
>

This is hard to agree to. The widget designer outputs XML, which is as
declarative as you can get. While QML's syntax is nicer you have the same
argument going for it (e.g. the dreaded circular bindings).

> * weight
>
> Widgets are heavy, often very complex objects. They often come with all
> bells and whistles. QPushButton always has the data structure to support
> QPushButton::setMenu, even if probably <1% of buttons out there ever use
> that feature. That’s ok on desktop machines, it’s not ok on embedded
> systems.
>

Eh! I agree for the imperative painting and not being able to batch and
render efficiently, but you really think that a QWidget window has more
objects than a QtQuick scene? I will be hard pressed to believe that.
Moreover with the widgets you don't need everything to be QObject (or in
some cases Q_GADGET), or wrap everything in QVariant, or introduce global
factories like `Qt.vector3d` just due to the fact that you're working on a
lower level and you don't have to battle with the JS engine. I will concede
that the widgets were conceived in another age so they have a lot of
shortcomings, but 'heavy, often very complex objects' doesn't seem to be
it, especially if you're drawing a parallel to QtQuick. Anyone can go and
see the internal implementations of the QtQuick items if he/she doesn't
believe this.

* complexity and hard to customize
>
> Inheritance and reimplementing are nice concepts on paper and works great
> if you build your own custom widget from a reasonably abstract base class.
> But if you have ever tried to subclass e.g. QTreeWidget to modify how
> certain interactions work, then you know how hard it can be to not break
> the complex states that the default implementations rely on.
>

Yes, somewhat true. But this does go to the time the widgets API was
designed. It could as well have been using more aggregation and more
flexibility then (not placing blame). For example it could've been possible
to designed the tree widget to accept delegates that are not directly
painting, but rather are issuing jobs for the (hypothetical) painting
engine. And there could've been an effort to aggregate complex controls
instead of deriving (QComboBox comes to mind) where customizing elements
could've been done through delegates, but it is what it is.

So, making widgets work in a declarative, GPU friendly world where ease of
> customisation is more important than standard look’n'feel would have
> required many changes to widgets. Those would have been impossible to make
> without invalidating or breaking a lot of code out there, and still not
> given us the UI components we would have needed.
>

You should mentioned that by 'declarative' you mean the way you want to
render in batches/jobs (nothing wrong with this, btw.). The widgets (the
forms specifically) are declarative enough, the problem is that when you
start painting them you end up constantly setting and resetting the
painting state.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

On Thu, Apr 22, 2021 at 4:59 PM Jérôme Godbout  wrote:

> I wonder if it would be possible to totally declare the QtQuick scene from
> C++ without any Qml files actually, with Qt6 you got C++ binding and the
> Qml is compiled to C++ anyway. Maybe I miss something but it could be
> possible to actually only write C++ to create the actual scene?!
>

It will have been (even in Qt5) if the classes were public. In the end the
QML engine is really a glorified object factory. There are other problems
with that though, one such example is the tree control: GPL/Commercial for
QtQuick, while with widgets you get that directly with the same license as
the whole library (there are other such cases too, if I'm not mistaken) ...
and the mentioned already "native" look'n'feel.

I would not actually do this myself but it might attract some user that are
> scare of declarative
>

Many of us avoid it not because we are 'scared' as such, but because of
other more practically-relevant reasons.

> I stop using QWidgets a few years ago and I don’t miss it a bit, haven’t
> seen anything I could not achieved into Qml yet, some are a bit trickier
> than they should but in the end prototyping and modifying the GUI is so
> quick, I often make the change live when I’m working with my graphic
> designer and KDAB GammaRay (just need to apply those change after).
>

Well, I can build a nuclear power plant at home - probably I can achieve
it, but the fact of the matter is, should I? There are a couple of
considerations here. Firstly a lot of code is already written with the
widgets and even with best practices it's generally not trivial to do a
'face-lift'. Secondly, QML fails to sell its point to desktop devs due to
its C++ integration being a great PITA already. Anything that's non-trivial
ends up with (a) huge boilerplate wrapper(s). And while graphics
performance does matter, it's not typically the driving force on desktop,
where usually we value convenience over performance (on desktop you rarely
are pressed for resources). In fairness, exposing the property bindings
natively to C++ is a step, no doubt about it.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

I totally forgot about those! I follow them and voted them on JIRA. 
Also, I'm literally the last comment in there asking for an ETA.


"Reporter: Lars Knoll"

Well, seems that someone must have missed the memo! (just kidding!)

Rui

Em 22/04/2021 14:17, Giuseppe D'Angelo via Interest escreveu:

On 22/04/2021 14:55, Rui Oliveira wrote:

I know Giuseppe D’Angelo isn't a TQtC employee, but I trust KDABs stuff
in general.

https://www.qtdesktopdays.com/wp-content/uploads/2020/09/keynote.pdf

Slide 19 "Accelerate widget rendering & compositing through RHI", or I
didn't understand something?


In fact, see https://bugreports.qt.io/browse/QTBUG-74407 and related 
tasks.


HTH,

___
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

2021-04-22 Thread Shawn Rutledge

> On 2021 Apr 22, at 10:47, Rui Oliveira  wrote:
> What doesn't make sense, to me at least, is how QQC*1* seemed to have had a 
> better feature set for the desktop than QQC*2*.

The focus was on high-performance embedded use cases at first.  Now we are 
working again on making QQC2 better for desktop applications.  

> QML/Quick, for me, seems to need a lot of work for the desktop. Also, it 
> seems it's make for "flat", low density UIs. Yesterday I was presented with 
> this: https://ossia.io/ . Look how good it looks 
> (https://ossia.io/assets/score.png)! Holy damn, an that's widgets. And that's 
> a proper desktop productivity application. I mean, if we look at like NeoChat 
> (https://matrix.org/docs/projects/client/neo-chat/), which is made with KDE 
> Kirigami (a Qt Quick framework extension), or the Telegram desktop 
> application, they look all nice and all, but they lack the density.

That example looks like it has a lot of custom graphics.  For some, you could 
use QQuickPaintedItem (as long as the repaint rate is not too high); for some, 
it would make sense to break it down into static image assets, and use 
BorderImage to make them stretch.  Ultimately when you want complex and fluid 
graphics on the GPU, you need to educate yourself about the modern techniques 
(writing shaders and all the data that feeds into them).  It’s such a learning 
curve that many of us still don’t know the best way to build everything we 
want; I’ve done some of that work, and I want to learn to do more, because it’s 
exciting to leverage the GPU to such an extent that the CPU is nearly idle, 
free to just take care of the business logic and the setup work.  The “turtle 
graphics” approach is not going to get us there, but we know many programmers 
don’t know any other way.  It’s only good enough for mostly-static graphics.

I agree with the sentiment: don’t waste window space with whitespace, don’t 
oversimplify, don’t hide functionality that a lot of users need, don’t spread 
out conversations in chat apps just to make it look more “relaxed” at the 
expense of information density.  But you can realize dense designs with Qt 
Quick too.

When it comes to Controls 2 styles: we followed open, published design 
guidelines, which were made by contemporary designers with contemporary taste.  
But you can make your own style, and make it as dense as you want.  Controls 2 
consists of behavioral C++ code, with the rendering being done by instantiating 
Qt Quick items rather than by imperative QPainter code.  Different styles have 
different sizes for each control.

Using Controls 2 is not mandatory: you can build a whole set of controls from 
scratch using plain Qt Quick, that way you have as much design freedom as you 
want.  Before Controls 1, it had to be done that way, so it’s been done plenty 
of times here and there.  Some examples and manual tests in qtdeclarative have 
custom controls; the newest ones are in 
qtdeclarative/tests/manual/pointer/content.  They were written to validate that 
Pointer Handlers could be used for that, not to make a complete set of 
controls; but you could learn from those and make more.  The more customized 
you want it, the more I would recommend doing it that way.

Controls 1 was also built that way (but without the benefit of pointer 
handlers): pure component architecture with as little custom C++ as possible.  
Certain mistakes led to performance problems, but IMO it does not invalidate 
the concept: it’s possible to write simple sets of controls that have most of 
the functionality and also good performance, especially if the control has only 
a built-in style rather than trying to load various styles.

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

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

2021-04-22 Thread Jérôme Godbout

I wonder if it would be possible to totally declare the QtQuick scene from C++ 
without any Qml files actually, with Qt6 you got C++ binding and the Qml is 
compiled to C++ anyway. Maybe I miss something but it could be possible to 
actually only write C++ to create the actual scene?!

I would not actually do this myself but it might attract some user that are 
scare of declarative, I love Qml and the declarative binding make it super easy 
to glue the model to the GUI and the GUI is not seen into the C++ and my model 
are stay clean. I find the Qml way to split the layer of the application pretty 
clean if you understand what you have to do (keep the model and the business 
logic into C++, Qml is only for the GUI and display). The model exposes 
property and signal/slot, that it’s doesn’t care where it come from or what is 
going to modify it. That really force you to have a split between GUI layer and 
the business logic layer. I stop using QWidgets a few years ago and I don’t 
miss it a bit, haven’t seen anything I could not achieved into Qml yet, some 
are a bit trickier than they should but in the end prototyping and modifying 
the GUI is so quick, I often make the change live when I’m working with my 
graphic designer and KDAB GammaRay (just need to apply those change after).


From: Interest  on behalf of Bernhard Lindner 

Date: Thursday, April 22, 2021 at 7:01 AM
To: interest@qt-project.org 
Subject: Re: [Interest] Guide me through the Qt offerings for GUIs

> Widgets are heavy, often very complex objects. They often come with all bells 
> and
> whistles. QPushButton always has the data structure to support 
> QPushButton::setMenu,
> even if probably <1% of buttons out there ever use that feature. That’s ok on 
> desktop
> machines, it’s not ok on embedded systems.

Hm, this kind of confirms my impression: Quick is lightweight, simplified and 
suited for
embedded and touch. While widgets are more powerful and suited for complex 
desktops
applications. This makes me wonder even more why Qt gave up widgets. The logical
explanation is, Qt kind of gave up desktop.

You explained why the widgets concept is not compatible with the Quick concept. 
Can you
also explain why it was not possible to implement Quick as an additional, 
mostly widget-
independent C++ layer and then wrap it declaratively?

--
Best Regards,
Bernhard Lindner

___
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

2021-04-22 Thread Jérôme Godbout

Thanks Volker, that was insightful answer. I would love more answer like that!

From: Interest  on behalf of Volker Hilsheimer 

Date: Thursday, April 22, 2021 at 4:52 AM
To: Bernhard Lindner 
Cc: interest@qt-project.org 
Subject: Re: [Interest] Guide me through the Qt offerings for GUIs
> On 21 Apr 2021, at 22:39, Bernhard Lindner  
> wrote:
>
>
>> Personally, I think the exsting QtQuick element should be scrapped and just 
>> focus on QML
>> versions of the existing Widget functionality. I love the QML syntax, hate 
>> that it's not
>> just a layer on top of widgets.
>
> +100
>
> Why this wasn't done from the start is one of the hardest puzzles! I ask 
> myself this
> question every time I read the three letters "QML" :-)

Indeed, it’s an obvious knee-jerk reaction to have when looking at Qt and 
wondering why there are several UI frameworks.

But there are several reasons why things are as they are. Some of them:

* imperative painting

Paint-event based drawing with a “pen” is not easily reconcilable with how GPUs 
like to work. Without a persistent scene graph that is uploaded to the GPU, 
much of the performance you get from a GPU is lost. An animation at 60fps is 
ideally just a draw call on the GPU with some different transformations, not a 
completely new upload of a completely reconstructed scene graph for each frame.

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.

* integer coordinates and clipping

Widgets work with integer coordinates, which starts to be problematic now that 
we have high-DPI displays. And widgets clip are clipped to their parent 
geometry, which was the right choice for those UIs, but is very limiting and 
requires a lot of complex code to solve conceptually simple problems. Hello 
macOS focus ring.
Quick items do not clip and are not clipped, which gives a lot more freedom in 
how shapes are combined and structured.

* declarative vs imperative APIs

Many widget classes don’t have a declarative-friendly API. Plenty of widget 
properties have side effects on other properties, so the order in which 
properties are set matters. That doesn’t work well in a declarative world.

* weight

Widgets are heavy, often very complex objects. They often come with all bells 
and whistles. QPushButton always has the data structure to support 
QPushButton::setMenu, even if probably <1% of buttons out there ever use that 
feature. That’s ok on desktop machines, it’s not ok on embedded systems.

* complexity and hard to customize

Inheritance and reimplementing are nice concepts on paper and works great if 
you build your own custom widget from a reasonably abstract base class. But if 
you have ever tried to subclass e.g. QTreeWidget to modify how certain 
interactions work, then you know how hard it can be to not break the complex 
states that the default implementations rely on.

So, making widgets work in a declarative, GPU friendly world where ease of 
customisation is more important than standard look’n'feel would have required 
many changes to widgets. Those would have been impossible to make without 
invalidating or breaking a lot of code out there, and still not given us the UI 
components we would have needed.

I’m sure there are opportunities to share more code between widgets and quick 
world esp on the UI framework classes, and with Qt 6 we have taken some steps 
into that direction. But whether the benefits outweigh the risks and effort 
requires a case-by-case evaluation.

Volker

___
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

2021-04-22 Thread Vlad Stelmahovsky

it's not a problem of QML, it's just because no any UI/UX guys touched it
at all

On Thu, Apr 22, 2021 at 3:15 PM  wrote:

> > 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.
>
>
>

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

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


On 22/04/2021 14:55, Rui Oliveira wrote:

I know Giuseppe D’Angelo isn't a TQtC employee, but I trust KDABs stuff
in general.

https://www.qtdesktopdays.com/wp-content/uploads/2020/09/keynote.pdf

Slide 19 "Accelerate widget rendering & compositing through RHI", or I
didn't understand something?


In fact, see https://bugreports.qt.io/browse/QTBUG-74407 and related tasks.

HTH,
--
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

2021-04-22 Thread 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

I know Giuseppe D’Angelo isn't a TQtC employee, but I trust KDABs stuff 
in general.


https://www.qtdesktopdays.com/wp-content/uploads/2020/09/keynote.pdf

Slide 19 "Accelerate widget rendering & compositing through RHI", or I 
didn't understand something?


Rui

Em 22/04/2021 13:24, Volker Hilsheimer escreveu:

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.


Cheers,
Volker



On 22 Apr 2021, at 13:18, Rui Oliveira  wrote:

This makes me raise the question: then how will you do the RHI backend for Widgets then, 
if they are so "incompatible"?

Rui

Em 22/04/2021 09:50, Volker Hilsheimer escreveu:

On 21 Apr 2021, at 22:39, Bernhard Lindner  wrote:



Personally, I think the exsting QtQuick element should be scrapped and just 
focus on QML
versions of the existing Widget functionality. I love the QML syntax, hate that 
it's not
just a layer on top of widgets.

+100

Why this wasn't done from the start is one of the hardest puzzles! I ask myself 
this
question every time I read the three letters "QML" :-)

Indeed, it’s an obvious knee-jerk reaction to have when looking at Qt and 
wondering why there are several UI frameworks.

But there are several reasons why things are as they are. Some of them:

* imperative painting

Paint-event based drawing with a “pen” is not easily reconcilable with how GPUs 
like to work. Without a persistent scene graph that is uploaded to the GPU, 
much of the performance you get from a GPU is lost. An animation at 60fps is 
ideally just a draw call on the GPU with some different transformations, not a 
completely new upload of a completely reconstructed scene graph for each frame.

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.


* integer coordinates and clipping

Widgets work with integer coordinates, which starts to be problematic now that 
we have high-DPI displays. And widgets clip are clipped to their parent 
geometry, which was the right choice for those UIs, but is very limiting and 
requires a lot of complex code to solve conceptually simple problems. Hello 
macOS focus ring.
Quick items do not clip and are not clipped, which gives a lot more freedom in 
how shapes are combined and structured.


* declarative vs imperative APIs

Many widget classes don’t have a declarative-friendly API. Plenty of widget 
properties have side effects on other properties, so the order in which 
properties are set matters. That doesn’t work well in a declarative world.


* weight

Widgets are heavy, often very complex objects. They often come with all bells and 
whistles. QPushButton always has the data structure to support 
QPushButton::setMenu, even if probably <1% of buttons out there ever use that 
feature. That’s ok on desktop machines, it’s not ok on embedded systems.


* complexity and hard to customize

Inheritance and reimplementing are nice concepts on paper and works great if 
you build your own custom widget from a reasonably abstract base class. But if 
you have ever tried to subclass e.g. QTreeWidget to modify how certain 
interactions work, then you know how hard it can be to not break the complex 
states that the default implementations rely on.



So, making widgets work in a declarative, GPU friendly world where ease of 
customisation is more important than standard look’n'feel would have required 
many changes to widgets. Those would have been impossible to make without 
invalidating or breaking a lot of code out there, and still not given us the UI 
components we would have needed.

I’m sure there are opportunities to share more code between widgets and quick 
world esp on the UI framework classes, and with Qt 6 we have taken some steps 
into that direction. But whether the benefits outweigh the risks and effort 
requires a case-by-case evaluation.


Volker

___
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

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

2021-04-22 Thread Volker Hilsheimer

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.


Cheers,
Volker


> On 22 Apr 2021, at 13:18, Rui Oliveira  wrote:
> 
> This makes me raise the question: then how will you do the RHI backend for 
> Widgets then, if they are so "incompatible"?
> 
> Rui
> 
> Em 22/04/2021 09:50, Volker Hilsheimer escreveu:
>>> On 21 Apr 2021, at 22:39, Bernhard Lindner  
>>> wrote:
>>> 
>>> 
 Personally, I think the exsting QtQuick element should be scrapped and 
 just focus on QML
 versions of the existing Widget functionality. I love the QML syntax, hate 
 that it's not
 just a layer on top of widgets.
>>> +100
>>> 
>>> Why this wasn't done from the start is one of the hardest puzzles! I ask 
>>> myself this
>>> question every time I read the three letters "QML" :-)
>> 
>> Indeed, it’s an obvious knee-jerk reaction to have when looking at Qt and 
>> wondering why there are several UI frameworks.
>> 
>> But there are several reasons why things are as they are. Some of them:
>> 
>> * imperative painting
>> 
>> Paint-event based drawing with a “pen” is not easily reconcilable with how 
>> GPUs like to work. Without a persistent scene graph that is uploaded to the 
>> GPU, much of the performance you get from a GPU is lost. An animation at 
>> 60fps is ideally just a draw call on the GPU with some different 
>> transformations, not a completely new upload of a completely reconstructed 
>> scene graph for each frame.
>> 
>> 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.
>> 
>> 
>> * integer coordinates and clipping
>> 
>> Widgets work with integer coordinates, which starts to be problematic now 
>> that we have high-DPI displays. And widgets clip are clipped to their parent 
>> geometry, which was the right choice for those UIs, but is very limiting and 
>> requires a lot of complex code to solve conceptually simple problems. Hello 
>> macOS focus ring.
>> Quick items do not clip and are not clipped, which gives a lot more freedom 
>> in how shapes are combined and structured.
>> 
>> 
>> * declarative vs imperative APIs
>> 
>> Many widget classes don’t have a declarative-friendly API. Plenty of widget 
>> properties have side effects on other properties, so the order in which 
>> properties are set matters. That doesn’t work well in a declarative world.
>> 
>> 
>> * weight
>> 
>> Widgets are heavy, often very complex objects. They often come with all 
>> bells and whistles. QPushButton always has the data structure to support 
>> QPushButton::setMenu, even if probably <1% of buttons out there ever use 
>> that feature. That’s ok on desktop machines, it’s not ok on embedded systems.
>> 
>> 
>> * complexity and hard to customize
>> 
>> Inheritance and reimplementing are nice concepts on paper and works great if 
>> you build your own custom widget from a reasonably abstract base class. But 
>> if you have ever tried to subclass e.g. QTreeWidget to modify how certain 
>> interactions work, then you know how hard it can be to not break the complex 
>> states that the default implementations rely on.
>> 
>> 
>> 
>> So, making widgets work in a declarative, GPU friendly world where ease of 
>> customisation is more important than standard look’n'feel would have 
>> required many changes to widgets. Those would have been impossible to make 
>> without invalidating or breaking a lot of code out there, and still not 
>> given us the UI components we would have needed.
>> 
>> I’m sure there are opportunities to share more code between widgets and 
>> quick world esp on the UI framework classes, and with Qt 6 we have taken 
>> some steps into that direction. But whether the benefits outweigh the risks 
>> and effort requires a case-by-case evaluation.
>> 
>> 
>> Volker
>> 
>> ___
>> 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

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

That's nowhere near work of art. It's pretty much what the other poster 
was describing, a flat UI.


On 4/22/21 4:35 AM, Vlad Stelmahovsky wrote:
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 



if you dont know how, doesnt meant is not possible

On Thu, Apr 22, 2021 at 11:00 AM Roland Hughes 
mailto:rol...@logikalsolutions.com>> wrote:



On 4/22/2021 3:47 AM,  Nuno Santos wrote:

Boas Rui,


On 21 Apr 2021, at 18:24, Rui Oliveira  
  wrote:
I did notice your product line before, when you first answered me.

I like the look! Would you like to tell a bit about your experience in 
moving to Qt Quick? What were your main barriers?


As I just mentioned in my last email, it is a mindset shift. When I started 
using QtQuick I was not aware that I really needed a new mindset to work with 
Qml. That took me a while.


One of the biggest dangers is people drunk driving across all
three lanes.


https://www.logikalsolutions.com/wordpress/uncategorized/so-you-cant-get-your-qt-models-to-work-with-qml/




-- 
Roland Hughes, President

Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com  
https://infiniteexposure.net  
https://lesedi.us  
https://johnsmith-book.com  
https://logikalblog.com  
https://interestingauthors.com/blog  

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




--
Best regards,
Vlad


--
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] Guide me through the Qt offerings for GUIs

This makes me raise the question: then how will you do the RHI backend 
for Widgets then, if they are so "incompatible"?


Rui

Em 22/04/2021 09:50, Volker Hilsheimer escreveu:

On 21 Apr 2021, at 22:39, Bernhard Lindner  wrote:



Personally, I think the exsting QtQuick element should be scrapped and just 
focus on QML
versions of the existing Widget functionality. I love the QML syntax, hate that 
it's not
just a layer on top of widgets.

+100

Why this wasn't done from the start is one of the hardest puzzles! I ask myself 
this
question every time I read the three letters "QML" :-)


Indeed, it’s an obvious knee-jerk reaction to have when looking at Qt and 
wondering why there are several UI frameworks.

But there are several reasons why things are as they are. Some of them:

* imperative painting

Paint-event based drawing with a “pen” is not easily reconcilable with how GPUs 
like to work. Without a persistent scene graph that is uploaded to the GPU, 
much of the performance you get from a GPU is lost. An animation at 60fps is 
ideally just a draw call on the GPU with some different transformations, not a 
completely new upload of a completely reconstructed scene graph for each frame.

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.


* integer coordinates and clipping

Widgets work with integer coordinates, which starts to be problematic now that 
we have high-DPI displays. And widgets clip are clipped to their parent 
geometry, which was the right choice for those UIs, but is very limiting and 
requires a lot of complex code to solve conceptually simple problems. Hello 
macOS focus ring.
Quick items do not clip and are not clipped, which gives a lot more freedom in 
how shapes are combined and structured.


* declarative vs imperative APIs

Many widget classes don’t have a declarative-friendly API. Plenty of widget 
properties have side effects on other properties, so the order in which 
properties are set matters. That doesn’t work well in a declarative world.


* weight

Widgets are heavy, often very complex objects. They often come with all bells and 
whistles. QPushButton always has the data structure to support 
QPushButton::setMenu, even if probably <1% of buttons out there ever use that 
feature. That’s ok on desktop machines, it’s not ok on embedded systems.


* complexity and hard to customize

Inheritance and reimplementing are nice concepts on paper and works great if 
you build your own custom widget from a reasonably abstract base class. But if 
you have ever tried to subclass e.g. QTreeWidget to modify how certain 
interactions work, then you know how hard it can be to not break the complex 
states that the default implementations rely on.



So, making widgets work in a declarative, GPU friendly world where ease of 
customisation is more important than standard look’n'feel would have required 
many changes to widgets. Those would have been impossible to make without 
invalidating or breaking a lot of code out there, and still not given us the UI 
components we would have needed.

I’m sure there are opportunities to share more code between widgets and quick 
world esp on the UI framework classes, and with Qt 6 we have taken some steps 
into that direction. But whether the benefits outweigh the risks and effort 
requires a case-by-case evaluation.


Volker

___
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


On 22/04/2021 13:01, Bernhard Lindner wrote:

You explained why the widgets concept is not compatible with the Quick concept. 
Can you
also explain why it was not possible to implement Quick as an additional, 
mostly widget-
independent C++ layer and then wrap it declaratively?


Do you mean, also offer C++ APIs for Qt Quick? (As well as the QML APIs 
you have today.)


Thanks,
--
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

2021-04-22 Thread Bernhard Lindner


> Widgets are heavy, often very complex objects. They often come with all bells 
> and
> whistles. QPushButton always has the data structure to support 
> QPushButton::setMenu,
> even if probably <1% of buttons out there ever use that feature. That’s ok on 
> desktop
> machines, it’s not ok on embedded systems.

Hm, this kind of confirms my impression: Quick is lightweight, simplified and 
suited for
embedded and touch. While widgets are more powerful and suited for complex 
desktops
applications. This makes me wonder even more why Qt gave up widgets. The logical
explanation is, Qt kind of gave up desktop.

You explained why the widgets concept is not compatible with the Quick concept. 
Can you
also explain why it was not possible to implement Quick as an additional, 
mostly widget-
independent C++ layer and then wrap it declaratively?

-- 
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



On 4/22/2021 3:47 AM, Rui Oliveira wrote:

QML/Quick, for me, seems to need a lot of work for the desktop. Also, it
seems it's make for "flat", low density UIs. Yesterday I was presented
with this:https://ossia.io/  . Look how good it looks
(https://ossia.io/assets/score.png)! Holy damn, an that's widgets.


https://duckduckgo.com/?t=ffnt=connex+spot+monitor=images=images=https%3A%2F%2Fimage.tigermedical.com%2FProducts%2FLargeImages%2FWEL71XX-B-.jpg

That's all widgets baby. The CPU doesn't even have a GPU

Download the user manual and check out the screen shots inside.

https://www.hillrom.com/content/dam/hillrom-aem/us/en/sap-documents/LIT/80025/80025960LITPDF.pdf

That thing is a work of art. I just wish they would have included a shot 
of the readings history table. Apple ain't ever put out anything that 
looked so cool and was 100% functional.


QML can't hold a candle to it.

Those bricks can be re-arranged and re-sized without any use of layouts.

When you gotta bring the Uber Cool you gotta use widgets.

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

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

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

2021-04-22 Thread Nuno Santos

"QML is just a hand polished turd. There is no polite way to put it.”

"Qt made a desperate ploy to attract script kiddies in the iDiot phone market 
with QML.”

"The problem is, by and large, script kiddies don’t know anything. They tend to 
be “self-taught” with far more emphasis on “self” than “taught.””

by Roland Hughes (The Polished Turd)


> On 22 Apr 2021, at 10:35, Vlad Stelmahovsky  
> wrote:
> 
> 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
>  
> 
> 
> if you dont know how, doesnt meant is not possible
>  
> 
> On Thu, Apr 22, 2021 at 11:00 AM Roland Hughes  > wrote:
> 
> 
> On 4/22/2021 3:47 AM,  Nuno Santos wrote:
>> Boas Rui,
>> 
>>> On 21 Apr 2021, at 18:24, Rui Oliveira  
>>>  wrote:
>>> I did notice your product line before, when you first answered me.  
>>> 
>>> I like the look! Would you like to tell a bit about your experience in 
>>> moving to Qt Quick? What were your main barriers?
>>> 
>> As I just mentioned in my last email, it is a mindset shift. When I started 
>> using QtQuick I was not aware that I really needed a new mindset to work 
>> with Qml. That took me a while.
> One of the biggest dangers is people drunk driving across all three lanes.
> 
> https://www.logikalsolutions.com/wordpress/uncategorized/so-you-cant-get-your-qt-models-to-work-with-qml/
>  
> 
> 
> -- 
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593
> 
> https://theminimumyouneedtoknow.com 
> https://infiniteexposure.net 
> https://lesedi.us 
> https://johnsmith-book.com 
> https://logikalblog.com 
> https://interestingauthors.com/blog 
> ___
> Interest mailing list
> Interest@qt-project.org 
> https://lists.qt-project.org/listinfo/interest 
> 
> 
> 
> -- 
> Best regards,
> Vlad
> ___
> 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



On 4/22/2021 3:47 AM, Bernhard Lindner wrote:

Judging from the influx in the CopperSpice world, a lot of companies with 
projects large
and small are biting the bullet.

How did you come to this result? Are there any hard numbers, links, reports, 
etc. that you
can share?


Hard? Don't know. They don't publish the number of support contracts 
sold. I'm just seeing an up-tick in conversations like this one:


https://forum.copperspice.com/viewtopic.php?f=8=1715

More and more commercial projects asking for porting assistance. Barb 
and the others used to pop-in to the forum answering questions most 
every day, now it is down to 1-2 days per week. The claim has been made 
that they are too busy supporting paying customers. Maybe, maybe not. 
Things aren't as complete and polished yet, so I'm leaning more towards 
the maybe.


The CopperSpice and Python thread now has 6980 views.
The CopperSpice License Question thread started Dec 11, 2020 got quite a 
few posts and 3846 views.


I honestly thought the FOX Toolkit died with Windows 2000. The 
screenshots of applications on their site all have a very DECWindows 
look and feel.


http://fox-toolkit.org

I haven't kicked the tires on it yet. I have noticed it got a lot more 
interest last year when all of the licensing chatter happened here.


https://sourceforge.net/p/foxgui/mailman/foxgui-users/

I don't know how well their 3D stuff works. I do like the concept of 
staying in the center lanes of C++. I'm somewhat curious if the claims 
on their site are true that applications can build and run on Windows 9x 
and the same source can build and run on current Linux. Especially if 
one is using the graphics stuff. Just not enough time in the day to set 
things up and test all that should be tested. At one place somewhere 
they mentioned building with OpenWatcom but don't list it in other places.


The one thing that project definitely needs is a consistent location. 
Stuff is scattered all over between SourceForge and several other sites.


--

Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

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

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

2021-04-22 Thread 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

if you dont know how, doesnt meant is not possible


On Thu, Apr 22, 2021 at 11:00 AM Roland Hughes 
wrote:

>
> On 4/22/2021 3:47 AM,  Nuno Santos wrote:
>
> Boas Rui,
>
>
> On 21 Apr 2021, at 18:24, Rui Oliveira  
>  wrote:
> I did notice your product line before, when you first answered me.
>
> I like the look! Would you like to tell a bit about your experience in moving 
> to Qt Quick? What were your main barriers?
>
>
> As I just mentioned in my last email, it is a mindset shift. When I started 
> using QtQuick I was not aware that I really needed a new mindset to work with 
> Qml. That took me a while.
>
> One of the biggest dangers is people drunk driving across all three lanes.
>
>
> https://www.logikalsolutions.com/wordpress/uncategorized/so-you-cant-get-your-qt-models-to-work-with-qml/
>
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593
> https://theminimumyouneedtoknow.comhttps://infiniteexposure.nethttps://lesedi.ushttps://johnsmith-book.comhttps://logikalblog.comhttps://interestingauthors.com/blog
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>


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

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



On 4/22/2021 3:47 AM,  Nuno Santos wrote:

Boas Rui,


On 21 Apr 2021, at 18:24, Rui Oliveira  wrote:
I did notice your product line before, when you first answered me.

I like the look! Would you like to tell a bit about your experience in moving 
to Qt Quick? What were your main barriers?


As I just mentioned in my last email, it is a mindset shift. When I started 
using QtQuick I was not aware that I really needed a new mindset to work with 
Qml. That took me a while.


One of the biggest dangers is people drunk driving across all three lanes.

https://www.logikalsolutions.com/wordpress/uncategorized/so-you-cant-get-your-qt-models-to-work-with-qml/


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

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

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

2021-04-22 Thread Volker Hilsheimer

> On 21 Apr 2021, at 22:39, Bernhard Lindner  
> wrote:
> 
> 
>> Personally, I think the exsting QtQuick element should be scrapped and just 
>> focus on QML
>> versions of the existing Widget functionality. I love the QML syntax, hate 
>> that it's not
>> just a layer on top of widgets.
> 
> +100
> 
> Why this wasn't done from the start is one of the hardest puzzles! I ask 
> myself this
> question every time I read the three letters "QML" :-) 

Indeed, it’s an obvious knee-jerk reaction to have when looking at Qt and 
wondering why there are several UI frameworks.

But there are several reasons why things are as they are. Some of them:

* imperative painting

Paint-event based drawing with a “pen” is not easily reconcilable with how GPUs 
like to work. Without a persistent scene graph that is uploaded to the GPU, 
much of the performance you get from a GPU is lost. An animation at 60fps is 
ideally just a draw call on the GPU with some different transformations, not a 
completely new upload of a completely reconstructed scene graph for each frame.

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.

* integer coordinates and clipping

Widgets work with integer coordinates, which starts to be problematic now that 
we have high-DPI displays. And widgets clip are clipped to their parent 
geometry, which was the right choice for those UIs, but is very limiting and 
requires a lot of complex code to solve conceptually simple problems. Hello 
macOS focus ring.
Quick items do not clip and are not clipped, which gives a lot more freedom in 
how shapes are combined and structured.

* declarative vs imperative APIs

Many widget classes don’t have a declarative-friendly API. Plenty of widget 
properties have side effects on other properties, so the order in which 
properties are set matters. That doesn’t work well in a declarative world.

* weight

Widgets are heavy, often very complex objects. They often come with all bells 
and whistles. QPushButton always has the data structure to support 
QPushButton::setMenu, even if probably <1% of buttons out there ever use that 
feature. That’s ok on desktop machines, it’s not ok on embedded systems.

* complexity and hard to customize

Inheritance and reimplementing are nice concepts on paper and works great if 
you build your own custom widget from a reasonably abstract base class. But if 
you have ever tried to subclass e.g. QTreeWidget to modify how certain 
interactions work, then you know how hard it can be to not break the complex 
states that the default implementations rely on.

So, making widgets work in a declarative, GPU friendly world where ease of 
customisation is more important than standard look’n'feel would have required 
many changes to widgets. Those would have been impossible to make without 
invalidating or breaking a lot of code out there, and still not given us the UI 
components we would have needed.

I’m sure there are opportunities to share more code between widgets and quick 
world esp on the UI framework classes, and with Qt 6 we have taken some steps 
into that direction. But whether the benefits outweigh the risks and effort 
requires a case-by-case evaluation.

Volker

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

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

Well, I think this needs some historial context. Remember Nokia and how 
they wanted Qt to be the /de facto/ SDK for their mobile SO? QWidgets + 
phones? Not that great of a deal... Now update that story to Android or 
whatever, and Widgets aren't an answer for mobile development. It makes 
sense QML/Quick is what it is.


What doesn't make sense, to me at least, is how QQC*1* seemed to have 
had a better feature set for the desktop than QQC*2*. I mean, one would 
expect progress, not regression... But oh well.


QML/Quick, for me, seems to need a lot of work for the desktop. Also, it 
seems it's make for "flat", low density UIs. Yesterday I was presented 
with this: https://ossia.io/ . Look how good it looks 
(https://ossia.io/assets/score.png)! Holy damn, an that's widgets. And 
that's a proper desktop productivity application. I mean, if we look at 
like NeoChat (https://matrix.org/docs/projects/client/neo-chat/), which 
is made with KDE Kirigami (a Qt Quick framework extension), or the 
Telegram desktop application, they look all nice and all, but they lack 
the density.


Real productivity applications, that are to be mouse operated, and have 
desktop-first (and only) oriented designs have density. Look at 
Solidworks, look at EagleCAD, look at QtCreator of all things! Even 
vscode, which is an electron app, has the extra UI density needed for 
productivity on desktop. I mean, I'm writing this in Mozilla 
Thunderbird, and any "modern" client, with a "flat" UI would have half, 
or even less, the information density, at the gain of what? Nice 
screenshots?


And I use Windows, so I know very much first hand how low density "flat 
UI" is useless for any real work.


I don't know much, if anything, about design, but I am indeed a user of 
a computer, it's easy to see what makes me more productive or not.


As always, anything I do is an invitation for comments.

Rui

Em 21/04/2021 21:39, Bernhard Lindner escreveu:

Personally, I think the exsting QtQuick element should be scrapped and just 
focus on QML
versions of the existing Widget functionality. I love the QML syntax, hate that 
it's not
just a layer on top of widgets.

+100

Why this wasn't done from the start is one of the hardest puzzles! I ask myself 
this
question every time I read the three letters "QML" :-)

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

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

2021-04-21 Thread Bernhard Lindner


> Personally, I think the exsting QtQuick element should be scrapped and just 
> focus on QML
> versions of the existing Widget functionality. I love the QML syntax, hate 
> that it's not
> just a layer on top of widgets.

+100

Why this wasn't done from the start is one of the hardest puzzles! I ask myself 
this
question every time I read the three letters "QML" :-) 

-- 
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

2021-04-21 Thread Bernhard Lindner


> Judging from the influx in the CopperSpice world, a lot of companies with 
> projects large
> and small are biting the bullet.

How did you come to this result? Are there any hard numbers, links, reports, 
etc. that you
can share?

-- 
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



On 4/21/2021 11:04 AM, Giuseppe D'Angelo wrote:

On 21/04/2021 17:42, Jason H wrote:

Personally, I think the exsting QtQuick element should be scrapped and
just focus on QML versions of the existing Widget functionality. I love
the QML syntax, hate that it's not just a layer on top of widgets.
That said, I still really like both.

Do you mean something like this

https://github.com/KDAB/DeclarativeWidgets

or actually reimplementing the widgets themselves?


Having had this conversation before in here, I believe he means exactly 
what Tweedle Dee and Tweedle Dum described to me as QML during dart 
league all of those years ago.


QML fully pre-compiles to Widgets.

Just a way of getting rid of .UI files that, during 4.x days had a 
history of getting corrupted. Yes, we recently had yet another instance 
of that in here where someone opened old 4.x era .UI files with 
current/recent Designer and the hidden deleted layout started kicking 
widgets that shouldn't be there into the running application.


A QML-like syntax that generated C++ source and header files for widgets 
much like happens with .UI, kicking JavaScript to the curb. You get the 
snap and feel of native binary without having to saddle an application 
with 2 VMs.



--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

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

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

2021-04-21 Thread Nuno Santos

Boas Rui,

> On 21 Apr 2021, at 18:24, Rui Oliveira  wrote:
> I did notice your product line before, when you first answered me.  
> 
> I like the look! Would you like to tell a bit about your experience in moving 
> to Qt Quick? What were your main barriers?
> 

As I just mentioned in my last email, it is a mindset shift. When I started 
using QtQuick I was not aware that I really needed a new mindset to work with 
Qml. That took me a while.

Then possibilites are quite endless since you have a lot of data 
interoperability between C++ and Javascript on the Qml side. Some of this 
capabilities you will only learn later when you are confortable with the 
basics. 

Of course things can get complex, specially when you have to create your own 
scene graph nodes, to draw custom high performance views, just like the one you 
want to do for your application to display an FFT visualiser.


I believe the architecture will change from application to application and from 
developer to developer.

> And how much work was it to get this look?
> 

It really depends on the complexity of UI. But in general, 5x to 10x times of 
less with any other UI technology I have ever used.

For instance, TKFX, LK and DRC did not had designer. I have made the design 
while coding the apps. I would make visual improvements along the way, 
iteration by iteration. 

FRMS and K7D and ConnectionOpen have design work. I’ve set the building the 
blocks and the designer provided me the style. Then applied the style.

> They should give you a talk time at a Qt  days!
> 
Actually I had a chance to share my story 4 years ago at QtWS17 -> 
https://www.youtube.com/watch?v=vgBq4dMoI_g 


It is a bit outdated now. I only had 3 products back then! :)

Nuno

> Rui
> 
> Em 21/04/2021 17:31, Nuno Santos escreveu:
>> For me, the major benefit of Qml is speed. Before using Qml I’ve done a 
>> couple of years doing Qt Widgets. The glue code to make things work is a big 
>> pain. You can declare interfaces so easily in Qml, and still have the 
>> ability to quickly change everything without having to rewrite all the glue 
>> code. I’ve also coded native iOS and Android. Major pain with glue code 
>> again.
>> 
>> If you care about time to market, Qml is a definitely worth the investment. 
>> It is an investment because if you are still in the Widgets mindset, it will 
>> take you a while until you have a Quick mindset.
>> 
>> I realised that I could never maintain multiple code bases and make the 
>> product line grow, alone…. but with QtQuick I did. I’ve been using Qt Quick 
>> since 2014, 7 years now. In 7 years I’ve built 7 products:
>> 
>> www.imaginando.pt/products/drc 
>> www.imaginando.pt/products/frms 
>> www.imaginando.pt/products/k7d 
>> www.imaginando.pt/products/dlym 
>> www.imaginando.pt/products/lk 
>> www.imaginando.pt/products/tkfx 
>> www.connectionopen.com 
>> 
>> Most of this products are available for all platforms, Windows, Mac, iOS and 
>> Android, with a consistent look in all platforms.
>> 
>> Nuno
>> 
>>> On 21 Apr 2021, at 17:13, Rui Oliveira >> > wrote:
>>> 
>>> At least, it would be convenient to reap the benefits of QML: HW 
>>> acceleration, for example. 
>>> 
>>> I personally don't care for QML. I would prefer to write everything in C++. 
>>> But that's me. If there was a "no-QML-Quick-API" I'd be so much happy. No 
>>> more gluing code and properties and questions like 
>>> this:https://stackoverflow.com/questions/66618613/qml-c-classes-with-bring-your-own-component
>>>  
>>> 
>>> I could just use what I know: C++... The talk Volker linked in this thread 
>>> talks a lot about "working easily with your designers". But I'm just me... 
>>> So the team point is moot. I also don't have a background as frontend 
>>> engineer, so I never bothered to learn JS. I guess it's implicit that this 
>>> is another advantage of QML. Just take the armies of frontend devs that 
>>> exist in the web design market and employ them on GUI applications, cheaper 
>>> than a C++ programmer. Likewise, that sure is a reason of why Electron and 
>>> web backends on JS are so popular (and the results so disastrous, 
>>> sometimes). Some seem to agree with me: https://github.com/uwerat/qskinny 
>>> 
>>> But I think the "dream" is the same feature set as QWidgets as Qt Quick 
>>> Controls. And some things to make desktop usage actually decent, like 
>>> native dialogues and especially menus. So that on Macs the menu goes to the 
>>> top bar (also on some GNU/Linux graphical configurations),

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

2021-04-21 Thread Thorsten Glaser

On Wed, 21 Apr 2021, Giuseppe D'Angelo via Interest wrote:

> I'm not sure where to find QML on desktop stories, there's however a showroom
> https://showroom.qt.io/ where people can leave links to their applications.

You can probably add MuseScore 4 to that list. Mu͒4 is not yet finished but
it’s definitely implementing quite a massive amount in QML. See
https://github.com/musescore/MuseScore/tree/master/src/appshell/qml and
other directories.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

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

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


Olá Nuno,

I did notice your product line before, when you first answered me.

I like the look! Would you like to tell a bit about your experience in 
moving to Qt Quick? What were your main barriers? And how much work was 
it to get this look?


They should give you a talk time at a Qt  days!

Rui

Em 21/04/2021 17:31, Nuno Santos escreveu:
For me, the major benefit of Qml is speed. Before using Qml I’ve done 
a couple of years doing Qt Widgets. The glue code to make things work 
is a big pain. You can declare interfaces so easily in Qml, and still 
have the ability to quickly change everything without having to 
rewrite all the glue code. I’ve also coded native iOS and 
Android. Major pain with glue code again.


If you care about time to market, Qml is a definitely worth the 
investment. It is an investment because if you are still in the 
Widgets mindset, it will take you a while until you have a Quick mindset.


I realised that I could never maintain multiple code bases and make 
the product line grow, alone…. but with QtQuick I did. I’ve been using 
Qt Quick since 2014, 7 years now. In 7 years I’ve built 7 products:


www.imaginando.pt/products/drc 
www.imaginando.pt/products/frms 
www.imaginando.pt/products/k7d 
www.imaginando.pt/products/dlym 
www.imaginando.pt/products/lk 
www.imaginando.pt/products/tkfx 
www.connectionopen.com 

Most of this products are available for all platforms, Windows, Mac, 
iOS and Android, with a consistent look in all platforms.


Nuno

On 21 Apr 2021, at 17:13, Rui Oliveira > wrote:


At least, it would be convenient to reap the benefits of QML: HW 
acceleration, for example.


I personally don't care for QML. I would prefer to write everything 
in C++. But that's me. If there was a "no-QML-Quick-API" I'd be so 
much happy. No more gluing code and properties and questions like 
this: 
https://stackoverflow.com/questions/66618613/qml-c-classes-with-bring-your-own-component
I could just use what I know: C++... The talk Volker linked in this 
thread talks a lot about "working easily with your designers". But 
I'm just me... So the team point is moot. I also don't have a 
background as frontend engineer, so I never bothered to learn JS. I 
guess it's implicit that this is another advantage of QML. Just take 
the armies of frontend devs that exist in the web design market and 
employ them on GUI applications, cheaper than a C++ programmer. 
Likewise, that sure is a reason of why Electron and web backends on 
JS are so popular (and the results so disastrous, sometimes). Some 
seem to agree with me: https://github.com/uwerat/qskinny


But I think the "dream" is the same feature set as QWidgets as Qt 
Quick Controls. And some things to make desktop usage actually 
decent, like native dialogues and especially menus. So that on Macs 
the menu goes to the top bar (also on some GNU/Linux graphical 
configurations), etc etc. When I look at frameworks from like the 
.net ecosystem, which is growing so fast, I see exactly that. 
Practical example: https://avaloniaui.net/ is totally rendered with 
SKIA#, but there is 
http://reference.avaloniaui.net/api/Avalonia.Controls/NativeMenu/. 
Also, allowing the window to resize without it glitching all over, 
and other desktop/productivity things.


Or, in reverse, if the RHI backend for QWidgets really comes to life, 
and QWidgets keeps receiving some love to be up standard with the 
latest OSes, and receive a public RHI Painter API instead of 
QOpenGLWidget, and look decent on hi-dpi, that's a winning product 
right there. In my opinion, anyway...


That said, I wouldn't support scrapping what's already done. Just 
improving it. Like the native look and feel in QML actually going 
somewhere, and having a feature-equivalent set to QWidgets for 
desktop work.


Rui

Em 21/04/2021 16:48, Giuseppe D'Angelo via Interest escreveu:

On 21/04/2021 17:42, Jason H wrote:
Personally, I think the exsting QtQuick element should be scrapped 
and just focus on QML versions of the existing Widget 
functionality. I love the QML syntax, hate that it's not just a 
layer on top of widgets.

That said, I still really like both.


Do you mean something like this

https://github.com/KDAB/DeclarativeWidgets

or actually reimplementing the widgets themselves?

Thanks,


___
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

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

2021-04-21 Thread Jason H

> On 21/04/2021 17:42, Jason H wrote:
> > Personally, I think the exsting QtQuick element should be scrapped and
> > just focus on QML versions of the existing Widget functionality. I love
> > the QML syntax, hate that it's not just a layer on top of widgets.
> > That said, I still really like both.
>
> Do you mean something like this
>
> https://github.com/KDAB/DeclarativeWidgets
>
> or actually reimplementing the widgets themselves?

There's a couple things going on here:
1. API
2. UI

Ideally the API should be widgets, the UI should be Quick.

* Making a library where QGraphicsProxyWidget seems like a right choice. (UI)
* I believe that there was some recent talk at reimplementing Qt Quick Controls 
with
  proper theming via 
https://api.kde.org/frameworks/qqc2-desktop-style/html/index.html
  also seems like a right (UI)
* The DeclarativeWidgets seems like what Qt should have done from the 
beginning. (API) (?)
  But... is not using QtQuick rendering. (Also there should be gallery!) 
"Declarative Widgets
allows you to use Qt Widgets with QML, but it does not use Qt Quick. 
Declarative Widgets is
still using the Qt Widgets rendering and wrapping platform native 
components under the hood,
whilst Qt Quick uses OpenGL for rendering (a software renderer is now 
available) and you had
to build your UI from basic components. Qt Quick Controls provide standard 
controls for Qt Quick."

And then there's https://github.com/uwerat/qskinny, kinda related but not.

It's a shame that the DeclarativeWidgets requires a supplemental commercial 
license (or GPL).
And looking up the commercial license cost is "contact sales" which means it's 
too expensive.
The motivation for use is "I rather the old API" but the interest level does 
not rise
to the level of "contacting sales". If it were transparently prices at the 
price of a
developer tool ($40-60) I could splurge. Think a Qt Marketplace offering?

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

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

2021-04-21 Thread Nuno Santos

For me, the major benefit of Qml is speed. Before using Qml I’ve done a couple 
of years doing Qt Widgets. The glue code to make things work is a big pain. You 
can declare interfaces so easily in Qml, and still have the ability to quickly 
change everything without having to rewrite all the glue code. I’ve also coded 
native iOS and Android. Major pain with glue code again.

If you care about time to market, Qml is a definitely worth the investment. It 
is an investment because if you are still in the Widgets mindset, it will take 
you a while until you have a Quick mindset.

I realised that I could never maintain multiple code bases and make the product 
line grow, alone…. but with QtQuick I did. I’ve been using Qt Quick since 2014, 
7 years now. In 7 years I’ve built 7 products:

www.imaginando.pt/products/drc 
www.imaginando.pt/products/frms 
www.imaginando.pt/products/k7d 
www.imaginando.pt/products/dlym 
www.imaginando.pt/products/lk 
www.imaginando.pt/products/tkfx 
www.connectionopen.com 

Most of this products are available for all platforms, Windows, Mac, iOS and 
Android, with a consistent look in all platforms.

Nuno

> On 21 Apr 2021, at 17:13, Rui Oliveira  wrote:
> 
> At least, it would be convenient to reap the benefits of QML: HW 
> acceleration, for example. 
> 
> I personally don't care for QML. I would prefer to write everything in C++. 
> But that's me. If there was a "no-QML-Quick-API" I'd be so much happy. No 
> more gluing code and properties and questions like this: 
> https://stackoverflow.com/questions/66618613/qml-c-classes-with-bring-your-own-component
>  
> 
> I could just use what I know: C++... The talk Volker linked in this thread 
> talks a lot about "working easily with your designers". But I'm just me... So 
> the team point is moot. I also don't have a background as frontend engineer, 
> so I never bothered to learn JS. I guess it's implicit that this is another 
> advantage of QML. Just take the armies of frontend devs that exist in the web 
> design market and employ them on GUI applications, cheaper than a C++ 
> programmer. Likewise, that sure is a reason of why Electron and web backends 
> on JS are so popular (and the results so disastrous, sometimes). Some seem to 
> agree with me: https://github.com/uwerat/qskinny 
> 
> But I think the "dream" is the same feature set as QWidgets as Qt Quick 
> Controls. And some things to make desktop usage actually decent, like native 
> dialogues and especially menus. So that on Macs the menu goes to the top bar 
> (also on some GNU/Linux graphical configurations), etc etc. When I look at 
> frameworks from like the .net ecosystem, which is growing so fast, I see 
> exactly that. Practical example: https://avaloniaui.net/ 
>  is totally rendered with SKIA#, but there 
> ishttp://reference.avaloniaui.net/api/Avalonia.Controls/NativeMenu/ 
> . Also, 
> allowing the window to resize without it glitching all over, and other 
> desktop/productivity things. 
> 
> Or, in reverse, if the RHI backend for QWidgets really comes to life, and 
> QWidgets keeps receiving some love to be up standard with the latest OSes, 
> and receive a public RHI Painter API instead of QOpenGLWidget, and look 
> decent on hi-dpi, that's a winning product right there. In my opinion, 
> anyway...
> 
> That said, I wouldn't support scrapping what's already done. Just improving 
> it. Like the native look and feel in QML actually going somewhere, and having 
> a feature-equivalent set to QWidgets for desktop work. 
> 
> Rui
> 
> Em 21/04/2021 16:48, Giuseppe D'Angelo via Interest escreveu:
>> On 21/04/2021 17:42, Jason H wrote: 
>>> Personally, I think the exsting QtQuick element should be scrapped and just 
>>> focus on QML versions of the existing Widget functionality. I love the QML 
>>> syntax, hate that it's not just a layer on top of widgets. 
>>> That said, I still really like both. 
>> 
>> Do you mean something like this 
>> 
>> https://github.com/KDAB/DeclarativeWidgets 
>>  
>> 
>> or actually reimplementing the widgets themselves? 
>> 
>> Thanks, 
>> 
>> 
>> 
>> ___
>> Interest mailing list
>> Interest@qt-project.org 
>> https://lists.qt-project.org/listinfo/interest 
>> 
> ___
> Interest mailing list
> Interest@qt-project.org
>

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

I'm amazed. The GldSrc and the Source engines aren't famous for being 
super easy to work with. And somehow Qt Quick can be integrated to make 
the menus? Damn, I'd like to see that source code.


Although, this reminded me of a related example: https://sciter.com/ 
(notice the first example in the image pane).


Also, this one: https://docs.ultralig.ht/docs/integrating-with-games

Interesting, and amazing, that these things are possible!


Em 21/04/2021 16:51, Giuseppe D'Angelo via Interest escreveu:

On 21/04/2021 16:10, Rui Oliveira wrote:

Black Mesa Source?! Now that's an interesting one haha!



Yep, https://steamdb.info/depot/362894/ shows some familiar names in 
the installed libs. (That having been said, Qt is used only in the 
menus AFAIK :-))


Thanks,

___
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

At least, it would be convenient to reap the benefits of QML: HW 
acceleration, for example.


I personally don't care for QML. I would prefer to write everything in 
C++. But that's me. If there was a "no-QML-Quick-API" I'd be so much 
happy. No more gluing code and properties and questions like this: 
https://stackoverflow.com/questions/66618613/qml-c-classes-with-bring-your-own-component
I could just use what I know: C++... The talk Volker linked in this 
thread talks a lot about "working easily with your designers". But I'm 
just me... So the team point is moot. I also don't have a background as 
frontend engineer, so I never bothered to learn JS. I guess it's 
implicit that this is another advantage of QML. Just take the armies of 
frontend devs that exist in the web design market and employ them on GUI 
applications, cheaper than a C++ programmer. Likewise, that sure is a 
reason of why Electron and web backends on JS are so popular (and the 
results so disastrous, sometimes). Some seem to agree with me: 
https://github.com/uwerat/qskinny


But I think the "dream" is the same feature set as QWidgets as Qt Quick 
Controls. And some things to make desktop usage actually decent, like 
native dialogues and especially menus. So that on Macs the menu goes to 
the top bar (also on some GNU/Linux graphical configurations), etc etc. 
When I look at frameworks from like the .net ecosystem, which is growing 
so fast, I see exactly that. Practical example: https://avaloniaui.net/ 
is totally rendered with SKIA#, but there is 
http://reference.avaloniaui.net/api/Avalonia.Controls/NativeMenu/. Also, 
allowing the window to resize without it glitching all over, and other 
desktop/productivity things.


Or, in reverse, if the RHI backend for QWidgets really comes to life, 
and QWidgets keeps receiving some love to be up standard with the latest 
OSes, and receive a public RHI Painter API instead of QOpenGLWidget, and 
look decent on hi-dpi, that's a winning product right there. In my 
opinion, anyway...


That said, I wouldn't support scrapping what's already done. Just 
improving it. Like the native look and feel in QML actually going 
somewhere, and having a feature-equivalent set to QWidgets for desktop 
work.


Rui

Em 21/04/2021 16:48, Giuseppe D'Angelo via Interest escreveu:

On 21/04/2021 17:42, Jason H wrote:
Personally, I think the exsting QtQuick element should be scrapped 
and just focus on QML versions of the existing Widget functionality. 
I love the QML syntax, hate that it's not just a layer on top of 
widgets.

That said, I still really like both.


Do you mean something like this

https://github.com/KDAB/DeclarativeWidgets

or actually reimplementing the widgets themselves?

Thanks,


___
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

2021-04-21 Thread Giuseppe D'Angelo via Interest


On 21/04/2021 16:10, Rui Oliveira wrote:

Black Mesa Source?! Now that's an interesting one haha!



Yep, https://steamdb.info/depot/362894/ shows some familiar names in the 
installed libs. (That having been said, Qt is used only in the menus 
AFAIK :-))


Thanks,
--
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

2021-04-21 Thread Giuseppe D'Angelo via Interest


On 21/04/2021 17:42, Jason H wrote:
Personally, I think the exsting QtQuick element should be scrapped and 
just focus on QML versions of the existing Widget functionality. I love 
the QML syntax, hate that it's not just a layer on top of widgets.

That said, I still really like both.


Do you mean something like this

https://github.com/KDAB/DeclarativeWidgets

or actually reimplementing the widgets themselves?

Thanks,

--
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

2021-04-21 Thread Jason H

You probably won't  -- it's too new. Unless you call automotive Infotainment consoles success stories.

The lack of proper QtQuick Controls (v2) held it back for a while.

Personally, I think the exsting QtQuick element should be scrapped and just focus on QML versions of the existing Widget functionality. I love the QML syntax, hate that it's not just a layer on top of widgets.

That said, I still really like both.

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

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-past-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 <interest-boun...@qt-project.org> on behalf of eric.fedosej...@gmail.com <eric.fedosej...@gmail.com>
Date: Wednesday, April 21, 2021 at 8:37 AM
To: interest@qt-project.org <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 <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

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

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

2021-04-21 Thread 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 dont get lost when using it on
mobile, Mac OS or Windows it doesnt 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 
 <mailto:godbo...@dimonoff.com> godbo...@dimonoff.com

 <https://www.dimonoff.com/> 

 <https://www.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>
mailto:eric.fedosej...@gmail.com> >
Date: Wednesday, April 21, 2021 at 8:37 AM
To: interest@qt-project.org <mailto: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 <mailto: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


Hey Giuseppe, and discussion list!

I did watch all of those. In fact, my original post cites you directly, 
from a talk I believe to have happened in that event also.


Black Mesa Source?! Now that's an interesting one haha!

Anyway, some good information that I got here. Good to see someone from 
the Qt company acknowledge widgets, and that QML for the desktop app 
still needs some baking.


I'm still quite divided. I'm more inclined to widgets at this point, but 
it starts to look as the wrong bet... I guess we're at an interesting 
"middle" point, which is a bit weird.


Anyway, if the community in this mailing list wants to continue the 
discussion on these two technologies for the desktop, I welcome them.


If you want to discuss another things, change the subject title, because 
I get exited when I see answers to my post, which then aren't.


Rui

Em 21/04/2021 14:45, Giuseppe D'Angelo via Interest escreveu:

On 21/04/2021 14:37, eric.fedosej...@gmail.com wrote:
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.


Well the question was about embedded :)

I'm not sure where to find QML on desktop stories, there's however a 
showroom https://showroom.qt.io/ where people can leave links to their 
applications.


These days you'll find QML in a bunch of a desktop applications, from 
Autodesk's to Zoom to Musiscore to VLC-next to Black Mesa Source. 
There's been a few  interesting talks at the past Qt Desktop Days 
(about Scrite, VLC, KDE and so on; check out the videos, they're all 
on Youtube) and some customer showcases at the past (in person) Qt 
World Summits.


Hope this helps,

___
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

2021-04-21 Thread Giuseppe D'Angelo via Interest


On 21/04/2021 14:37, eric.fedosej...@gmail.com wrote:

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.


Well the question was about embedded :)

I'm not sure where to find QML on desktop stories, there's however a 
showroom https://showroom.qt.io/ where people can leave links to their 
applications.


These days you'll find QML in a bunch of a desktop applications, from 
Autodesk's to Zoom to Musiscore to VLC-next to Black Mesa Source. 
There's been a few  interesting talks at the past Qt Desktop Days (about 
Scrite, VLC, KDE and so on; check out the videos, they're all on 
Youtube) and some customer showcases at the past (in person) Qt World 
Summits.


Hope this helps,
--
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

2021-04-21 Thread Jérôme Godbout

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-past-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<mailto:godbo...@dimonoff.com>
[signature_1674119260]<https://www.dimonoff.com/>
dimonoff.com<https://www.dimonoff.com/>
1015 Avenue Wilfrid-Pelletier,
Québec, QC G1W 0C4, 4e étage

From: Interest  on behalf of 
eric.fedosej...@gmail.com 
Date: Wednesday, April 21, 2021 at 8:37 AM
To: 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  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

2021-04-21 Thread 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] Guide me through the Qt offerings for GUIs



On 4/21/2021 7:17 AM, Vlad Stelmahovsky wrote:



On Wed, Apr 21, 2021 at 1:50 PM Roland Hughes 
mailto:rol...@logikalsolutions.com>> wrote:



On 4/21/2021 6:36 AM, Vlad Stelmahovsky wrote:

Using Electron has nothing to do with licensing issues. The issue
is common programming knowledge level is going down when
programmers paradise promised for newcomers: learn HTML
programming language (sic!) and you are rich
btw, is Electron licensed for use in medical devices?


The professional sound equipment company moved from Qt to Electron
because of licensing. They already had all of the C++ Qt
developers. They had to learn how to use Electron.


I have experience with a musicians related company, which just bought 
a license and that's it. no whining and excuses. they just have a real 
picture of their need and did what then have to do


We shall see. This company converted a very large installed base from Qt 
during the pandemic shutdown because of the licensing. They are a big 
name in professional sound and have quite a number of products. They 
make stuff for concert halls, high end theaters, and professional 
recording studios.


Personally I thought their code base was too extensive to ever leave. 
They bit the bullet.


Judging from the influx in the CopperSpice world, a lot of companies 
with projects large and small are biting the bullet.


Best regards,


--
Best regards,
Vlad


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

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

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

2021-04-21 Thread Vlad Stelmahovsky

On Wed, Apr 21, 2021 at 1:50 PM Roland Hughes 
wrote:

>
> On 4/21/2021 6:36 AM, Vlad Stelmahovsky wrote:
>
> Using Electron has nothing to do with licensing issues. The issue is
> common programming knowledge level is going down when programmers paradise
> promised for newcomers: learn HTML programming language (sic!) and you are
> rich
> btw, is Electron licensed for use in medical devices?
>
>
> The professional sound equipment company moved from Qt to Electron because
> of licensing. They already had all of the C++ Qt developers. They had to
> learn how to use Electron.
>
>
> I have experience with a musicians related company, which just bought a
license and that's it. no whining and excuses. they just have a real
picture of their need and did what then have to do

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

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



On 4/20/2021 4:35 PM, Alexey Rusakov wrote:

Am I the only one to feel that Roland monopolises the mailing list again,
after a couple of years?


I'm sorry you feel that way. You can join the growing chorus to have 
Giuseppe D'Angelo placed on 18 month forced hibernation due to 
reprehensible behavior. His personal attacks and lashing out at people 
aren't adding anything to the conversation.


Given all of the graphing the OP is going to be doing with their 
implementation they are going to run headlong into the 
single-thread-i-ness of the main event loop. I ran into it with an 
embedded system where real-time live update graphing from a database had 
to be performed.  Setting up something for them to see that is a lot of 
work.


FeatherPad is in Ubuntu (and probably other distros) so with minimal 
effort someone can see the monkey pile effect on the single-thread-i-ness.


The OP asked a high level question which means that high level 
discussions about low level problems need to happen. I followed the link 
he provided and looked at the application type he wants to work on. If 
he doesn't design around the low level architectural issues 
(single-thread-i-ness of main event loop) he is going to have issues.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

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

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

On 4/21/2021 6:36 AM, Vlad Stelmahovsky wrote:
Using Electron has nothing to do with licensing issues. The issue is
common programming knowledge level is going down when programmers
paradise promised for newcomers: learn HTML programming language
(sic!) and you are rich

btw, is Electron licensed for use in medical devices?

The professional sound equipment company moved from Qt to Electron
because of licensing. They already had all of the C++ Qt developers.
They had to learn how to use Electron.

The "Explore this computer" app for Intel made the same move for the
same reason. A good number of KIOSK applications made the same move for
the same reason.

As to the licensing, if you can sufficiently distance the UI from the
code which must be deterministic, you can get away with a lot. There is
just a __lot__ of paperwork for RISK justification. I got a call from a
researcher/doctor touting the Johns Hopkins credentials wanting me to
work on a post-op patient monitor they were going to hook directly to a
Windows 10 desktop sans an intervening control unit. No, I did not take
the gig.

On Wed, Apr 21, 2021 at 1:30 PM Roland Hughes
mailto:rol...@logikalsolutions.com>> wrote:

LOL,

I never said it wasn't. I said phones and John Deere. My point was
this:

>That tiny subset on the Web site doesn't scratch the surface.

Of course the total number of embedded systems using Qt of any
flavor is going down as much of the market is moving to Electron
and other libraries given the licensing issues.

Automotive is a tiny subset of where Qt is historically used.

On 4/21/2021 6:26 AM, Vlad Stelmahovsky wrote:

With these numbers are you trying to convince me that QML is not
used in embedded? or what?

On Wed, Apr 21, 2021 at 1:21 PM Roland Hughes
mailto:rol...@logikalsolutions.com>> wrote:

On 4/21/2021 12:14 AM, Vlad Stelmahovsky wrote:

On Tue, Apr 20, 2021 at 3:13 PM Roland Hughes
mailto:rol...@logikalsolutions.com>> wrote:

On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:

On 18/04/2021 14:50, Roland Hughes wrote:

It's completely true. That tiny subset on the Web site
doesn't scratch the surface. It certainly doesn't
encompass my customer base and I haven't heard anyone
pipe up on here using QML for anything non-significant
that wasn't phones or John Deere. Even the one medical
device we have been told about on this list has said you
can't do anything in QML, only painting.

its not true. f.ex all Volvo cars from 2015 until this year
using QML-based apps in their infotainment system

https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2015=12

https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2016=12

https://www.media.volvocars.com/global/en-gb/media/pressreleases/172301/volvo-cars-reports-record-sales-of-503127-in-2015

https://www.media.volvocars.com/global/en-gb/media/pressreleases/204359/volvo-cars-reports-operating-profit-of-sek11bn-in-2016

2015 70,047 U.S. 503,127 global
2016 82,724 U.S. 534,332 global

I guess we need to have some common definition of subset and
surface?

The patient monitors that use Qt sans QML sell millions of
units. Granted, they only cost thousands, not tens of
thousands. The one I worked on that was released some time in
2015 reportedly sold 7 million units in its first few years.

--
Roland Hughes, President

Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com

https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

--
Best regards,

Vlad

--
Roland Hughes, President

Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com

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

2021-04-21 Thread Vlad Stelmahovsky

Using Electron has nothing to do with licensing issues. The issue is common
programming knowledge level is going down when programmers paradise
promised for newcomers: learn HTML programming language (sic!) and you are
rich
btw, is Electron licensed for use in medical devices?

On Wed, Apr 21, 2021 at 1:30 PM Roland Hughes 
wrote:

> LOL,
>
> I never said it wasn't. I said phones and John Deere. My point was this:
>
> >That tiny subset on the Web site doesn't scratch the surface.
>
> Of course the total number of embedded systems using Qt of any flavor is
> going down as much of the market is moving to Electron and other libraries
> given the licensing issues.
>
> Automotive is a tiny subset of where Qt is historically used.
> On 4/21/2021 6:26 AM, Vlad Stelmahovsky wrote:
>
> With these numbers are you trying to convince me that QML is not used in
> embedded? or what?
>
> On Wed, Apr 21, 2021 at 1:21 PM Roland Hughes 
> wrote:
>
>>
>> On 4/21/2021 12:14 AM, Vlad Stelmahovsky wrote:
>>
>>
>>
>> On Tue, Apr 20, 2021 at 3:13 PM Roland Hughes <
>> rol...@logikalsolutions.com> wrote:
>>
>>>
>>> On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:
>>>
>>> On 18/04/2021 14:50, Roland Hughes wrote:
>>>
>>> It's completely true. That tiny subset on the Web site doesn't scratch
>>> the surface. It certainly doesn't encompass my customer base and I haven't
>>> heard anyone pipe up on here using QML for anything non-significant that
>>> wasn't phones or John Deere. Even the one medical device we have been told
>>> about on this list has said you can't do anything in QML, only painting.
>>>
>>
>> its not true. f.ex all Volvo cars from 2015 until this year using
>> QML-based apps in their infotainment system
>>
>>
>> https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2015=12
>>
>>
>> https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2016=12
>>
>>
>> https://www.media.volvocars.com/global/en-gb/media/pressreleases/172301/volvo-cars-reports-record-sales-of-503127-in-2015
>>
>>
>> https://www.media.volvocars.com/global/en-gb/media/pressreleases/204359/volvo-cars-reports-operating-profit-of-sek11bn-in-2016
>>
>>
>> 2015   70,047  U.S.   503,127 global
>> 2016   82,724  U.S.   534,332 global
>>
>> I guess we need to have some common definition of subset and surface?
>>
>> The patient monitors that use Qt sans QML sell millions of units.
>> Granted, they only cost thousands, not tens of thousands. The one I worked
>> on that was released some time in 2015 reportedly sold 7 million units in
>> its first few years.
>>
>> --
>> Roland Hughes, President
>> Logikal Solutions
>> (630)-205-1593
>> https://theminimumyouneedtoknow.comhttps://infiniteexposure.nethttps://lesedi.ushttps://johnsmith-book.comhttps://logikalblog.comhttps://interestingauthors.com/blog
>>
>>
>
> --
> Best regards,
> Vlad
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593
> https://theminimumyouneedtoknow.comhttps://infiniteexposure.nethttps://lesedi.ushttps://johnsmith-book.comhttps://logikalblog.comhttps://interestingauthors.com/blog
>
>

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

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

LOL,

I never said it wasn't. I said phones and John Deere. My point was this:

>That tiny subset on the Web site doesn't scratch the surface.

Of course the total number of embedded systems using Qt of any flavor is
going down as much of the market is moving to Electron and other
libraries given the licensing issues.

Automotive is a tiny subset of where Qt is historically used.

On 4/21/2021 6:26 AM, Vlad Stelmahovsky wrote:
With these numbers are you trying to convince me that QML is not used
in embedded? or what?

On Wed, Apr 21, 2021 at 1:21 PM Roland Hughes
mailto:rol...@logikalsolutions.com>> wrote:

On 4/21/2021 12:14 AM, Vlad Stelmahovsky wrote:

On Tue, Apr 20, 2021 at 3:13 PM Roland Hughes
mailto:rol...@logikalsolutions.com>> wrote:

On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:

On 18/04/2021 14:50, Roland Hughes wrote:

It's completely true. That tiny subset on the Web site
doesn't scratch the surface. It certainly doesn't encompass
my customer base and I haven't heard anyone pipe up on here
using QML for anything non-significant that wasn't phones or
John Deere. Even the one medical device we have been told
about on this list has said you can't do anything in QML,
only painting.

its not true. f.ex all Volvo cars from 2015 until this year using
QML-based apps in their infotainment system

https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2015=12

https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2016=12

https://www.media.volvocars.com/global/en-gb/media/pressreleases/172301/volvo-cars-reports-record-sales-of-503127-in-2015

https://www.media.volvocars.com/global/en-gb/media/pressreleases/204359/volvo-cars-reports-operating-profit-of-sek11bn-in-2016

2015 70,047 U.S. 503,127 global
2016 82,724 U.S. 534,332 global

I guess we need to have some common definition of subset and surface?

The patient monitors that use Qt sans QML sell millions of units.
Granted, they only cost thousands, not tens of thousands. The one
I worked on that was released some time in 2015 reportedly sold 7
million units in its first few years.

--
Roland Hughes, President

Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

--
Best regards,
Vlad

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

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

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

2021-04-21 Thread Vlad Stelmahovsky

With these numbers are you trying to convince me that QML is not used in
embedded? or what?

On Wed, Apr 21, 2021 at 1:21 PM Roland Hughes 
wrote:

>
> On 4/21/2021 12:14 AM, Vlad Stelmahovsky wrote:
>
>
>
> On Tue, Apr 20, 2021 at 3:13 PM Roland Hughes 
> wrote:
>
>>
>> On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:
>>
>> On 18/04/2021 14:50, Roland Hughes wrote:
>>
>> It's completely true. That tiny subset on the Web site doesn't scratch
>> the surface. It certainly doesn't encompass my customer base and I haven't
>> heard anyone pipe up on here using QML for anything non-significant that
>> wasn't phones or John Deere. Even the one medical device we have been told
>> about on this list has said you can't do anything in QML, only painting.
>>
>
> its not true. f.ex all Volvo cars from 2015 until this year using
> QML-based apps in their infotainment system
>
>
> https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2015=12
>
>
> https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2016=12
>
>
> https://www.media.volvocars.com/global/en-gb/media/pressreleases/172301/volvo-cars-reports-record-sales-of-503127-in-2015
>
>
> https://www.media.volvocars.com/global/en-gb/media/pressreleases/204359/volvo-cars-reports-operating-profit-of-sek11bn-in-2016
>
>
> 2015   70,047  U.S.   503,127 global
> 2016   82,724  U.S.   534,332 global
>
> I guess we need to have some common definition of subset and surface?
>
> The patient monitors that use Qt sans QML sell millions of units. Granted,
> they only cost thousands, not tens of thousands. The one I worked on that
> was released some time in 2015 reportedly sold 7 million units in its first
> few years.
>
> --
> Roland Hughes, President
> Logikal Solutions
> (630)-205-1593
> https://theminimumyouneedtoknow.comhttps://infiniteexposure.nethttps://lesedi.ushttps://johnsmith-book.comhttps://logikalblog.comhttps://interestingauthors.com/blog
>
>

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

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



On 4/21/2021 12:14 AM, Vlad Stelmahovsky wrote:



On Tue, Apr 20, 2021 at 3:13 PM Roland Hughes 
mailto:rol...@logikalsolutions.com>> wrote:



On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:

On 18/04/2021 14:50, Roland Hughes wrote:

It's completely true. That tiny subset on the Web site doesn't
scratch the surface. It certainly doesn't encompass my customer
base and I haven't heard anyone pipe up on here using QML for
anything non-significant that wasn't phones or John Deere. Even
the one medical device we have been told about on this list has
said you can't do anything in QML, only painting.


its not true. f.ex all Volvo cars from 2015 until this year using 
QML-based apps in their infotainment system

https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2015=12

https://www.media.volvocars.com/us/en-us/corporate/sales-volumes?year=2016=12

https://www.media.volvocars.com/global/en-gb/media/pressreleases/172301/volvo-cars-reports-record-sales-of-503127-in-2015

https://www.media.volvocars.com/global/en-gb/media/pressreleases/204359/volvo-cars-reports-operating-profit-of-sek11bn-in-2016


2015   70,047  U.S.   503,127 global
2016   82,724  U.S.   534,332 global

I guess we need to have some common definition of subset and surface?

The patient monitors that use Qt sans QML sell millions of units. 
Granted, they only cost thousands, not tens of thousands. The one I 
worked on that was released some time in 2015 reportedly sold 7 million 
units in its first few years.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

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

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

2021-04-21 Thread Nuno Santos

Rui,

You need to extend QQuickItem and create your scene graph.

Open QtCreator and search for scene graph examples. Take a special look to 
"Scene Graph - Custom Geometry”

Best,

Nuno

> On 15 Apr 2021, at 11:25, Rui Oliveira  wrote:
> 
> Hey,
> As per the title implies, I would like some comments on the GUI offerings Qt 
> currently has. 
> 
> I'll share my own assessments and needs, and I'd like very much to hear your 
> comments.
> 
> So:
> 
> 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 (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". Even KDE moved on from them... 
> And I understand that's not where the money is for now... Still, I'd like 
> some comments.
> 
> Now, QML.
> 
> Slide 25 of the same talk mentions native desktop styling for QQC2. I can't 
> find documentations on this. Are they already available yet? Also, in the 
> previous slide, "Planned in Qt 6.x: C++ API for Qt Quick elements". Does this 
> mean Qt Quick *without* QML? 
> 
> Also, in QML it seems to be very hard to have anything native-looking. I 
> looked at Qt Labs Platform [2] 
>  and things like the right 
> click menu aren't available on Windows, for example. Are there plans to 
> expand this? 
> 
> 
> 
> Either way, I'm quite divided. I'd like to hear your thoughts and 
> recommendations. 
> 
> 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.
> 
> 
> 
> Thank you for your time,
> Rui
> 
> 
> 
> For those reading in plain text:
> [1] https://www.qtdesktopdays.com/wp-content/uploads/2020/09/keynote.pdf 
>  
> [2] https://doc.qt.io/qt-6/qtlabsplatform-index.html 
> 
> ___
> 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

2021-04-21 Thread Jason H

I am ambidextrous when it comes to Quick and Widgets.
If you want it to look modern, use Quick. If you want more business-retro, use 
widgets. Widgets still has better UX, but it is not as bad as it used to be. 

You can do what you want in Quick, with C++ QQuickImageProvider subclass.  It's 
a little head-scratchy at first, but it works well. Using an Image, I pass the 
data in via source property URL and generate the image for that data. (My stuff 
doesn't update frequently, so I send all the data. You'll probably allocate a 
resources and update the data separately)






> Sent: Thursday, April 15, 2021 at 12:25 PM
> From: "Rui Oliveira" 
> To: "Qt Interest" 
> Subject: [Interest] Guide me through the Qt offerings for GUIs
>
> Hey,
> 
> As per the title implies, I would like some comments on the GUI 
> offerings Qt currently has.
> 
> I'll share my own assessments and needs, and I'd like very much to hear 
> your comments.
> 
> So:
> 
> 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 (slides [1] 
> <https://www.qtdesktopdays.com/wp-content/uploads/2020/09/keynote.pdf>), 
> 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". Even KDE moved on from 
> them... And I understand that's not where the money is for now... Still, 
> I'd like some comments.
> 
> Now, QML.
> 
> Slide 25 of the same talk mentions native desktop styling for QQC2. I 
> can't find documentations on this. Are they already available yet? Also, 
> in the previous slide, "Planned in Qt 6.x: C++ API for Qt Quick 
> elements". Does this mean Qt Quick *without* QML?
> 
> Also, in QML it seems to be very hard to have anything native-looking. I 
> looked at Qt Labs Platform [2] 
> <https://doc.qt.io/qt-6/qtlabsplatform-index.html> and things like the 
> right click menu aren't available on Windows, for example. Are there 
> plans to expand this?
> 
> 
> Either way, I'm quite divided. I'd like to hear your thoughts and 
> recommendations.
> 
> 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.
> 
> 
> Thank you for your time,
> Rui
> 
> 
> For those reading in plain text:
> [1] https://www.qtdesktopdays.com/wp-content/uploads/2020/09/keynote.pdf
> [2] https://doc.qt.io/qt-6/qtlabsplatform-index.html
> 
> ___
> 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

2021-04-20 Thread Vlad Stelmahovsky

On Tue, Apr 20, 2021 at 3:13 PM Roland Hughes 
wrote:

>
> On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:
>
> On 18/04/2021 14:50, Roland Hughes wrote:
>
> It's completely true. That tiny subset on the Web site doesn't scratch the
> surface. It certainly doesn't encompass my customer base and I haven't
> heard anyone pipe up on here using QML for anything non-significant that
> wasn't phones or John Deere. Even the one medical device we have been told
> about on this list has said you can't do anything in QML, only painting.
>

its not true. f.ex all Volvo cars from 2015 until this year using QML-based
apps in their infotainment system


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

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



On 4/20/2021 4:35 PM, Kyle Edwards wrote:

On 4/20/21 10:18 AM, Matthew Woehlke wrote:

It's well known that you*have*  to highlight the whole file, at least
to the current position, for accurate ("perfect") highlighting.

If I understand correctly, you have to*analyze*  the whole file, but not
necessarily*highlight*  it. (Though, once you've completed the analysis,
highlighting it is a relatively trivial step, and skipping it for
non-visible parts of the file may not yield a whole lot of savings.)


Mostly correct Kyle.

With the structure/design of QPlainTextEdit you have to *analyze* in the 
single-thread-i-ness main event loop. So, when someone opens and editor 
with 4-7 large source files opened in tabs, the one you really need, the 
last one, is jammed up in the single-thread-i-ness main event loop 
behind the other tabs you cannot see because they were in first load order.


QPlainTextEdit forces you to *highlight* during *analyze* using regular 
expressions . . . assuming you use it as designed.


As Matthew has pointed out, KATE doesn't do this. Last I looked at the 
code it creates worker threads for everything.


One note though. KATE (or katepart as Mathew prefers) has to be using 
more than just regular expressions because it actually highlighted the 
initializer list correctly.


Thanks for participating in the conversation.

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://lesedi.us
https://johnsmith-book.com
https://logikalblog.com
https://interestingauthors.com/blog

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

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



On 4/20/2021 3:53 PM, Matthew Woehlke wrote:
TL;DR: We agree that QPlainTextEdit is "bad" (see below for definition 
of "bad"). We (apparently) disagree on what's required to correctly 
parse a file for syntax highlighting.


On 20/04/2021 15.03, Roland Hughes wrote:

On 4/20/21 9:18 AM, Matthew Woehlke wrote:

On 20/04/2021 09.10, Roland Hughes wrote:
Close on the heels of that "Why are they highlighting the whole 
thing?" when you only need the currently visible lines and possibly 
a screen up/down. Open up a 10,000 line source file in editors 
using Scintilla or the Electron JavaScript based things, or even 
GUI Emacs even on an i5-gen3 and you are almost instantly taken to 
the line you were on with perfect syntax highlighting.


Frankly, I am skeptical. At best I think you are misrepresenting the 
problem.


It's well known that you *have* to highlight the whole file, at 
least to the current position, for accurate ("perfect") 
highlighting. At least in the general case. There may be some files 
and/or syntaxes for which that it not the case, but vim has had 
partial highlighting for almost forever, and I've seen it drop the 
ball on plenty of occasions, because something earlier in the file 
changes correct highlighting for the visible part.


No, it's not well known or even accurate. IF one is taking a student 
type approach and attempting to use regular expressions all mushed 
together as one nasty bundle, the statement is true.


Let's look at three editors that seem to do it right.

KATE


Well, I find it ironic you include Kate (which really means katepart, 
i.e. Kate, KWrite, KDevelop and maybe others), since AFAIK that *does* 
highlight the whole file. It also *definitely* uses regular 
expressions (and Qt's RE engine, AFAIK), although it also uses a mix 
of other stuff optimized for common cases.


But maybe we're talking about different things. When I say 
"highlight", what I really mean is "syntax parse". Trying to *render* 
the entirety of a large file is, indeed, madness.


Yes. It isn't *highlighted* until it is *rendered*.



...and see my previous comments; QPlainTextEdit was never meant for 
that. Frankly, if you are using QPlainTextEdit to hold more than 
~16KiB of text... stop that.


There are a lot of little editors out there using QPlainTextEdit and one 
big mass of regular expressions where each line of the regular 
expression requires yet another pass through the text.




Of course, this may all be happening in a separate thread, and it 
isn't using QPlainTextEdit; katepart I'm almost certain has its own 
structures for managing state and keeping track of breaking the text 
into highlighted chunks.

Last I looked at KATE source, everything is happening in worker threads.



Text isn't a stream.


Katepart would disagree. Although the way of *expressing* how to 
handle line ends is different from handling other tokens, they are, at 
the end of the day, handled almost exactly the same as any other 
token. The difference is mainly that the rule to detect a newline is 
built-in and uses different syntax to express how said rule should 
modify the context stack.


No. Line endings are not "just another token." Linux always gets in 
trouble thinking like that. They are the record terminators on platforms 
intelligent enough to understand records. You have to get above the x86 
to experience that.





There is no magic that allows you to begin parsing in the middle of a 
file. If you do that, you will get something that is *wrong*. 
(Admittedly, not always, but sometimes, and vim is proof.)


Moreover, if you insist on expecting "text" to be structured in nice, 
neat records delimited by "line breaks", you are going to be in for a 
rude awakening when someone decides to try to open a "condensed" XML, 
JS, or whatnot. (Katepart *mostly* handles these gracefully. By 
default, it gives up at IIRC 1024 characters and forces a line break. 
You can raise that limit... admittedly, at your own peril. In a sense, 
katepart can get bogged down due to taking the approach you are 
*recommending*.)



It's the correct approach.

Despite what people say, it's almost always LF CR in a file.


This is trivially disproven by `unix2dos`. Or looking at most text 
files created on a Windows machine.

Not really, no.


 $ echo 'Hello, world!' | unix2dos | od -t x1
 000 48 65 6c 6c 6f 2c 20 77 6f 72 6c 64 21 0d 0a

That's a CR (0x0d, '\r') followed by a LF (0x0a, '\n').

Again, the ASCII world was much larger than the 
x86-wanna-be-a-real-computer-one-day-when-I-grow-up universe. Most early 
DOS versions, in particular the version of DOS shipping stock on the AST 
Premium 286, actually wrote LF CR. Some software wrote what you posted 
above, but not most of it. The error was introduced by people saying 
"carriage return linefeed" and developers not knowing any better. Most 
DOS (and GUI DOS) applications got modified to only require the two 
characters, accepting them in any order. The reason, if

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

2021-04-20 Thread Matthew Woehlke

TL;DR: We agree that QPlainTextEdit is "bad" (see below for definition 
of "bad"). We (apparently) disagree on what's required to correctly 
parse a file for syntax highlighting.


On 20/04/2021 15.03, Roland Hughes wrote:

On 4/20/21 9:18 AM, Matthew Woehlke wrote:

On 20/04/2021 09.10, Roland Hughes wrote:
Close on the heels of that "Why are they highlighting the whole 
thing?" when you only need the currently visible lines and possibly a 
screen up/down. Open up a 10,000 line source file in editors using 
Scintilla or the Electron JavaScript based things, or even GUI Emacs 
even on an i5-gen3 and you are almost instantly taken to the line you 
were on with perfect syntax highlighting.


Frankly, I am skeptical. At best I think you are misrepresenting the 
problem.


It's well known that you *have* to highlight the whole file, at least 
to the current position, for accurate ("perfect") highlighting. At 
least in the general case. There may be some files and/or syntaxes for 
which that it not the case, but vim has had partial highlighting for 
almost forever, and I've seen it drop the ball on plenty of occasions, 
because something earlier in the file changes correct highlighting for 
the visible part.


No, it's not well known or even accurate. IF one is taking a student 
type approach and attempting to use regular expressions all mushed 
together as one nasty bundle, the statement is true.


Let's look at three editors that seem to do it right.

KATE


Well, I find it ironic you include Kate (which really means katepart, 
i.e. Kate, KWrite, KDevelop and maybe others), since AFAIK that *does* 
highlight the whole file. It also *definitely* uses regular expressions 
(and Qt's RE engine, AFAIK), although it also uses a mix of other stuff 
optimized for common cases.


But maybe we're talking about different things. When I say "highlight", 
what I really mean is "syntax parse". Trying to *render* the entirety of 
a large file is, indeed, madness.


...and see my previous comments; QPlainTextEdit was never meant for 
that. Frankly, if you are using QPlainTextEdit to hold more than ~16KiB 
of text... stop that.



Now lets pick on Featherpad trying to do it "the Qt way"


I'm not sure what you consider "the Qt way". IMHO, katepart *is* "the Qt 
way". It's the way (well, *a* way, anyway) any sane person using Qt 
would implement a text editor that's intended to be usable with large 
documents.


To highlight only the visible subset one simply needs to know the outer 
most enclosing boundaries.


Well... yes. And no. The problem is, in order to know those boundaries, 
you have to look at *everything* in them. You can't just, for instance, 
see a '{' and decide you can skip everything until the next '}', because 
that brace might be inside a string literal.


I haven't looked at katepart's guts enough to know how they work or if 
they try to employ any clever optimizations. I *have* written 
highlighters for katepart, however, and knowing what those look like, 
I'm far from convinced that any such optimizations are implemented, or 
indeed, even possible. Katepart's highlighting is based on a context 
stack, with each detection rule potentially altering that stack. You 
can't just skip rules, because doing so means the wrong rule might end 
up gobbling some token, which will lead you into a wrong stack state, 
and things will just get worse from there.


Of course, this may all be happening in a separate thread, and it isn't 
using QPlainTextEdit; katepart I'm almost certain has its own structures 
for managing state and keeping track of breaking the text into 
highlighted chunks.



Text isn't a stream.


Katepart would disagree. Although the way of *expressing* how to handle 
line ends is different from handling other tokens, they are, at the end 
of the day, handled almost exactly the same as any other token. The 
difference is mainly that the rule to detect a newline is built-in and 
uses different syntax to express how said rule should modify the context 
stack.


There is no magic that allows you to begin parsing in the middle of a 
file. If you do that, you will get something that is *wrong*. 
(Admittedly, not always, but sometimes, and vim is proof.)


Moreover, if you insist on expecting "text" to be structured in nice, 
neat records delimited by "line breaks", you are going to be in for a 
rude awakening when someone decides to try to open a "condensed" XML, 
JS, or whatnot. (Katepart *mostly* handles these gracefully. By default, 
it gives up at IIRC 1024 characters and forces a line break. You can 
raise that limit... admittedly, at your own peril. In a sense, katepart 
can get bogged down due to taking the approach you are *recommending*.)



Despite what people say, it's almost always LF CR in a file.


This is trivially disproven by `unix2dos`. Or looking at most text files 
created on a Windows machine.


  $ echo 'Hello, world!' | unix2dos | od -t x1
  000 48 65 6c 6c 6f 2c 20 77 6f 72 6c 64

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



On 4/20/21 9:18 AM, Matthew Woehlke wrote:

On 20/04/2021 09.10, Roland Hughes wrote:
Close on the heels of that "Why are they highlighting the whole 
thing?" when you only need the currently visible lines and possibly a 
screen up/down. Open up a 10,000 line source file in editors using 
Scintilla or the Electron JavaScript based things, or even GUI Emacs 
even on an i5-gen3 and you are almost instantly taken to the line you 
were on with perfect syntax highlighting.


Frankly, I am skeptical. At best I think you are misrepresenting the 
problem.


It's well known that you *have* to highlight the whole file, at least 
to the current position, for accurate ("perfect") highlighting. At 
least in the general case. There may be some files and/or syntaxes for 
which that it not the case, but vim has had partial highlighting for 
almost forever, and I've seen it drop the ball on plenty of occasions, 
because something earlier in the file changes correct highlighting for 
the visible part.


No, it's not well known or even accurate. IF one is taking a student 
type approach and attempting to use regular expressions all mushed 
together as one nasty bundle, the statement is true.


Let's look at three editors that seem to do it right.

Emacs

https://www.logikalsolutions.com/wordpress/wp-content/uploads/2021/04/emacs-cpp.png
https://www.logikalsolutions.com/wordpress/wp-content/uploads/2021/04/emacs-h.png

Sublime

https://www.logikalsolutions.com/wordpress/wp-content/uploads/2021/04/sublime-cpp.png
https://www.logikalsolutions.com/wordpress/wp-content/uploads/2021/04/sublime-h.png

KATE

https://www.logikalsolutions.com/wordpress/wp-content/uploads/2021/04/kate-cpp.png
https://www.logikalsolutions.com/wordpress/wp-content/uploads/2021/04/kate-h.png

While some may/may not know about Qt classes, they all know about 
initializer lists.


Now lets pick on Featherpad trying to do it "the Qt way"

Featherpad

https://www.logikalsolutions.com/wordpress/wp-content/uploads/2021/04/featherpad-cpp.png
https://www.logikalsolutions.com/wordpress/wp-content/uploads/2021/04/featherpad-h.png

Obviously not right. Probably passable for many, but as language syntax 
increases in complexity both accuracy and performance degrade.


To highlight only the visible subset one simply needs to know the outer 
most enclosing boundaries. We had to do this stuff back when I was 
working on a Masters in the 1980s. Instructor for compiler design made 
us do this stuff in both Assembler and Algol (don't ask!)


There are multiple architectural problems with QPlainTextEdit. Most 
notably, it completely abandoned "plain text." Instead we have graphics 
components wedged in with private classes one can't get to and in 
general trying to stuff everything into a single class with much of it 
locked away. Adding insult to injury is the single-thread-i-ness of main 
event loop.


Text isn't a stream. It isn't a blob and it isn't a byte array. A text 
file is a sequence of variable length text records. Each record has an 
end-of-record marker depending on the OS and disk storage method. Some 
will have 0x0A (linefeed); others 0x0A 0X0D (linefeed carriage return); 
a very rare few will have 0x0D 0x0A (Carriage return linefeed) [Despite 
what people say, it's almost always LF CR in a file. The CR LF sequence 
was used almost exclusively for transmission to remote line printers 
without flow control because you needed to buy time for the print head 
to get to the left margin.]


The last rarity on the original ASCII systems is just 0x0D. I forget 
where that got used most often. (EBCDIC is a completely different can of 
worms)


At any rate, to successfully syntax highlight a narrow window all you 
really need to know is the outermost enclosing scope which gets 
determined during load and stored in a structure.


Well, anyway, QPlainTextEdit tried to mush everything down into one 
layer, at least everything that mattered. The single-thread-i-ness of 
the main event loop causes everything to monkey pile in the event queue 
all waiting their turn to paint.


For a couple hundred lines on a fast machine it is close enough for hand 
grenades. For editing anything of any significance, no.


I feel what's-his-name's pain with Featherpad. Trying to speed things up 
by tweaking the regular expression stuff, always hitting a performance 
wall. Thank God he is only doing a small handful of colors instead of 
the robust syntax highlighting found in Sublime and Emacs. He could be 
looking at ten minute file loads.


At the core of the class is the wrong object. The needed higher level 
objects also aren't there.


A text editor, even a GUI one, is still a line editor.

--
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

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

2021-04-20 Thread Giuseppe D'Angelo via Interest

On 20/04/2021 15:10, Roland Hughes wrote:

On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:

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.
It's completely true. That tiny subset on the Web site doesn't scratch
the surface.

So there's even *MORE* QML used in embedded than what's advertised on
TQC's website? That's great news!

It certainly doesn't encompass my customer base and I
haven't heard anyone pipe up on here using QML for anything
non-significant that wasn't phones or John Deere.

Ah ok, since *you* never saw QML used on embedded projects, then it
doesn't exist. How silly of me assuming otherwise.

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.

You need to actually learn processor history or at least do some
research before you speak.

You need to learn to use Google before you speak.

Or actually, better not: last time you used Google you fell for *two*
April fools' blog posts, claiming they were true. For that, we haven't
received apologies yet. So who tells us that it's different this time?

https://lists.qt-project.org/pipermail/interest/2019-December/034255.html

The 486SX was a marketing quirk. Intel had a high failure rate (low
yield) on the FPU. When a CPU passed DX testing it was sold as a 486DX.
When it failed testing it went down another line where they "cut some
pins" so the chip couldn't communicate with the bad FPU, put an SX on it
and sold scrap at a discount.

This has widely been debunked.

The SXs were introduced to the market _years_ after the introduction of
the DXs. Intel didn't start to have massive production problems all of a
sudden and thus decided to pull this stunt. The SXs were _designed_ to
have the FPU disabled, and their FPU was for this reason ever tested.
The only reason for the introduction of the SX was market segmentation
to compete against AMD.

Here's some links for you, given you seem to able to Google "486 sx
defective" (and leave it in the URLs that you link), but somehow
conveniently IGNORING the first couple of results, even if they include
first-hand accounts of Intel engineers who worked on the 486 that
disprove the whole defective story:

http://www.os2museum.com/wp/lies-damn-lies-and-wikipedia/

By the way, did you notice that the Wikipedia page that YOU linked
doesn't talk about those chips being "defective" DXs?

Because that's a lie, as discussed in the talk page:

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

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.

The API has a ___lot___ to do with this as the dude putting out
featherpad is learning the hard way and every editor developer
attempting to use Qt and only Qt before them. The single-thread-i-ness
hits a hard wall. That's the biggest issue.

That is followed by all of the "why would anyone have done __that__" issues:

like burying the selection active inside a private internal class and
basing it on the difference of cursor position thus making it physically
impossible to follow numerous time honored editor traditions of Mark> . Unless you gut the class and redevelop from scratch
you can't have an N-key key sequence for begin mark and have the editor
class understand a selection has been enabled even though there is zero
cursor difference.

Close on the heels of that "Why are they highlighting the whole thing?"
when you only need the currently visible lines and possibly a screen
up/down. Open up a 10,000 line source file in editors

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

2021-04-20 Thread Kyle Edwards via Interest


On 4/20/21 10:18 AM, Matthew Woehlke wrote:
It's well known that you *have* to highlight the whole file, at least 
to the current position, for accurate ("perfect") highlighting.


If I understand correctly, you have to *analyze* the whole file, but not 
necessarily *highlight* it. (Though, once you've completed the analysis, 
highlighting it is a relatively trivial step, and skipping it for 
non-visible parts of the file may not yield a whole lot of savings.)


Kyle

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

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

2021-04-20 Thread Matthew Woehlke


On 20/04/2021 09.10, Roland Hughes wrote:
Close on the heels of that "Why are they highlighting the whole thing?" 
when you only need the currently visible lines and possibly a screen 
up/down. Open up a 10,000 line source file in editors using Scintilla or 
the Electron JavaScript based things, or even GUI Emacs even on an 
i5-gen3 and you are almost instantly taken to the line you were on with 
perfect syntax highlighting.


Frankly, I am skeptical. At best I think you are misrepresenting the 
problem.


It's well known that you *have* to highlight the whole file, at least to 
the current position, for accurate ("perfect") highlighting. At least in 
the general case. There may be some files and/or syntaxes for which that 
it not the case, but vim has had partial highlighting for almost 
forever, and I've seen it drop the ball on plenty of occasions, because 
something earlier in the file changes correct highlighting for the 
visible part.


That said, Qt definitely does not have a widget that can do a reasonable 
job of syntax highlighting a large file. Katepart, which does a pretty 
good job, is very much its own implementation of a text editor with very 
little high level Qt code involved. (At least that used to be the case; 
I think some of the actual text parsing may have moved *into* Qt *from* 
katepart. Back when I was involved with it, however, it used Qt for text 
rendering and low level input, but I believe all the higher level logic 
for input handling and layouting was reimplemented.)


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

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

2021-04-20 Thread Alexey Rusakov

Am I the only one to feel that Roland monopolises the mailing list again,
after a couple of years?

On Tue, 20 Apr 2021 at 15:11, Roland Hughes 
wrote:

>
> On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:
>
> 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.
>
> It's completely true. That tiny subset on the Web site doesn't scratch the
> surface. It certainly doesn't encompass my customer base and I haven't
> heard anyone pipe up on here using QML for anything non-significant that
> wasn't phones or John Deere. Even the one medical device we have been told
> about on this list has said you can't do anything in QML, only painting.
>
>  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.
>
> You need to actually learn processor history or at least do some research
> before you speak.
>
> https://arstechnica.com/civis/viewtopic.php?t=390388
>
>
> https://books.google.com/books?id=AoKUhNoOys4C=PP19=486sx+defective+fpu=en=X=2ahUKEwj2tL_s6IzwAhXQQc0KHYFnBj8Q6AEwAHoECAAQAg#v=onepage=486sx%20defective%20fpu=false
>
>
> https://www.google.com/books/edition/Blackie_s_Dictionary_of_Computer_Science/P2EtDAAAQBAJ?hl=en=1=486sx+defective+fpu=PR34=frontcover
>
>
> https://www.google.com/books/edition/The_Art_of_Computer_Virus_Research_and_D/XE-ddYF6uhYC?hl=en=1=486sx+defective+fpu=PT296=frontcover
>
>
> https://www.google.com/books/edition/Upgrading_and_Repairing_PCs/E1p2FDL7P5QC?hl=en=1=486sx+defective+fpu=PA123=frontcover
>
> The 486SX was a marketing quirk. Intel had a high failure rate (low yield)
> on the FPU. When a CPU passed DX testing it was sold as a 486DX. When it
> failed testing it went down another line where they "cut some pins" so the
> chip couldn't communicate with the bad FPU, put an SX on it and sold scrap
> at a discount.
>
> The 386SX was a different design. The 486SX was simply unloading 486DX
> junk.
>
>  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.
>
> The API has a ___lot___ to do with this as the dude putting out featherpad
> is learning the hard way and every editor developer attempting to use Qt
> and only Qt before them. The single-thread-i-ness hits a hard wall. That's
> the biggest issue.
>
> That is followed by all of the "why would anyone have done __that__"
> issues:
>
> like burying the selection active inside a private internal class and
> basing it on the difference of cursor position thus making it physically
> impossible to follow numerous time honored editor traditions of  Mark> . Unless you gut the class and redevelop from scratch you
> can't have an N-key key sequence for begin mark and have the editor class
> understand a selection has been enabled even though there is zero cursor
> difference.
>
> Close on the heels of that "Why are they highlighting the whole thing?"
> when you only need the currently visible lines and possibly a screen
> up/down. Open up a 10,000 line source file in editors using Scintilla or
> the Electron JavaScript based things, or even GUI Emacs even on an i5-gen3
> and you are almost instantly taken to the line you were on with perfect
> syntax highlighting. Because QPlainTextEdit has to do everything in the
> main event loop and appears not to understand scope of visibility, it
> starts at the top and works its way down. Bad enough with one file, but try
> having three tabs open all with large files all using regular expressions
> for highlighting in the main event loop.
>
> The underlying graphics API

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