Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Furkan Üzümcü]

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

From: Michael Jackson 
Sent: Thursday, March 17, 2022 10:17:40 AM
To: Furkan Üzümcü 
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.jack...@bluequartz.net
[w] www.bluequartz.net


On 3/16/22, 6:51 PM, "Furkan Üzümcü"  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  
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 

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Furkan Üzümcü]

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  
> 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.jack...@bluequartz.net
> [w] www.bluequartz.net
>  
>  
> On 2/21/22, 6:34 PM, "Interest on behalf of Mark Gaiser" 
>  wrote:
>  
> On Mon, Feb 21, 2022 at 11:11 PM Bernhard Lindner 
>  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.

Re: [Interest] Is there a good alternative to the QML, Controls in Qt6 for native desktop integration purposes?

[Roland Hughes via Interest]

On 2/27/22 05:00, Volker Hilsheimer wrote:

11) The terms of the commercial license

My perspective on this is very limited, it?s been a few years since I?ve been on 
the buyer?s side of R tooling. I do think that the recent cleanup of the 
licenses and the new license agreement [1], and in particular the new terms 
regarding the distribution of software after development licenses have expired, are 
a huge step into the right direction.

[1]https://www.qt.io/faq/tag/qt-commercial-licensing


That's what I left off my list!

Whatever you know about licensing, give it 15 minutes and your knowledge 
will be invalid. One can get more consistent answers from a roulette 
wheel. No, "talk to your sales rep" is not an answer.


--
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] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Петр]

I'm just a developer, of course, but
1) Qt doesn't expand controls in any way in accordance with trends and new
ideas in ux/ui (burger menu and etc.) On each new project, you have to
write a lot of basic things that are not in the controls, and even if they
are, then Qt doesn't provide a ui kit so that designers can somehow build
something on this. I understand that you want it to look native, but
usually it only covers the buttons and window view. Qt designer is cool,
but it is just visual setting properties and qml-live. I think designers
need vision, examples and ets. This will lower the entry threshold.
2) Qt can offer his own controls that will be convenient for use by both
developers and users (this should be with design)
3) The above can be taken over by the community, but there should still be
moderators and collaboration for synchronization and a better result.
4) Rewarding for fixing bugs or contributing was a good motivation for
example for me (I didn’t go well with the nerves at the interview and
failed it, but I still want to make Qt better, especially qml part)

сб, 26 февр. 2022 г. в 18:41, Volker Hilsheimer :

> Thanks for a lot of good replies and input to this thread. I’m taking the
> liberty to summarise a bit what I have read, especially from those of you
> who would like to contribute, but have given reasons why you don’t.
>
> Starting with the things that I or we can and should do something about.
>
>
> 1) Difficult contribution process
>
> > * Overly difficult to setup all the needed accounts, git pulls, PRs,
> Gerrit review processes.
>
> > Unfortunately the process of contributing code to the project feels only
> a little bit better than eating glass.
>
>
> I agree that it is a steep learning curve. The pay-off compared to simple
> PR’s using github workflows isn’t always clear, and doesn’t manifest at all
> for casual contributors. Honestly, I hated the process in the beginning,
> and I’m still not at ease with it. I’m always reminded of how complex it is
> when we onboard new people in The Qt Company. git is a complex tool as it
> is, adding the gerrit-specifics makes it really painful unless you have a
> ton of scripts, which then just add to the cognitive overload. The
> repository structure adds more complexity.
>
> I’m sure the documentation isn’t as good as it could be, and perhaps some
> tooling to get started could help lower some of those bars. But in the end:
> it shouldn’t be that hard.
>
> Would it help if we’d accept PRs through the GitHub mirrors? We’d need to
> integrate the CLA workflow into github (see CLA point further down), and
> perhaps implement some integrated review process, but perhaps this can be
> solved.
>
>
> 2) Access to cross-platform testing systems
>
> > * Ensuring it works cross platform when most may not have access to all
> of the needed testing systems.
>
> First of all, you can’t break anything; our CI system, as challenged as it
> is these days to keep up with the workload, will test your changes on all
> relevant platforms. But I agree that throwing stuff at CI just to see if it
> builds is not a great way of developing software.
>
> Would it help if we would make readily provisioned VMs or docker images
> (where applicable) available? Perhaps as an AMI in AWS (which then takes
> care of e.g. Windows or macOS licensing)? Or at least scripts or Ansible
> playbooks or equivalent stuff that you can run locally to install the tools
> and dependencies?
>
> If you think this would help, then I might have a solution for you in a
> bit.
>
>
> 3) Priorities
>
> > * My bugs probably may not align with TQtC priorities
> > * An "apparent" lack of interest from Qt in QML for the desktop makes me
> think "why would i care?"
>
>
> If you are making a contribution that improves Qt on the desktop (which is
> what this thread is all about), then there are plenty of approvers in the
> Open Source community outside of The Qt Company, and there are plenty of
> people inside that would be happy to work with you as well. TQtC priorities
> define what TQtC employees will spend the majority of their time on; they
> don’t have to be your priorities, and just because your ideas don’t match
> TQtC’s strategy doesn’t invalidate your ideas. Btw, Qt Creator, Qt Design
> Studio, or Squish are desktop applications as well.
>
> Of course, not every idea that comes in via code review or JIRA ticket
> fits the Qt project. But an improvement to widgets or Quick on the desktop
> will generally have my attention.
>
>
> 4) Difficult to find reviewers
>
> > * Finding time in my own schedule to match up with time from a Qt
> engineers schedule.
> > * Nobody looks at contributions
>
>
> Knowing who might be interested in your change takes a bit of effort,
> following the project, seeing who is active in which area. Getting support
> for your ideas requires an investment and some convincing of people.
>
> The list of maintainers is long, and some of the people on the list
> haven’t 

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Volker Hilsheimer]

Thanks for a lot of good replies and input to this thread. I’m taking the 
liberty to summarise a bit what I have read, especially from those of you who 
would like to contribute, but have given reasons why you don’t.

Starting with the things that I or we can and should do something about.


1) Difficult contribution process

> * Overly difficult to setup all the needed accounts, git pulls, PRs, Gerrit 
> review processes.

> Unfortunately the process of contributing code to the project feels only a 
> little bit better than eating glass.


I agree that it is a steep learning curve. The pay-off compared to simple PR’s 
using github workflows isn’t always clear, and doesn’t manifest at all for 
casual contributors. Honestly, I hated the process in the beginning, and I’m 
still not at ease with it. I’m always reminded of how complex it is when we 
onboard new people in The Qt Company. git is a complex tool as it is, adding 
the gerrit-specifics makes it really painful unless you have a ton of scripts, 
which then just add to the cognitive overload. The repository structure adds 
more complexity.

I’m sure the documentation isn’t as good as it could be, and perhaps some 
tooling to get started could help lower some of those bars. But in the end: it 
shouldn’t be that hard.

Would it help if we’d accept PRs through the GitHub mirrors? We’d need to 
integrate the CLA workflow into github (see CLA point further down), and 
perhaps implement some integrated review process, but perhaps this can be 
solved.


2) Access to cross-platform testing systems

> * Ensuring it works cross platform when most may not have access to all of 
> the needed testing systems.

First of all, you can’t break anything; our CI system, as challenged as it is 
these days to keep up with the workload, will test your changes on all relevant 
platforms. But I agree that throwing stuff at CI just to see if it builds is 
not a great way of developing software.

Would it help if we would make readily provisioned VMs or docker images (where 
applicable) available? Perhaps as an AMI in AWS (which then takes care of e.g. 
Windows or macOS licensing)? Or at least scripts or Ansible playbooks or 
equivalent stuff that you can run locally to install the tools and dependencies?

If you think this would help, then I might have a solution for you in a bit.


3) Priorities

> * My bugs probably may not align with TQtC priorities
> * An "apparent" lack of interest from Qt in QML for the desktop makes me 
> think "why would i care?"


If you are making a contribution that improves Qt on the desktop (which is what 
this thread is all about), then there are plenty of approvers in the Open 
Source community outside of The Qt Company, and there are plenty of people 
inside that would be happy to work with you as well. TQtC priorities define 
what TQtC employees will spend the majority of their time on; they don’t have 
to be your priorities, and just because your ideas don’t match TQtC’s strategy 
doesn’t invalidate your ideas. Btw, Qt Creator, Qt Design Studio, or Squish are 
desktop applications as well.

Of course, not every idea that comes in via code review or JIRA ticket fits the 
Qt project. But an improvement to widgets or Quick on the desktop will 
generally have my attention.


4) Difficult to find reviewers

> * Finding time in my own schedule to match up with time from a Qt engineers 
> schedule.
> * Nobody looks at contributions


Knowing who might be interested in your change takes a bit of effort, following 
the project, seeing who is active in which area. Getting support for your ideas 
requires an investment and some convincing of people.

The list of maintainers is long, and some of the people on the list haven’t 
been active in the project for a while. The quality of the channels we as a 
community have to find people to help out with code reviews is, frankly, 
sub-par. And on those channels we do have (and that I’m on) there don’t seem to 
be a lot of people looking for reviewers.

Use what we have (perhaps an email to developm...@qt-project.org). And if you 
have improvements to widgets or to Quick Controls, especially on the desktop, 
then I will be very interested in your patches.


5) Writing tests

> * Writing a unit test is always a blast. Again, time waiting for a code 
> review.


While we can all agree that the ideal way of writing code or fixing bugs is to 
do that together with a automated test case, it’s sometimes simply too 
challenging, especially for a casual contributor. Finding someone to work with 
and get support from is not always easy. I personally enjoy writing tests, and 
even if I don’t always have time to do so myself I at least enjoy discussing 
how a test could be written for those areas in Qt that I’m familiar with. I 
know that many of my colleagues feel the same.

So again, if you have something that makes widgets or Quick on the desktop 
better, then add me as a reviewer.



6) Code complexity and lack of 

Re: [Interest] Is there a good alternative to the QML, Controls in Qt6 for native desktop integration purposes?

[Roland Hughes via Interest]

Am 24.02.2022 um 15:38 hat Volker Hilsheimer geschrieben:


Evidently, the people commenting in this thread care deeply enough
about Qt on the desktop to participate in the discussion. And I suppose
most of us on this list are software engineers, many perhaps for more
reasons than to put food on the table. My question to you is: how can
we make it easier, or more fun, or more motivating to contribute to Qt,
and to help with making things better?


my 2 cents in decreasing order of rank.

 * Many of us work for companies/clients that paid north of $600K for 5
   developer seats and those companies were lead to believe the bulk of
   the licensing fees would be used to zero out the bug database that
   was north of 5000 at the time. Instead, Qt 6 was forced out the door
   YEARS before it was close to ready dramatically increasing the
   number of bugs per the original message of this thread.
 * There have been many stories over the years of people who went
   through the pain and suffering of setting up a development
   environment per the haloed instructions, had a laughing good time
   writing a test, then submitted the patch into the abyss. Nobody
   looked at it. Patch rotted until the version of Qt it was made
   against was no longer supported. Those people left Qt for good, most
   of them, if any are left, they aren't going to waste their time.
   Life's too short to waste that much of it when there is less than a
   50/50 chance of a patch getting through?
 * There is no OpenSource Qt anymore. There is just alpha-quality
   pre-release commercial software one then has to pay to use.
   OpenSource Qt died when the LTS became commercial only.
 * On multiple occasions TQtC people have talked about the stock price
   of the company. Given the comment Bernhard Lindner made, the above
   comment really is the view of the OSS world. Why would anyone want
   to work for free to increase the stock price of a company that
   doesn't fix their bugs. Yes, some bugs eventually get fixed, but the
   company adds new features rather than whittling the bug database
   down to under 100 first.
 * Lastly, for Americans anyway, it might now be illegal. America has a
   long storied history with slavery and a whole lot of laws to prevent
   it in many forms. Read up on the massive fines Walmart had to pay
   for making hourly workers work off-clock. Every major hospital has a
   massive number of volunteers working there. The hospital can't
   function without them. The hospital also had to set up formal
   volunteer programs that complied with the law and after N hours of
   volunteer work said volunteers have to have access to benefits like
   health care, etc. In general it is illegal to work for free for a
   for-profit entity. A fact Facebook and the other social media giants
   are tap-dancing around right now. The "we're just a platform"
   argument is falling apart. So, when the OSS world was controlling
   the direction of Qt and providing an LTS, everyone was free to work
   for free. TQtC was free to sell support contracts and license things
   they developed on their own that weren't released to the OSS
   community. That's the way it works in America. It got __really__
   gray and iffy when TQtC began exerting control over the direction of
   the product and the OSS effort. Exactly when that was doesn't
   matter. At that point it became highly questionable. One had to
   desperately cling to the existence of the LTS and spin a tale TQtC
   was just scamming license fees from companies that could otherwise
   use the LTS for free. Today, from what everyone says, the OSS
   community doesn't control the direction of the product. There is no
   OpenSource LTS allowed to exist. The community can't even create one
   if it wanted to. By extension of that, there is no OpenSource Qt,
   just pre-release commercial software one is allowed to use for a
   little while. A non-profit charity that has filled out the paperwork
   to get itself classified as a non-profit charity like OpenSource
   projects accepting donations in/from America can have any number of
   people working for free for as long as those people care to work for
   free. A publicly traded for-profit entity cannot. I'm not a lawyer,
   but I've had clients that had to deal with this time and time again.
   In their case, people are honked off at them because they have to
   turn them away. The time, cost, and effort of setting up a formal
   volunteer program and complying with government regulations just
   isn't worth the effort. They do it for temporary internships, but
   nothing else. Many corporations opt to pay their interns just to
   avoid the hassle.
 * Many Linux distros dropped KDE long ago and now many are talking
   about dropping Qt as well. Other than possibly WireShark, every
   other Qt based OpenSource project with any kind of user base has
   "something" written with a different tool set that does many of the
   same 

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Richard Weickelt]

Hi Volker,

closing access to LTS was a terrible decision by the Qt Company's management. 

Why is there no bounty system to attract developers fixing bugs and lowering 
the barrier for anybody to get bugs fixed in a timely manner or to get features 
added? Voting for tickets is entire non-sense if it's not backed by money.

I never found it hard to contribute to Qt and always enjoyed the positive and 
helpful review comments. I learned something for life. And I don't care about 
the CLA as long as I can use the fruits of my own work.

Selling licenses is a business model for sure, but I don't think it's a very 
healthy model for the future of Qt. The role of the Qt company should be more 
about moderation, communication and building up a fertile eco system IMO. But 
that is not very compatible with the purpose of a stock company. Right now it 
behaves more like a traditional industrial company without any notion of 
creativity. But I think it's too late to make Qt great again. C++ is no longer 
the lingua franca on the desktop and people got even used to sluggish software 
like MS Teams. C# is backed by overwhelming manpower and market force, I don't 
see how the Qt company can compete with that.

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

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Nils Jeisecke via Interest]

Am 24.02.2022 um 15:38 hat Volker Hilsheimer geschrieben:

>Evidently, the people commenting in this thread care deeply enough
>about Qt on the desktop to participate in the discussion. And I suppose
>most of us on this list are software engineers, many perhaps for more
>reasons than to put food on the table. My question to you is: how can
>we make it easier, or more fun, or more motivating to contribute to Qt,
>and to help with making things better?

my 2 cents:

* Ensure people have trust in the Qt Company (again) by publicly
  guaranteeing that (the essential parts of) Qt will always be available
  under LGPL. Reconsider the LTS decision.

* Advertise it when things like the qt.labs.calendar items (previously only
  available under marketplace licenses, never for Qt 6) become available
  under LGPL (hopefully I am not mistaken here).

* More love for the Desktop ;-)

* Get rid of the V4 complexity (hello qmlsc/qmltc). Added on top of the
  scenegraph wizardry it is incredible difficult for non-insiders to
  help analyzing/debugging problems in this area. Also I'm not aware of
  any public technical documentation about how this stuff actually
  works.

* Offer commercial licenses under terms hardly anybody can refuse ;-)

Technically:

Contributing documentation should be easier. Sometimes it's just about
adding little notes about things you've learned during development that
should be shared in the documentation.

Currently you can easily spend hours of work to get a single sentence
in. Setting up a local environment only to allow previewing/checking
documentation is way too complicated (at least that was my impression
when trying to do that last time, maybe this has changed with Q6/cmake?)

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

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Narolewski Jakub]

Dear Volker,

I have always found Qt project fascinating from a technological
perspective. I enjoy using it and I will surely continue to do so. Multiple
times when I discovered that some things can be made faster, better or more
robust I felt the need to give the community something back.

Unfortunately the process of contributing code to the project feels only a
little bit better than eating glass.

This probably seems silly at best for someone how does it daily but as I
have only a limited amount of free time for 'side activities' I find it ...
demotivating.

As for how this could be improved I have honestly no idea. It would be nice
to contribute back to Qt but - for me personally - the entry barrier seems
quite high.

On Thu, 24 Feb 2022, 16:40 Volker Hilsheimer, 
wrote:

> > On 22 Feb 2022, at 00:34, Mark Gaiser  wrote:
> >>> 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.
> >>
> >> On Mon, Feb 21, 2022 at 11:11 PM Bernhard Lindner <
> priv...@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.
> >
>
>
> Hi All,
>
> Thanks for keeping it civilised.
>
> Yes, Qt Quick Controls - and largely the entire Qt Quick framework - were
> originally designed for mobile and embedded platforms, and indeed, that
> shows when using them for the desktop.
>
> I’m happy that at least in The Qt Company we are now in a position that
> allows us to put more focus on the desktop, and that we are are able to do
> more than maintenance and catching up with what’s happening on the
> underlying platforms. That includes the journey of making Qt Quick Controls
> a great toolkit for the desktop as well. In Qt 6 so far we have had first
> implementations of the native styles - yes, those require more work; we
> have made a number of improvements to item views, including a TreeView now
> in Qt 6.3; a first set of standard dialogs is in Qt 6.2 and more are coming
> in 6.3. We have worked on some architectural issues that are problematic on
> the desktop, such as keyboard navigation and focus handling, and there is a
> fair amount of more work needed there as well.
>
> I’m not going to claim that all things will be wonderful any moment now;
> there’s plenty of work that needs to be done. But things do get better,
> both with Qt Quick Controls, and with Qt Widgets as well.
>
> What keeps confusing me personally is how few people in the community seem
> to find it interesting to contribute to either of our UI frameworks in Qt.
> If I take one of the QtWidgets issues that came up in this thread:
> "QTBUG-6864 is 12 years old, has 47 votes”. I sat down on Tuesday evening
> to check what it would take to implement hiding of rows in a QFormLayout;
> after a few hours I had a working implementation, which is right now on its
> way into the dev branch. The hardest part, as it so often is, was writing a
> unit test.
>
> Now, I understand that not everybody finds it fun to do that kind of thing
> on a Tuesday evening. But given the apparently high interest in this
> feature, that nobody seems to have tried to give it a shot in 12 years is
> really puzzling me. When Nokia acquired Trolltech, it didn’t take a crystal
> ball to see that the focus won’t be the desktop. And one answer to this was
> to move Qt under Open Governance so that anyone could contribute to Qt and
> make sure that it stays awesome also for domains that Nokia won’t care much
> about.
>
> Evidently, the people 

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Nyall Dawson]

On Fri, 25 Feb 2022 at 01:40, Volker Hilsheimer  wrote:

>  My question to you is: how can we make it easier, or more fun, or more 
> motivating to contribute to Qt, and to help with making things better?

Speaking from my personal perspective:

The situation with the open source releases and the new LTS update
policy is the #1 thing holding me back from contributing to Qt.  I
just can't justify the time investment required to fix bugs in Qt if
I'll only see the benefit of those fixes in 12+ months time, when the
applications I use have been ported to Qt 6.

Speaking from a downstream project's perspective:

I'm heavily involved in the QGIS application
(https://qgis.org/en/site/), which is an open-source GIS based on Qt.
The QGIS project has a good history of contributing fixes to Qt for
issues which impact us -- we contract out to KDAB to implement these
fixes on our behalf. Over recent years we've probably invested around
20k EUR into Qt via KDAB. I'd like to think the QGIS project is a very
well behaved open-source contributor in this regard! (And, for
reference, there's plans to invest much more heavily in the future,
especially in Qt's SVG support and QPainter framework).
Unfortunately the LTS situation has made justifying the cost of
funding these fixes difficult, as QGIS will remain on Qt 5 for the
foreseeable future. Previously we could easily demonstrate the value
of the fixes as ALL our users would (eventually!) see the fix,
regardless of whether they were on Windows/Mac or linux builds. Now
only a very tiny portion of our users receive the fixes (specifically,
those using recent Fedora releases, as Fedora have moved away from Qt
5 upstream packages to instead following the KDE maintained 5.15
fork). Our Windows, Mac and debian based users will likely never get
the fix for their Qt 5 versions.

So, please, if you want to see more community contributions you NEED
to reverse the LTS licensing situation (at least for the Qt 5.15
version).

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

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Mark Gaiser]

On Thu, Feb 24, 2022 at 4:38 PM Volker Hilsheimer 
wrote:

> > On 22 Feb 2022, at 00:34, Mark Gaiser  wrote:
> >>> 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.
> >>
> >> On Mon, Feb 21, 2022 at 11:11 PM Bernhard Lindner <
> priv...@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.
> >
>
>
> Hi All,
>
> Thanks for keeping it civilised.
>

Thank you for writing that insightful response! That's nice to read!

>
> Yes, Qt Quick Controls - and largely the entire Qt Quick framework - were
> originally designed for mobile and embedded platforms, and indeed, that
> shows when using them for the desktop.
>

It's not as simple as that.
In my view Qt went backwards with the version 6 release and QML support on
the desktop.
What was there before (Controls V1) in Qt5 sure had it's fair share of
bugs, true, but it was working very stable with relatively minor annoyances
to work around.
One should not remove something if the replacement isn't at least
reasonable on par with what was removed. I'm sure some of it is driven by
the maintenance cost of 2 component sets so with that in mind it did make
much sense to drop one. That being said, I don't think the current
components should be more than a labs project.

I’m happy that at least in The Qt Company we are now in a position that
> allows us to put more focus on the desktop, and that we are are able to do
> more than maintenance and catching up with what’s happening on the
> underlying platforms. That includes the journey of making Qt Quick Controls
> a great toolkit for the desktop as well. In Qt 6 so far we have had first
> implementations of the native styles - yes, those require more work; we
> have made a number of improvements to item views, including a TreeView now
> in Qt 6.3; a first set of standard dialogs is in Qt 6.2 and more are coming
> in 6.3. We have worked on some architectural issues that are problematic on
> the desktop, such as keyboard navigation and focus handling, and there is a
> fair amount of more work needed there as well.
>

That's good to hear :)
I do still care enough to want to use Qt with QML if it gets better.

>
> I’m not going to claim that all things will be wonderful any moment now;
> there’s plenty of work that needs to be done. But things do get better,
> both with Qt Quick Controls, and with Qt Widgets as well.
>
> What keeps confusing me personally is how few people in the community seem
> to find it interesting to contribute to either of our UI frameworks in Qt.
> If I take one of the QtWidgets issues that came up in this thread:
> "QTBUG-6864 is 12 years old, has 47 votes”. I sat down on Tuesday evening
> to check what it would take to implement hiding of rows in a QFormLayout;
> after a few hours I had a working implementation, which is right now on its
> way into the dev branch. The hardest part, as it so often is, was writing a
> unit test.
>
> Now, I understand that not everybody finds it fun to do that kind of thing
> on a Tuesday evening. But given the apparently high interest in this
> feature, that nobody seems to have tried to give it a shot in 12 years is
> really puzzling me. When Nokia acquired Trolltech, it didn’t take a crystal
> ball to see that the focus won’t be the desktop. And one answer to this was
> to move Qt under Open Governance so that anyone could contribute to Qt and
> make sure that it stays awesome also for domains that Nokia won’t 

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Michael Jackson]

Dear Volker,
I will try to address some points from my own context which is that I've 
been using Qt for our open source cross platform desktop application since 
early Qt4. I've stuck with Qt because of the close to write once (mostly) just 
compile and run everywhere kind of thing. I code all day, try to run my 
company, hire people, manage projects, manage contracts so frankly I don't have 
the time to _learn_ the deep underpinnings of Qt to fix a bug. If it really 
only took an hour or so to fix I might actually consider contributing. And at 
this point since Qt 5.15.2 will not have any more releases there is absolutely 
*no* reason to contribute to Qt.

I think some of the hurdles to putting in bug patches is the following:
* Overly difficult to setup all the needed accounts, git pulls, PRs, Gerrit 
review processes.
* Finding time in my own schedule to match up with time from a Qt engineers 
schedule. 
* My bugs probably may not align with TQtC priorities
* Writing a unit test is always a blast. Again, time waiting for a code review.
* Ensuring it works cross platform when most may not have access to all of the 
needed testing systems.


I agree with the others that the LTS releases need to go out to open source. I 
understand that The Qt Company is a business and needs to earn revenue to pay 
its own engineers. On the flip side though TQtC yanking the licensing rug out 
from underneath my company puts _my_ company at risk. I don't have a solid 
answer for how the licensing should be done, but clearly the current practice 
_isn't_ well received by the Qt community. I don't think the community is 
asking for much to have the 5.15.8 released to OSS.

Respectfully
Michael Jackson
Owner, BlueQuartz Software, LLC

On 2/24/22, 10:39 AM, "Interest on behalf of Volker Hilsheimer" 
 wrote:

Hi All,

Thanks for keeping it civilised.

Yes, Qt Quick Controls - and largely the entire Qt Quick framework - were 
originally designed for mobile and embedded platforms, and indeed, that shows 
when using them for the desktop.

I’m happy that at least in The Qt Company we are now in a position that 
allows us to put more focus on the desktop, and that we are are able to do more 
than maintenance and catching up with what’s happening on the underlying 
platforms. That includes the journey of making Qt Quick Controls a great 
toolkit for the desktop as well. In Qt 6 so far we have had first 
implementations of the native styles - yes, those require more work; we have 
made a number of improvements to item views, including a TreeView now in Qt 
6.3; a first set of standard dialogs is in Qt 6.2 and more are coming in 6.3. 
We have worked on some architectural issues that are problematic on the 
desktop, such as keyboard navigation and focus handling, and there is a fair 
amount of more work needed there as well.

I’m not going to claim that all things will be wonderful any moment now; 
there’s plenty of work that needs to be done. But things do get better, both 
with Qt Quick Controls, and with Qt Widgets as well.

What keeps confusing me personally is how few people in the community seem 
to find it interesting to contribute to either of our UI frameworks in Qt. If I 
take one of the QtWidgets issues that came up in this thread: "QTBUG-6864 is 12 
years old, has 47 votes”. I sat down on Tuesday evening to check what it would 
take to implement hiding of rows in a QFormLayout; after a few hours I had a 
working implementation, which is right now on its way into the dev branch. The 
hardest part, as it so often is, was writing a unit test.

Now, I understand that not everybody finds it fun to do that kind of thing 
on a Tuesday evening. But given the apparently high interest in this feature, 
that nobody seems to have tried to give it a shot in 12 years is really 
puzzling me. When Nokia acquired Trolltech, it didn’t take a crystal ball to 
see that the focus won’t be the desktop. And one answer to this was to move Qt 
under Open Governance so that anyone could contribute to Qt and make sure that 
it stays awesome also for domains that Nokia won’t care much about.

Evidently, the people commenting in this thread care deeply enough about Qt 
on the desktop to participate in the discussion. And I suppose most of us on 
this list are software engineers, many perhaps for more reasons than to put 
food on the table. My question to you is: how can we make it easier, or more 
fun, or more motivating to contribute to Qt, and to help with making things 
better?


Volker





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

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Nikos Chantziaras]

On 21/02/2022 17:42, Mark Gaiser wrote:
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.


There is:

https://api.kde.org/frameworks/qqc2-desktop-style/html/index.html

I haven't used it myself, since I prefer QWidget, so I'm not sure if it 
supports Qt 6. You might have to stay with Qt 5.15, and use 5.15 branch 
from the KDE project:


https://community.kde.org/Qt5PatchCollection

instead of the now outdated official 5.15.2 release. KDE's branch 
provides some of the updates of the 5.15.x releases that Qt have locked 
behind a paywall.


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

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Nikos Chantziaras]

On 24/02/2022 17:38, Volker Hilsheimer wrote:

how can we make it easier, or more fun, or more motivating to contribute to Qt, 
and to help with making things better?


Removing the Contribution License Agreement and releasing your LTS 
versions of Qt as open source instead of making them closed source and 
proprietary would be a good start.


I have contributed code to quite a few project over the years, except 
Qt, because of the CLA. Now it's even less likely as Qt become hostile 
to open source projects.


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

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Bernhard Lindner]

> Evidently, the people commenting in this thread care deeply enough about Qt 
> on the
> desktop to participate in the discussion. And I suppose most of us on this 
> list are
> software engineers, many perhaps for more reasons than to put food on the 
> table. My
> question to you is: how can we make it easier, or more fun, or more 
> motivating to
> contribute to Qt, and to help with making things better?

I don't know how to make it more attractive for OSS developers to contribute. 
But I know
how to make it more unattractive... OSS hostile licenes are one way. 

Recently in one of the biggest german IT news portals there was a news about 
Qt. It got
exactly one comment thread that said "After the new licensing model, Qt is dead 
anyway". 
If this is the conventional wisdom among OSS developers, then no further effort 
is needed.

-- 
Best Regards,
Bernhard Lindner

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

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Volker Hilsheimer]

Of course; I think there are a number of developers here that use Qt under an 
Open Source license though, and perhaps even a few that, while having various 
reasons not to use Qt under an Open Source license, still wouldn't mind 
contributing with patches.


Volker


> On 24 Feb 2022, at 17:17, Nelson, Michael via Interest 
>  wrote:
> 
> A fair question perhaps for OSS community but many on this list pay for 
> licensing and support precisely because we don't have time to fix everything 
> ourselves.
> 
> MIke
> 
> 
> Confidential - Company Proprietary
> 
> -Original Message-
> From: Interest  On Behalf Of Volker 
> Hilsheimer
> Sent: Thursday, February 24, 2022 10:39 AM
> To: Qt Interest 
> Subject: Re: [Interest] Is there a good alternative to the QML Controls in 
> Qt6 for native desktop integration purposes?
> 
>> On 22 Feb 2022, at 00:34, Mark Gaiser  wrote:
 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.
>>> 
>>> On Mon, Feb 21, 2022 at 11:11 PM Bernhard Lindner 
>>>  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.
>> 
> 
> 
> Hi All,
> 
> Thanks for keeping it civilised.
> 
> Yes, Qt Quick Controls - and largely the entire Qt Quick framework - were 
> originally designed for mobile and embedded platforms, and indeed, that shows 
> when using them for the desktop.
> 
> I’m happy that at least in The Qt Company we are now in a position that 
> allows us to put more focus on the desktop, and that we are are able to do 
> more than maintenance and catching up with what’s happening on the underlying 
> platforms. That includes the journey of making Qt Quick Controls a great 
> toolkit for the desktop as well. In Qt 6 so far we have had first 
> implementations of the native styles - yes, those require more work; we have 
> made a number of improvements to item views, including a TreeView now in Qt 
> 6.3; a first set of standard dialogs is in Qt 6.2 and more are coming in 6.3. 
> We have worked on some architectural issues that are problematic on the 
> desktop, such as keyboard navigation and focus handling, and there is a fair 
> amount of more work needed there as well.
> 
> I’m not going to claim that all things will be wonderful any moment now; 
> there’s plenty of work that needs to be done. But things do get better, both 
> with Qt Quick Controls, and with Qt Widgets as well.
> 
> What keeps confusing me personally is how few people in the community seem to 
> find it interesting to contribute to either of our UI frameworks in Qt. If I 
> take one of the QtWidgets issues that came up in this thread: "QTBUG-6864 is 
> 12 years old, has 47 votes”. I sat down on Tuesday evening to check what it 
> would take to implement hiding of rows in a QFormLayout; after a few hours I 
> had a working implementation, which is right now on its way into the dev 
> branch. The hardest part, as it so often is, was writing a unit test.
> 
> Now, I understand that not everybody finds it fun to do that kind of thing on 
> a Tuesday evening. But given the apparently high interest in this feature, 
> that nobody seems to have tried to give it a shot in 12 years is really 
> puzzling me. When Nokia acquired Trolltech, it didn’t take a crystal ball to 
> see that the focus won’t be the desktop. And one answer to this was to move 
> Qt under Open Governance so that anyone could contribute to Qt and make sure 
> that it stays awesome also for domains that Nokia won’t care 

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Nelson, Michael via Interest]

A fair question perhaps for OSS community but many on this list pay for 
licensing and support precisely because we don't have time to fix everything 
ourselves.

MIke


Confidential - Company Proprietary

-Original Message-
From: Interest  On Behalf Of Volker Hilsheimer
Sent: Thursday, February 24, 2022 10:39 AM
To: Qt Interest 
Subject: Re: [Interest] Is there a good alternative to the QML Controls in Qt6 
for native desktop integration purposes?

> On 22 Feb 2022, at 00:34, Mark Gaiser  wrote:
>>> 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.
>>
>> On Mon, Feb 21, 2022 at 11:11 PM Bernhard Lindner 
>>  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.
>


Hi All,

Thanks for keeping it civilised.

Yes, Qt Quick Controls - and largely the entire Qt Quick framework - were 
originally designed for mobile and embedded platforms, and indeed, that shows 
when using them for the desktop.

I’m happy that at least in The Qt Company we are now in a position that allows 
us to put more focus on the desktop, and that we are are able to do more than 
maintenance and catching up with what’s happening on the underlying platforms. 
That includes the journey of making Qt Quick Controls a great toolkit for the 
desktop as well. In Qt 6 so far we have had first implementations of the native 
styles - yes, those require more work; we have made a number of improvements to 
item views, including a TreeView now in Qt 6.3; a first set of standard dialogs 
is in Qt 6.2 and more are coming in 6.3. We have worked on some architectural 
issues that are problematic on the desktop, such as keyboard navigation and 
focus handling, and there is a fair amount of more work needed there as well.

I’m not going to claim that all things will be wonderful any moment now; 
there’s plenty of work that needs to be done. But things do get better, both 
with Qt Quick Controls, and with Qt Widgets as well.

What keeps confusing me personally is how few people in the community seem to 
find it interesting to contribute to either of our UI frameworks in Qt. If I 
take one of the QtWidgets issues that came up in this thread: "QTBUG-6864 is 12 
years old, has 47 votes”. I sat down on Tuesday evening to check what it would 
take to implement hiding of rows in a QFormLayout; after a few hours I had a 
working implementation, which is right now on its way into the dev branch. The 
hardest part, as it so often is, was writing a unit test.

Now, I understand that not everybody finds it fun to do that kind of thing on a 
Tuesday evening. But given the apparently high interest in this feature, that 
nobody seems to have tried to give it a shot in 12 years is really puzzling me. 
When Nokia acquired Trolltech, it didn’t take a crystal ball to see that the 
focus won’t be the desktop. And one answer to this was to move Qt under Open 
Governance so that anyone could contribute to Qt and make sure that it stays 
awesome also for domains that Nokia won’t care much about.

Evidently, the people commenting in this thread care deeply enough about Qt on 
the desktop to participate in the discussion. And I suppose most of us on this 
list are software engineers, many perhaps for more reasons than to put food on 
the table. My question to you is: how can we make it easier, or more fun, or 
more motivating to contribute to Qt, and to help with making things better?


Volker


___
Interest mailing list
Interest@qt-project.org

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Volker Hilsheimer]

> On 22 Feb 2022, at 00:34, Mark Gaiser  wrote:
>>> 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.
>> 
>> On Mon, Feb 21, 2022 at 11:11 PM Bernhard Lindner 
>>  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.
> 


Hi All,

Thanks for keeping it civilised.

Yes, Qt Quick Controls - and largely the entire Qt Quick framework - were 
originally designed for mobile and embedded platforms, and indeed, that shows 
when using them for the desktop.

I’m happy that at least in The Qt Company we are now in a position that allows 
us to put more focus on the desktop, and that we are are able to do more than 
maintenance and catching up with what’s happening on the underlying platforms. 
That includes the journey of making Qt Quick Controls a great toolkit for the 
desktop as well. In Qt 6 so far we have had first implementations of the native 
styles - yes, those require more work; we have made a number of improvements to 
item views, including a TreeView now in Qt 6.3; a first set of standard dialogs 
is in Qt 6.2 and more are coming in 6.3. We have worked on some architectural 
issues that are problematic on the desktop, such as keyboard navigation and 
focus handling, and there is a fair amount of more work needed there as well.

I’m not going to claim that all things will be wonderful any moment now; 
there’s plenty of work that needs to be done. But things do get better, both 
with Qt Quick Controls, and with Qt Widgets as well.

What keeps confusing me personally is how few people in the community seem to 
find it interesting to contribute to either of our UI frameworks in Qt. If I 
take one of the QtWidgets issues that came up in this thread: "QTBUG-6864 is 12 
years old, has 47 votes”. I sat down on Tuesday evening to check what it would 
take to implement hiding of rows in a QFormLayout; after a few hours I had a 
working implementation, which is right now on its way into the dev branch. The 
hardest part, as it so often is, was writing a unit test.

Now, I understand that not everybody finds it fun to do that kind of thing on a 
Tuesday evening. But given the apparently high interest in this feature, that 
nobody seems to have tried to give it a shot in 12 years is really puzzling me. 
When Nokia acquired Trolltech, it didn’t take a crystal ball to see that the 
focus won’t be the desktop. And one answer to this was to move Qt under Open 
Governance so that anyone could contribute to Qt and make sure that it stays 
awesome also for domains that Nokia won’t care much about.

Evidently, the people commenting in this thread care deeply enough about Qt on 
the desktop to participate in the discussion. And I suppose most of us on this 
list are software engineers, many perhaps for more reasons than to put food on 
the table. My question to you is: how can we make it easier, or more fun, or 
more motivating to contribute to Qt, and to help with making things better?


Volker


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

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Mark Gaiser]

On Tue, Feb 22, 2022 at 12:51 AM Michael Jackson <
mike.jack...@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.. ).
>
>
>
That sounds like a rough time and a developer nightmare.
While I don't have that experience (porting from QWidgets to QML), I do
have the experience from QML (Qt 5.x) with Controls V1 to Controls V2 in Qt
6.
The experience there is that components with the same names - making you
think you can easily port - have wildly different properties and in general
work just completely different.

Another annoyance are the component defaults. Those defaults are definitely
not suitable for desktop usage. Properties like selecting text or even
being able to edit it are off by default.
Need mouse support to select text?... You might or might not be able to
enable it. For a TextField you can enable it. For a SpinBox you can't
enable it at all. And there's so much more like this.


> 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.
>
>
>
But... I thought one of the big selling points for QML was - when it first
got introduced - that it had live updating capabilities.
I never used it but I thought it was a unique selling point.


> --
>
> Michael Jackson | Owner, President
>
>   BlueQuartz Software
>
> [e] mike.jack...@bluequartz.net
>
> [w] www.bluequartz.net
>
>
>
>
>
> On 2/21/22, 6:34 PM, "Interest on behalf of Mark Gaiser" <
> interest-boun...@qt-project.org on behalf of mark...@gmail.com> wrote:
>
>
>
> On Mon, Feb 21, 2022 at 11:11 PM Bernhard Lindner <
> priv...@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@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
>
> --
> Best Regards,
> Bernhard 

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Michael Jackson]

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.jack...@bluequartz.net

[w] www.bluequartz.net

 

 

On 2/21/22, 6:34 PM, "Interest on behalf of Mark Gaiser" 
 wrote:

 

On Mon, Feb 21, 2022 at 11:11 PM Bernhard Lindner  
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@qt-project.org
> https://lists.qt-project.org/listinfo/interest

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

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

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Mark Gaiser]

On Mon, Feb 21, 2022 at 11:11 PM Bernhard Lindner <
priv...@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@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
>
> --
> 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] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Bernhard Lindner]

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.

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@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Best Regards,
Bernhard Lindner

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

Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Mark Gaiser]

On Mon, Feb 21, 2022 at 6:27 PM coroberti  wrote:

> Hi Mark,
> The initial dev is slower when using Widgets,
> but with less bugs and more robustness, it could be worth doing it,
> and at the end of the day, it is even time-saving.
>
> The Qt apps on the desktop platforms you mentioned look very native with
> Widgets.
>
> There are many tips and ready solutions for Widgets you can find on the web
> to cut the time for the initial development.
>

Hi Robert,

Thank you for your reply!
I'm well aware of Widgets and it's looks, I've got quite some years of
experience with them:)

In fact, there's a "funny" thing with Qt here.
There is a QML component gallery [1] meant to demonstrate the components.
1. The compilation of that project takes _longer_ than the QWidgets gallery
demo [2]
2. You need to restart the QML gallery for theme changes where they are
right there on the fly in QWidgets.

Having said that...
The development speed and debugging is in fact faster in QML. It's also
much easier to change quite significant parts with relative ease.
Therefore I'd still like to go for QML.

But the components Qt provides are so bad that it's essentially impossible.
Hence I'm looking for components that integrate nicely in the platform.

Should I just consider QML to be dead[3] on the desktop now?

[1]
https://code.qt.io/cgit/qt/qtdeclarative.git/tree/examples/quickcontrols2/gallery
[2] https://code.qt.io/cgit/qt/qtbase.git/tree/examples/widgets/gallery
[3] As in when going for platform integration. If you go the full custom
route you're fine.

>
> Kind regards,
> Robert Iakobashvili
> 
>
>
> On Mon, Feb 21, 2022 at 5:44 PM 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@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] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[coroberti]

Hi Mark,
The initial dev is slower when using Widgets,
but with less bugs and more robustness, it could be worth doing it,
and at the end of the day, it is even time-saving.

The Qt apps on the desktop platforms you mentioned look very native with
Widgets.

There are many tips and ready solutions for Widgets you can find on the web
to cut the time for the initial development.

Kind regards,
Robert Iakobashvili



On Mon, Feb 21, 2022 at 5:44 PM 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@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] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

[Mark Gaiser]

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@qt-project.org
https://lists.qt-project.org/listinfo/interest