[Development] Question about Qt's future

[Joshua Kolden]

On Apr 21, 2014, at 4:39 AM, Roland Winklmeier <roland.m.winklmeier at gmail.com> wrote:

> Am 21.04.2014 05:27, schrieb Joshua Kolden:
>> I’m curious why you are not interested in QML.  
>> 
>> I’m just finishing up a an initial production release of software oriented towards high-performance graphics.  We used QML for the interface, coffeescript for view logic, and Qt/c++ for processing and business logic.  It works astonishingly well sine we can design and build the UI separately from the business logic, and designers can work interactively without a compilation step, while the business logic can worry about threads and other performance processing complexity without regard to the event loop, just throwing things over the fence to the UI when ready.
>> 
>> I see no reason to stay with Qt Widgets at all other than legacy application support.  So what is your concern?  Is it just that you don’t what to go from being an expert in the tools you already know to an beginner at new tools, or are you up to speed on QML and you have some details on why this approach is a bad idea?  I haven’t found any major issues, other then a few bugs and missing features that will be fixed soon enough. 
>> 
>> Please don’t read this as me being facetious, I’m genuinely looking for any information that would indicate the we are on the wrong path with our application design.
>> 
>> Thanks,
>> j
>> 
>> 
>> On Apr 20, 2014, at 6:40 PM, Michael Knight <jackdalton20000 at gmail.com> wrote:
>> 
>>> I feel like Qt is going in the direction of being Qml and Javascript only.I 
>>> fear that they may abandon Qt Widgets in the near future,I think they are 
>>> heavily promoting Qml.I don't want to use Qml,and before I start using Qt,I 
>>> want to be sure that they will not abandon C++ side of Qt and that they 
>>> continue to develop C++ side.It seems to me that they are developing Qml side 
>>> mostly. 
>>> 
>>> What do you think about this?
>> 
> 
> I'm working for a Flight Simulator addon project which was initiated 1
> year ago. When we started with the UI part, QML was heavily promoted in
> Qt5 to be the future of Qt and I also got the feeling that QtWidgets are
> not longer developed (except of bug fixing and minor features - but the
> focus is now on QML). I hadn't used QML or QtQuick before at all, so I
> looked into it and the demonstrations were indeed nice. So we started to
> design our UI with QML. I liked the design to split business logic into
> C++ and UI design into QML and I still like it, but I came across
> several blocking issues (some of them are only valid for our
> application, some of them are general):
> 
> - Our application has a huge framework of value classes. They cannot (or
> at least it does not make sense to) derive from QObject for several
> reasons. But subclassing QObject is the requirement to access data from
> C++ in QML. So we had our framework of well designed value classes and
> cannot use them in QML. There were evaluations to create QObject
> wrappers, but no nice solution. So no support for value classes is
> probably a show stopper for many projects. With Widgets we were able to
> use them easily.

Hmm, I’m not sure what you mean by value classes.  Do you mean literally data models?  You don’t need to move QObjects across to QML if you are just sending data for display in the UI.  We have lots of complicated data types that we simply save in QVariantMaps, and they show up as javascript objects in QML. You may not have this flexibility, but as the application designer on our project I don’t allow anyone to put new classes into QML from c++ unless they directly drive a viewable element, because that contaminates the view layer with business logic, following the MVC pattern.  I wouldn’t allow that with widgets either.

> - When we did our QML tests, I got the feeling QML in general is not yet
> stable enough. The performance was not always the best (e.g. scrolling
> in a table view was not smooth).

I agree, we’ve had some issues there too.  I’m still struggling with a signifiant drop in frame rate / smoothness with our app running on a macbook pro with retina display, and that’s a pretty beefy device to be having performance issues with.  However, we did discover there are lots of tools for optimizing that are not well documented, or at least don’t stand out well in the documentation. Things like cacheBuffer to pre-create objects out side the viewable area in some layouts and the layer properties for creating textures for elements that are not changing at the moment.  Depending on the elements they are replacing these tools may also save memory or use more memory.

More clearly defined optimization tools would be great.

> - UI components: QML did not have the set of standard UI components. I
> know this is currently changing with QQuickControls but one year ago,
> there wasn't much. So Widgets were easier to start with.

Yep, this is probably the biggest weakness for most projects at the moment I think.  At the moment you’re better off creating your own interface, which we have the luxury of doing for this app, but not everyone has the resources to do custom UI design.

> - Memory consumption: Even a mini example took about 70 MB of memory,
> QtWidgets need a lot less. This is not a complain, I know the JS runtime
> needs its initial memory. It was just one factor, because our
> application is running as an addon to Flight Simulators and they usally
> consum a lot memory. This is especially a major problem with MS Flight
> Simulator since it is only available as 32 bit application. Therefore
> every any MegaByte is important.

We don’t have this constraint so I can speak to it.  Our app seems fairly big in memory, but by no means approaching any limits on any devices we’re deploying too.

> Dont get me wrong. I'm excited about QML. Doing UI design in C++ is
> awfull and QML really would improve things. The current implementation
> is good for some projects, but it is not the solution for everything.
> There are still even new projects going back to QtWidgets (as we did),
> because QML is not suitable. So to me its not only legacy support.
> However I rethink my descision when most the above points are addressed
> in later QML versions.
> 

Yeah, for us the biggest asset and biggest issue with QML is that it’s the future of how this kind of stuff is done, it’s already much better than the way we worked before, but not every piece we’d like to have is in place yet, and some pieces are broken.  Nevertheless, that hasn’t kept us from selecting it for this project.  I just hope it doesn’t bite me on the ass, when our app hits the streets.

j

> ---
> Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv.
> http://www.avast.com
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development