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

Петр artifeks92 at gmail.com
Sat Feb 26 18:31:51 CET 2022

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 <volker.hilsheimer at qt.io>:

> 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
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest


Best Regards,

Petr Mironychev

artifeks92 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20220226/1a6a4836/attachment.htm>

More information about the Interest mailing list