[Development] Input events handling ideas and feedback

[Shawn Rutledge]

Disclaimer: I'm writing some mix of personal opinion (which is subject to change anyway) and opinions that I’ve heard from others, in reply to this...

> On 27 Jun 2016, at 11:28, Uwe Rathmann <Uwe.Rathmann at tigertal.de> wrote:
> 
> On Mon, 27 Jun 2016 08:39:42 +0000, Shawn Rutledge wrote:
> 
>> We have mostly stopped working on QtQuick Controls 1, because the
>> implementation of Controls 2 is much more performant ...
> 
> Controls 2 are for "embedded" - what at least means to me: not being for 
> desktop applications.

Emulating pixel-perfect native appearance is always tricky at best.  But if you avoid doing that, you can still develop some nice desktop applications.  And lately, support has been added for the native menubar, and for platform dialogs and tray icons - those aren’t for embedded.

The trend is for every app to have its own design nowadays (even though the old guard of usability-oriented designers will naturally think that’s terrible).  People got used to diversity, and having to learn the UI of every app separately.  They got used to web apps: it’s so easy to make incremental changes there.  Visual designers have gotten the upper hand over usability designers.  Personally I use all the OSes (except for avoiding Windows a lot of the time), so I just have to adapt.  Even the OSes are in flux, so native app designs get updated periodically whether we like it or not.  Is there a backlash against all this change (much of which is completely gratuitous)?  Will there be?  I’m not sure.  What people enjoy and what’s optimal for them are seldom the same.  And AI is coming, so we can expect that more flux is coming too: AIs could be used to rewrite software faster; they might be able to optimize the human factors better (if people can make the AIs focus on that); and the UI which itself incorporates AI can be expected to be different anyway.  How soon will people begin to think about and agree on expectations for conversational interfaces: when and how do we want to talk to the software and when do we not?  Personally, I only want to talk to it if its motivations aren’t completely opposite to mine, if it’s not an advertising or surveillance platform first and a UI second, if I can be sure it doesn't record everything I type and all sound within my environment all the time, and send it to the cloud.

So with all that coming, is it really so important to accurately emulate the appearance of widgets on your OS-of-the-day?  Every year or so, it will change again, so it’s quite some effort for us to keep following along, copycatting their every move.  People who are so inclined sometimes work on widget styles, and then Controls 1 was reusing them to draw the native-looking controls.  It’s not a pure QtQuick way of rendering: the CPU has to do some of the rendering work.  Why couldn’t we keep doing that?  Controls 2 has C++ for behavior, and you do the styling in QML, so maybe someone will again write a way of reusing the widget styles to draw the controls.  It hasn’t been done yet AFAIK; maybe it will be.  And when UI designs (like Android Material) themselves incorporate animation, widget styles can’t express that anyway, so we have to emulate it via animations in QtQuick.

>> It was achieved by implementing behavior in C++ ...
> 
> ... and by dropping desktop specific features.
> 
> But does your statement imply, that Qt development has mostly given up QML 
> as a technology for the desktop ?
> 
> If true, was it done because of:
> 
> a) seeing Controls 1 as complete and satisfying
> b) something is wrong with the implementation of Controls 1
> c) the overhead of QML is too big for such large projects
> d) nobody is interested in the desktop at all
> 
> And what is recommended for us users: better starting off with widgets 
> for new desktop applications ?

There is probably disagreement on that, but I’d say it depends what kind of application.  If you are writing the same kind of application that you’d have written a decade ago, and you want it to look native and stay that way, then you never needed a “fluid” UI anyway (which is what QtQuick is all about).  And we keep fixing bugs in widgets, even though we don’t develop many new features, because there continues to be so much demand.  But if you want the same application to be portable to mobile devices, then widgets aren’t a great fit, because users don’t get what they expect.  So it bothers me that we don’t try to uphold the old write once deploy anywhere strategy anymore, because people think it’s impossible now - mobile and desktop are too different.  I don’t think it’s impossible, but we don’t focus on it so far.  There are so many app developers, and so much disposable software now.  If people don’t value their time so much that they want to write it only once and keep using it for years or decades on multiple platforms without redesigning it, what can we do about that?  And if they do, then widgets still work.  Maybe it’s worth the time it takes to have a really efficient pure-native application with no interpreters running.  And if you have enough experience using Creator and its built-in Designer, you can throw widget apps together almost as fast as QML apps anyway.

OTOH there is hope that the 2D Renderer is going to make QtQuick practical on platforms where OpenGL performance isn’t predictable enough.  (Although, how many more years are we really going to have trouble with GPU acceleration on any platform?  It’s been far too long already.)  And there is hope that the compiler replaces the interpreter, at least to an extent.

If you need a fluid UI, you’d better have GPU acceleration, IMO.  If you want to use the GPU to render the whole UI, you need the scene graph, so that it can batch draw calls.  But I suspect we could use some limited GPU acceleration in widgets - if the one thing you want to be “fluid” is flicking and scrolling, why not render the scrollable contents (or tiles from it) to texture(s), and let the GPU move them around during the scrolling?  We ought to be able to have that technique in the mainstream eventually.  Then widgets would be more tolerable for a while yet, and it might be more efficient when it works.  Somebody will probably point out a way that you can already do that, but so far you have to jump through whatever hoops to make it happen.  But making that mainstream hasn’t been prioritized.