On 9 Jan 2013, at 22:30, André Pönitz <andre.poen...@mathematik.tu-chemnitz.de> wrote:
> […] > A few questions that come to mind are: I think these are good provocative questions, and I will try to answer them with my personal opinion. > > - Which real world problems do we address? [By "real world" I > explicitly do include handset makers, and potential single- > platform interest in that area, but it's definitely not > restricted to those] Dynamic interfaces, with transitions and generally lot of dynamic layout. This is relevant especially for touch devices. > > - Given the just identified problems we want to solve, what are > the possible options to solve them? I think the pipeline of old style widgets is not adapted for this task I think. Still a similar approach (with a stricter UI/Code separation) could work. Apple for example went with that road. Qt now has a new pipeline for getting graphics and UI to the screen, but as far as I know no work is done to have a more "widget like" approach. QML allows rapid prototyping and easy editing. Personally I find it sometime blurs the ui/code line a bit too much, but with some care I think it is a good solution for the problem. Some extra constraints could be added to it without breaking what is nice in my opinion HTML5 can also be used for this purpose. It shares several advantages/drawbacks with QML, because conceptually the approach is similar. The main differences * it has a *much* larger developer/market share * it was not developed for this purpose, but is more and more used for that * Is cumbersome to write by hand, but many tools for it exist > > - Assuming that QML is one of those options, where does > it _theoretically_ rank in terms of > * implementation effort on the Qt side > * maintenance QML requires a much larger effort than the other options. Lots has already been invested, and extra effort is still required Having javascript in particular turned out to be a large dependency with all sort of issues, that makes for example iOS port problematic. All is being addressed, still it requires some effort. > * utility for the users I think it is useful for those wanting to develop those kind of interfaces > * migration cost for the users quite large, having desktop widgets libraries will help. QML *can* be used a bit like widgets, with such a library. I have no experience of porting normal applications, but I suspect the in most cases it might not be worth the effort. For *new* things, the major obstacle is to learn javascript and QML, and how to use that effectively, so basically the fact that it is new > > - Same as previous question: What's the actual state? > * what kind of effort is needed to make it "smooth" > from a developer point of view? > * what kind of maintenance effort do we face in the > long term? > * are users happy with it? > * how much effort did it take them to migrate? Work is still needed, QtQuick 1 is usable, QtQuick 2 just shipped. There are stumbling blocks, and things that could be better, for example iOS, Designer for QtQuick 2,… Still it can be used, and work is ongoing to address the problems And qml *is* used, and there are happy users despite all shortcomings. Especially for the early adopters there was some pain involved, but things ar ok in the end. (at least that is my perception without having done any survey). Is Qml worth the effort, as said personally, while I don't necessarily share all design decisions I think that the answer is yes, and I think that QML while it can be misused, it can also be used effectively, and we are learning how to do it. An important use case of Qml (smarphones,…) means that the UI has to be adapted at the space available. Thus being able to cleanly use a different layouts/ resources is good. Note that this pushes one toward a bigger separation between View and controller, QML and javascript. In fact speaking with developers some are already doing that, moving most of the javascript to a separate file. Qml can be cross platform, specific optimisation for a given form factor or platform should remain the exception (that is the reason I like the approach with user editable platform dependent paths that can override just a few files on a given platform). Fawzi _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
