[Interest] Guide me through the Qt offerings for GUIs

Rui Oliveira ruilvo at hotmail.com
Wed Apr 21 19:24:38 CEST 2021

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 <something> days!


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
>> 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 at qt-project.org
>>> 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
> _______________________________________________
> 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/e4ab609c/attachment.html>

More information about the Interest mailing list