[Interest] Guide me through the Qt offerings for GUIs

Wed Apr 21 19:48:46 CEST 2021

Boas Rui,

> On 21 Apr 2021, at 18:24, Rui Oliveira <ruilvo at hotmail.com> 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 <something> days!
> 
Actually I had a chance to share my story 4 years ago at QtWS17 -> https://www.youtube.com/watch?v=vgBq4dMoI_g <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 <https://www.imaginando.pt/products/drc>
>> www.imaginando.pt/products/frms <https://www.imaginando.pt/products/frms>
>> www.imaginando.pt/products/k7d <https://www.imaginando.pt/products/k7d>
>> www.imaginando.pt/products/dlym <https://www.imaginando.pt/products/dlym>
>> www.imaginando.pt/products/lk <https://www.imaginando.pt/products/lk>
>> www.imaginando.pt/products/tkfx <https://www.imaginando.pt/products/tkfx>
>> www.connectionopen.com <http://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 <ruilvo at hotmail.com <mailto:ruilvo at hotmail.com>> 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 <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 <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/ <https://avaloniaui.net/> is totally rendered with SKIA#, but there is http://reference.avaloniaui.net/api/Avalonia.Controls/NativeMenu/ <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 <https://github.com/KDAB/DeclarativeWidgets> 
>>>> 
>>>> or actually reimplementing the widgets themselves? 
>>>> 
>>>> Thanks, 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Interest mailing list
>>>> Interest at qt-project.org <mailto:Interest at qt-project.org>
>>>> https://lists.qt-project.org/listinfo/interest <https://lists.qt-project.org/listinfo/interest>
>>> _______________________________________________
>>> Interest mailing list
>>> Interest at qt-project.org <mailto:Interest at qt-project.org>
>>> https://lists.qt-project.org/listinfo/interest <https://lists.qt-project.org/listinfo/interest>
>> 
>> 
>> 
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org <mailto:Interest at qt-project.org>
>> https://lists.qt-project.org/listinfo/interest <https://lists.qt-project.org/listinfo/interest>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210421/296a9f44/attachment.html>