[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 development at 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 documentation

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

This is a very valid point, and I don’t have a good answer for you. I agree that we have very little technical documentation, especially for the most complex areas in Qt. Writing architecture documentation or similar has never been part of the Qt development culture; not before Nokia, and not since. And most of the documentation we might have is probably out-dated.

I’ll discuss internally if this is something we believe needs to change.


7) Bug bounty system

> 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 don’t entirely agree with the idea that people only do stuff if there is a big enough carrot dangling in front of them. I personally don’t expect it to be a particularly effective tool. If you want to get paid to work on Qt - well, both we and many of our partners are hiring.

It’s an idea that has come up a few times before, and short of “nobody has time to set things up and follow up on the process”, there’s probably no reason no to try it out. However, that’s a pretty good reason, and if we had someone that had that kind of time, then I personally would rather want them to have a look at 1-6 first.



A bunch of things were brought up that I can’t or won't do anything about, so just for reference and maybe clarification:

8) “We pay for the license, we don’t have time to fix things”

Fair enough, this email thread is not for you. As a customer, you have better levers than email discussions on interest at qt-project.org. In The Qt Company we do generally prioritise bugs impacting commercial customers and reported to us through our support team. I have a deep respect for my colleagues in the customer support team, and know that they will represent your interests well when we need to decide what to spend our time on. That doesn’t translate into a guarantee that every issue can or will be fixed.


9) The CLA

It’s been part of the Open Governance of Qt since the beginning, and as I see it it’s going to stay for as long as The Qt Company is a product company that develops Qt to sell it, and not only because we need it to do something more interesting or profitable. I respect that for some of you it is a reason not to contribute. For me at least, the fact that we are a product (and not e.g. a consulting) company with Qt at the heart of our business and customer relations is a strong reason to work for The Qt Company.


10) Qt LTS being a commercial-only service

I understand why this was done, and having some insight into how laborious and expensive it is to maintain and release old branches I can follow the argument to make this a service reserved for customers. But I wholeheartedly understand that the fact, and perhaps especially the timing with the last Qt 5.15 release, sucks for many users and Open Source projects.

As a general clarification: the Qt 5.15 patch releases will become available under Open Source licenses eventually; the KDE Free Qt Foundation agreements guarantee that, as well as the continued availability of Qt under Open Source licenses.


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


Cheers,
Volker