> On 2021 Apr 22, at 10:47, Rui Oliveira <rui...@hotmail.com> wrote: > What doesn't make sense, to me at least, is how QQC*1* seemed to have had a > better feature set for the desktop than QQC*2*.
The focus was on high-performance embedded use cases at first. Now we are working again on making QQC2 better for desktop applications. > QML/Quick, for me, seems to need a lot of work for the desktop. Also, it > seems it's make for "flat", low density UIs. Yesterday I was presented with > this: https://ossia.io/ . Look how good it looks > (https://ossia.io/assets/score.png)! Holy damn, an that's widgets. And that's > a proper desktop productivity application. I mean, if we look at like NeoChat > (https://matrix.org/docs/projects/client/neo-chat/), which is made with KDE > Kirigami (a Qt Quick framework extension), or the Telegram desktop > application, they look all nice and all, but they lack the density. That example looks like it has a lot of custom graphics. For some, you could use QQuickPaintedItem (as long as the repaint rate is not too high); for some, it would make sense to break it down into static image assets, and use BorderImage to make them stretch. Ultimately when you want complex and fluid graphics on the GPU, you need to educate yourself about the modern techniques (writing shaders and all the data that feeds into them). It’s such a learning curve that many of us still don’t know the best way to build everything we want; I’ve done some of that work, and I want to learn to do more, because it’s exciting to leverage the GPU to such an extent that the CPU is nearly idle, free to just take care of the business logic and the setup work. The “turtle graphics” approach is not going to get us there, but we know many programmers don’t know any other way. It’s only good enough for mostly-static graphics. I agree with the sentiment: don’t waste window space with whitespace, don’t oversimplify, don’t hide functionality that a lot of users need, don’t spread out conversations in chat apps just to make it look more “relaxed” at the expense of information density. But you can realize dense designs with Qt Quick too. When it comes to Controls 2 styles: we followed open, published design guidelines, which were made by contemporary designers with contemporary taste. But you can make your own style, and make it as dense as you want. Controls 2 consists of behavioral C++ code, with the rendering being done by instantiating Qt Quick items rather than by imperative QPainter code. Different styles have different sizes for each control. Using Controls 2 is not mandatory: you can build a whole set of controls from scratch using plain Qt Quick, that way you have as much design freedom as you want. Before Controls 1, it had to be done that way, so it’s been done plenty of times here and there. Some examples and manual tests in qtdeclarative have custom controls; the newest ones are in qtdeclarative/tests/manual/pointer/content. They were written to validate that Pointer Handlers could be used for that, not to make a complete set of controls; but you could learn from those and make more. The more customized you want it, the more I would recommend doing it that way. Controls 1 was also built that way (but without the benefit of pointer handlers): pure component architecture with as little custom C++ as possible. Certain mistakes led to performance problems, but IMO it does not invalidate the concept: it’s possible to write simple sets of controls that have most of the functionality and also good performance, especially if the control has only a built-in style rather than trying to load various styles. _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
