[Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?
Furkan Üzümcü
furkanuzumcu at gmail.com
Thu Mar 17 16:17:06 CET 2022
We definitely had cases like that. We also have a few widgets that are supposed to be tree views with millions of items inside. What we ended up doing is flattening the tree model into a list model. It wasn’t easy to get there, so I definitely understand your point.
Hopefully there’s more work from the Qt Company and the community to make all that effort worth it for all of us. Thanks for sharing your experience.
Regards,
Furkan Uzumcu<https://aka.ms/o0ukef>
________________________________
From: Michael Jackson <mike.jackson at bluequartz.net>
Sent: Thursday, March 17, 2022 10:17:40 AM
To: Furkan Üzümcü <furkanuzumcu at gmail.com>
Subject: Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?
Hello,
Thank you for the personal response. What I failed to articulate well in my email was that our desktop app heavily relies on a TreeView to view some internal data structures and then render those using VTK. We thought we could push past the issues but we just could not. We paid a heavy financial price just trying to get VTK and QML to play nice together and get a TreeView (basically written from scratch) that still does not support basic mouse hovering, drag and drop, easy extension. These functions are absolutely critical to our application. Without them, the application isn't usable. So for _our_ use case QML was not an appropriate choice. We are also stuck on Qt5 for at least another year since our end customer isn't able to install Qt6 in order to compile our codes. QML _can_ be very nice to use. It _can_ be great for the right development teams. Just not _our_ application in QML's current state. I really hope Qt puts some more concentrated effort into these areas and we can revisit this again in a few years.
--
Michael Jackson | Owner, President
BlueQuartz Software
[e] mike.jackson at bluequartz.net
[w] www.bluequartz.net<http://www.bluequartz.net>
On 3/16/22, 6:51 PM, "Furkan Üzümcü" <furkanuzumcu at gmail.com> wrote:
Hi Micheal.
I’m pretty late to the discussion, just checking my Qt Interest emails, I’d like to chime in with my opinion on this since I’m on a similar boat to yours.
I’ve been working on a legacy system (35 years old CAD software), and we’ve been working on a project to rewire the GUI, pay off some technical debt, and re-architecture the software so things are not painful to deal with any more. We’ve set up a system where we have designers contribute QML code to our codebase, and things have worked out great for us so far. Sometimes we do run into some troubles, but so far we’ve always been either find a workaround or create a fix ourselves. We are nearing the end of the project, and the way we set up our architecture with QML really did change the way we work as a team with devs and also across teams.
Our team struggled in the beginning (Really even now…) because everyone was painfully used to procedural programming and was not that willing to expand their knowledge and get used to other paradigms. It got easier over time, but I think that’s the biggest problem we had. I also find that there’s not that many good practices and community knowledge around QML in general. I tried to help in a small way by creating this document: https://github.com/Furkanzmc/QML-Coding-Guide but there’s not much attention to it. It seems to me that in order for a team to be really productive with QML, they need a helping hand from someone experienced to show them the ropes, I was that person in our team and it was a struggle for me. But in the end, it paid off.
I think what the Qt Company did with the new QML book is definitely a good step forward for this.
> On Feb 21, 2022, at 18:51, Michael Jackson <mike.jackson at bluequartz.net> wrote:
>
> So I’ll throw my 2 cents worth of experience into the ring.
>
> I’ve developed a desktop application using Qt Widgets since 2009 era. Last year we got funding to completely rewrite it from the ground up. We selected QML over widgets because we wanted that forced Model-View-Delegate and separation of the back end from the front end. QML sure looked promising from the demos. The early prototypes were nice. What we got for development is a hot mess. The QML debugger is a joke. GammaRay helps here and there trying to figure out what rectangles are where. The development time is horribly long. QML itself is just a black-magic soup where you never really know when things are getting initialized. We were hoping to have a flashy desktop application, all “modern” and everything. We are months behind schedule at this point. We spend hours messing with QML trying to get it to behave appropriately (sizing, visual style) where widgets would have just been “done”. We spent a large chunk of cash paying someone to get a TreeView working since Qt5 doesn’t supply one (Don’t get me started on that.. ).
>
> Had I known back then what I know *now* I would never have selected QML over Widgets for Desktop development. In no way is it ready for anything past some trivial applications. Not even close. The idea is great. The vision is cool. Our development experience has not been a good one.
>
> @Mark Gaiser one of our contractors implemented some code up in main.cpp where we press “F7” and the app reloads using the QML files from disk. This helps us cycle the theme updates and QML updates instead of having to quit and restart each time.
>
> --
> Michael Jackson | Owner, President
> BlueQuartz Software
> [e] mike.jackson at bluequartz.net
> [w] www.bluequartz.net<http://www.bluequartz.net>
>
>
> On 2/21/22, 6:34 PM, "Interest on behalf of Mark Gaiser" <interest-bounces at qt-project.org on behalf of markg85 at gmail.com> wrote:
>
> On Mon, Feb 21, 2022 at 11:11 PM Bernhard Lindner <private at bernhard-lindner.de> wrote:
>> Hi,
>>
>> QML is nice for basic applications but widgets is important for professional, technical
>> and high-density applications.
>>
>> But that doesn't matter. From my point of view Qt stopped being developed as a desktop
>> framework a long time ago. Other industries seems to have priority now.
>
> Well, it was nearly good enough in the Qt5 days with Controls V1.
> All they needed was a better set of controls to accommodate mobile more and reduce complexity in V1.
>
> What they did - conceptually - with V2 was good.
> But it seems like they just left it in alpha quality and call it "ok" to replace V1.. That was a mistake.
> It needed much more development time to be a proper replacement.
>
> We're now like ~8 years past the introduction of the V2 set...
> And it still has really severe bugs that just interrupt usability. 8 years...
> So I doubt it will be getting any better at all.
>>
>> On Mo, 2022-02-21 at 16:42 +0100, Mark Gaiser wrote:
>> > Hi,
>> >
>> > I'm facing so many bugs in QML Controls in Qt6 (they used to be Controls V2 in the Qt 5.x
>> > days) that I don't want to use them at all anymore. They are bugged beyond repair and
>> > downright unusable for native desktop integration purposes.
>> >
>> > Is there another good open source component set out there that integrates with the
>> > desktop. Specifically with Windows but preferably also with Linux (kde and gnome) and Mac.
>> >
>> > Using QWidgets should not be an alternative as it slows down development a lot. But given
>> > the crap that QML Controls is makes me consider switching to QWidgets instead.
>> >
>> >
>> > Best regards,
>> > Mark
>> > _______________________________________________
>> > Interest mailing list
>> > Interest at qt-project.org
>> > https://lists.qt-project.org/listinfo/interest
>>
>> --
>> Best Regards,
>> Bernhard Lindner
>>
>> _______________________________________________
>> Interest mailing list
>> 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
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
Regards,
Furkan Üzümcü
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20220317/4e13412f/attachment.htm>
More information about the Interest
mailing list