[Development] The place of QML

[d3fault]

On 5/15/12, BRM <bm_witness at yahoo.com> wrote:
> It would probably be good for a statistically significant poll to be
> officially done.
> I'd expect that it would probably have a 50/50 split, or may be a 60/40
> split in favor of QML
> as I do expect there is still a lot of momentum behind the QWidgets and
> QGraphics* frameworks.
> But I doubt that will happen.

The polls consistently show a 3:2 lead for C++ GUI... but I agree we
need a bigger sample size. I don't think even with thousands of votes
that the ratio would change much.
Thiago: can you use your godlike yet neutral powers in this "open
governance" project to put a neutral poll on the front page?
Really, the big issue is that Nokia has in effect killed the
development of the Qt (sans maintenance, bug fixes, small-medium size
features, and R&D that tries to solve Nokias financial problems).
...but there's no better way to emphasize that fact than to highlight
the giant split in a) what the Qt _users_ want and b) what Nokia wants


On 5/16/12, Robin Burchell <robin+qt at viroteck.net> wrote:
> On Wed, May 16, 2012 at 4:42 PM, Atlant Schmidt
> <aschmidt at dekaresearch.com> wrote:
>>  Qt "the product" may be developed by a meritocracy of devel-
>>  opers but it damned-well better respond in a more-or-less
>>  democratic way to the needs/demands of the consumers of the
>>  product. If it doesn't, those consumers will move on to
>>  using other frameworks.
>
> That isn't how reality works. You cannot tell me (as a volunteer) what
> I ought to be spending my time on any more than I can tell you what
> color to paint your livingroom. My interests dictate what I invest my
> time into, not random people on the internet. As a developer working
> on Qt, I will probably keep users' interests in mind, but at the end
> of the day, it's still my decision.

For individual contributors + 3rd party contributors, yes, nobody can
or should tell you what to work on. This is obvious. But Qt at one
point had people who were paid by investors to work on Qt. Improving
it, satisfying the _users_, etc. Those developers had an implicit
obligation to serve the Qt _users_. It was in their interest to do so
and their R&D would reflect it. Trolltech gets gobbled up and all of
the sudden the goal shifts from attracting more Qt _users_ (hoping
they convert to Commercial someday... or just contribute really) to a
highly experimental/obtrusive-to-existing-code/not-source-compatible+not-binary-compatible
Toy Programming Language (that is forced upon you if you want to use
the recent/updated/enhanced/efficient QtQuick) to hopefully save Nokia
in the mobile market (It won't. Microsoft has Nokia by the balls).


On 5/16/12, Thiago Macieira <thiago.macieira at intel.com> wrote:
> Even though the consumers cannot demand anything from volunteer
> contributors, there is a an important overlap between what the consumers want and what the
> contributors want to work on. Or, at the very least, there should be.
>
> If we, as the contributors, do not pay attention to what our users want,
> we'll produce a toolkit that no one wants to use. Therefore, it is in our best
> interest to keep the users present and happy with the functionality. That's
> the only way to ensure the long-term survival of the project.

I think it's in Qt's overall interest for a company to be responsible
for paying attention to what the users want. Nokia has the job but is
not performing it. Qt is suffering and will continue to suffer,
perhaps even until Nokia's inevitable death.

> But note also that the overlap is not 100% and will probably never be.
> Sometimes, users want too much, or don't know exactly what they want. There
> must be room for the contributors to exercise their imaginations and come up
> with new, revolutionary solutions.
>
> I firmly believe that QML is in that camp.

QML may be revolutionary, but it does not target the right camp. It
targets the designer/amateur-coder audience. "Awww, poor baby. C++ too
hard for you? Here's some meta-descriptive-GUI language where you can
use simple javascript statements/code to implement all your back-end
(and subsequently, perform non-trivial bindings)".
Where's the direct/developer/1337h4x0r interface to using the same
thing that makes QML so bitchin (QtQuick/Scene Graph)? QML _is_
revolutionary... it just isn't what the average C++/Qt dev (user)
wants.


On 5/16/12, Thiago Macieira <thiago.macieira at intel.com> wrote:
> We need a new architecture, which means building stuff from the ground up
> with it. It requires a scene graph with retained-mode painting.

Yes, QtQuick is this new architecture. I just wish it wasn't exclusive
to QML. I agree QWidgets should be 'Done' (because it is)... but it
shouldn't be just left their to die. Imperative Declaration of UI
structure from within C++ is how us programmers prefer to do it
(QWidgets C++ API). It isn't so much to ask for something similar for
the future of Qt GUIs (not just for porting ease... but also for
familiarity). The imperative declaration of GUI that C++ developers
like to use in QWidgets is there for a reason: preference (it might
also be the 'defining' way to do it... as in, the xml .ui might
translate into C++ calls, idk tbh). Don't remove/ignore our preference
and force your own.


On 5/16/12, Thiago Macieira <thiago.macieira at intel.com> wrote:
> On quarta-feira, 16 de maio de 2012 13.24.25, Atlant Schmidt wrote:
>>   The FOSS developers HOPE that their interests are congruent
>>   with those of the mere customers and at least in QT's world,
>>   there's some evidence that this is true for some customers
>>   but there is also mounting evidence that this is decidedly
>>   NOT TRUE for other customers, hence our current debate
>>   about QML Qt versus QWidget Qt.
>
> That's not exactly true. The debate isn't about QML vs QWidget. The core of
> the debate, as far as I can see, is whether there should be a C++ interface
> for making UIs with the new technology.
>
> I haven't seen anyone support QWidget itself in this thread. Moreover, I
> doubt most people know the challenges with enhancing QWidget further. Consider
> this: the QWidget & QPainter imperative painting technology is Done. It's not a
> matter of taste, it's fact: graphical technology has moved on.

Imperative painting is done, yes... but imperative declaring (how i'd
refer to the QWidgets C++ API) isn't.
I am sure someone can design a new imperative C++ interface (with huge
similarities to QWidget) that uses Scene Graph/QtQuick.

> But the point is that we need something new to take Qt forward and be the
> basis for the next 5-10 years. The suggestion so far is QML & scene graph
> and with a few tweaks it could be made to suit most people's requests.
>
> No one has suggested an alternative.

The suggested alternative is the Upgraded C++ GUI API! Nobody has
funded/researched/developed the alternative, however :(

> So I suggest we spend our energy discussing those tweaks I mention, what's
> necessary to make the technology more attractive to current developers, what
> the impact on maintenance will be, etc.

This C++ vs QML discussion is moderately important to Qt as a whole...
but what about the "I do not want to contribute" (and therefore I'm
assuming/extrapolating that others also won't) problem? I think that's
a much larger issue. Sure, who the fuck am I? I am an independent
developer who is a _user_ of Qt. I hope to one day be in the position
where I can (and want to) contribute to Qt. There are many like us and
Qt needs the individual developer to want to contribute if it plans on
staying ahead of the market. Ok maybe "needs" is a stretch (companies
can/will dump money into it for yeeeeeeaaaaaars, keeping it alive
support-wise)... but it will definitely improve the overall Qt
experience to have individual contributors WANTING to contribute fresh
ideas (without the feeling that Nokia would be wasting the profits
said contribution would bring to Qt) and code.
The Qt Trademark is what it really boils down to. The Qt Project needs
to own the Qt trademark, else it will always be shoveling money into
the black hole that is Nokia. How much power do the people "at the
top" of the open governance meritocracy really have? Can they change
Trademark agreements (doubtful)? How about specific portions of the
QCA (perhaps more likely)?


On 5/17/12, Peter Kümmel <syntheticpp at gmx.net> wrote:
> On 16.05.2012 20:31, qtnext wrote:
> So all you can do is using a system with a "obsolete architecture", diving
> deep into QML and writing your own desktop elements, or waiting another one or
> two years.

I think you hit the problem square on the head... except that a lot of
us don't feel like QML Desktop Components are the answer to the
obsolete architecture problem... so we're even more aggravated knowing
that we have to wait even longer for a solution. Maybe someone will
make a C++ interface to QML (using precompiler or whatever)... which
would be possible but makes me want to LoL at such a terrible design
decision. Thiago, are these the tweaks you speak of to make QML usable
for most? A C++ interface to QML + no-v8-requirement + QML bytecode
embedded in executable resources. I think I'd actually settle for that
(I'd just lmao at the toolchain). It just seems silly to have the QML
be the defining interface for communication to QtQuick. A QML
extension to a C++ interface (just like how [I assume] .ui XML
extends/translates-into C++ calls) makes much more sense from a design
and maintenance perspective (I could be wrong).


On 5/17/12, Peter Kümmel <syntheticpp at gmx.net> wrote:
> Then Qt Widgets is perfect for you: mature, stable API. You
> only would have a problem when you have to implement features
> which are much better supported by QML.

QWidgets may be more stable, but it is NOT the more performant of the
two. QML/QtQuick uses hardware acceleration whereas QWidgets uses your
CPU. Now tell me better which is better in an emedded scenario. For a
very recent example of a low-capable-CPU/highly-capable-GPU Qt 5
device, look no further than the Raspberry Pi. You can't get a Pi and
then use QWidgets. I mean you can... but then you're wasting the Pi. I
don't know what GUI language I'm going to write Pi apps in tbh:
Obsolete/stable/slow QWidgets or New/untested/fast QML/QtQuick. The
slow/fast difference will probably be visibly notable for certain GUI
events on certain programs -- most notably on the Pi.


On 5/16/12, Giuseppe D'Angelo <dangelog at gmail.com> wrote:
> The OP:
> - doesn't like the fact that QML has not a comprehensive C++ API;
> - does want instead that API;
> - doesn't like the CLA and the fact that he would be giving to Nokia
> more what Nokia gives him back under a free license;
> - knows that such an API won't come from Nokia "soon";
>
> The natural consequence is: OP: go ahead and create this technology.
>
> Make a startup, hire 20+ world-top-class developers, work hard for 1-2
> years, and release your product as a 3rd-party add on for Qt.
>
> You won't have to sign any CLA, and you'll be free to release it under
> any licensing model you want.
>
> And any bank will be happy to back your company, since, as you say,
> - it's ok for you / you're willing to run in the red for some time
> - the huge number of people wanting your product will make it
> completely repay for the initial investment.
>
> Does it sound good?

Sounds Great. Can you provide funding ;-)? I've already said that all
that's needed is a Charity/Business. But in saying this you are pretty
much admitting that Nokia themselves do not have a vested interest.
The mere fact that it should be contributed as a 3rd party module
should signal a problem with the Qt Project infrastructure. Do we want
Qt to have amazing 1st party/supported/maintained/tested modules or do
we want to have to rely on the community to contribute BASIC
FUNCTIONALITY (modern C++ gui -_-) through 3rd party modules?
A huge disadvantage (though also an advantage) would be that said
charity/business couldn't use the Qt Trademark. Their 3rd party module
would probably be specific to Qt. They could refer to Qt... but they
couldn't not call themselves Qt. Profits would suffer (this is also an
advantage because of the current work required to
support/maintain/fork Qt).


On 5/18/12, Uwe Rathmann <Uwe.Rathmann at tigertal.de> wrote:
> What I want to say with this is: speedup numbers heavily depend on the
> use case and often doesn't mean much for your application.

Well obviously. The difference is that hardware acceleration almost
always brings the additional advantage of freeing up the CPU.
Let's not even get started on how much better a GPU scales under heavier load.
Hardware acceleration can speed up your processes (not referring to
CPU processes... but the overall task) by an order of magnitude
compared to cpu-based rendering. 2.5x sounds like a safe low estimate
to me...

Hardware Acceleration is something the C++ and QML camp both
definitely agree on.
Uwe, if you don't think the performance difference between CPU/GPU is
that much... you should be perfectly happy sticking to the 'Done'
(which almost actually kind of means perfected... so long as you're ok
with obsolete) QWidgets.


to end,
Qt would never have appealed to me (maybe I would have landed on GTK+
instead idk) if the use of QWidgets required me to define my UI in
XML. This is essentially what QML is requiring.
d3fault