[Development] The place of QML

Tue May 22 06:21:09 CEST 2012

DEFIB.

all of these are replies to comments in
http://labs.qt.nokia.com/2012/04/18/qt-5-c-and-qt-widgets/
which Marius Storm-Olsen decided to close

Donald
http://labs.qt.nokia.com/2012/04/18/qt-5-c-and-qt-widgets/#comment-72564
+ others
>We are putting serious effort into QML and hope to disrupt existing development paradigms. We are the same trolls we always were, and we are excited about our tech, like we always were. Shoot us. (I keep on seeing this straw man fallacy where people blame Nokia for our technical direction)

See: http://www.macieira.org/blog/2012/04/qt-project-statistics/
You being a 3rd party developer (thx btw (edit: wait I'm confused on
whether you're under Nokia's employ or not -- but it's irrelevant))
means yes, you do get to choose your own direction. You will always be
who you are, and you will always be excited about your tech. I don't
want to shoot you though. Keep making whatever you want. I'll keep on
getting lucky that I can benefit from your contributions (as well as
contributions from thousands (maybe millions someday) of others').
But how can you claim that Nokia does not drive the technical
direction? The move to open governance helped... but did not solve the
problem entirely. First, Nokia controls all Qt R&D funds (aside:
another company could do R&D for Qt... but they would then have to
allow Nokia to sell their R&D under a commercial license... while not
even being able to sell the [assumed-first-party] module under
commercial licensing themselves (not because they don't have the
rights to their own code... but because their contribution depends
entirely on the Qt library itself... which they (well, mainly each and
every one of their prospective customers... not 'they') need to
purchase a Qt commercial license for)). Second, the majority of the
'people in power' in the open governance project are Nokians. Sure,
the 2nd point is less relevant and time will hopefully change that.
Looking at the above Qt Project Statistics, you can see that Nokia
does the vast majority of the work on Qt. Although I don't have any
hard numbers, I don't think it would be much of a stretch to say that
over 50% of those Nokia contributors are working 8 hours a day, 5 days
a week on Qt Declarative, given it's size and ambition.
Nokia contributors do not get to choose what they work on (even if
they were the original Trolltech developers who invented Qt). The
corporation that is Nokia (*cough*irrelevant*cough* who happens to
depend HEAVILY on Microsoft for it's survival....
*cough*more-irrelevant-info*cough* who happens to hate Qt because it
directly competes with (and kicks the shit out of) their .Net
framework)) tells them what to do. Given the above numbers, it is safe
to say that Nokia is to blame for the technical direction. It is a
stretch to blame any of their business partners, however ;-).

One half of the argument: don't blame Nokia for Qt's direction
The other half (not made by you): Qt needs Nokia because of all of
their contributions
lol.

>QML bypasses the binary contract issue. I have personally ported a lot of code from QML 1 o QML 2, it was rather pleasant and involved me dusting off my sed skills. We do this via a hand behind the curtain which switched out the rendering engine and JS backend when you weren’t looking. You want us to drop the curtain, and yet still perform magic?

Yes, I do. The undocumented complexity of the QML->QtQuick
interpretation/structure-generation is [probably?] the main thing
stopping someone from writing a proper C++ front end to QtQuick.
As far as switching out the back-end 'magically'... ever heard of a
C++ interface? A v1 of a C++ Front-End to the QtQuickv1 back-end could
have been just as easy to port to the v2 C++ Front-End whenever
QtQuickv2 came about.

>You will find shouting at us as productive as shouting at people in the real world tends to be.

It seems hitting the devs with a barrage of logically sound arguments
is just as effective.

>Our (paid) development time is dictated strategically by technical concerns, a road map, laid out by technical people with a set agenda.

Nope. Sure, it might appear that way... but at the end of the day,
your boss tells you what to do.
The person who gives you money.

...the person who gives you money...
....the person you depend on.........
.....Nokia depends on who again.......?
<3 conspiracy theories xD

>If you were my manager, and assigned me task A, you would be happy with me working on task B instead because thousands (read 10?)

Bullshit, Donald. You and I both know that it's > 50% of the Qt
_users_ that want a C++ API. Nokia does too. Pro-QML camp just doesn't
want to be statistically called out. They're scared (lol @
kindergarten tactics) of the results. Prove me wrong ;-).

Dave
http://labs.qt.nokia.com/2012/04/18/qt-5-c-and-qt-widgets/#comment-72598
>I assume that if the people involved in the debate were capable of proposing a Qt-style C++ API for the QML functionality that the comment thread would look significantly different.

Incorrect. If the people involved in the debate were capable of
proposing a Qt-style C++ API for the QML functionality (meaning, a C++
front-end to the QtQuick back-end similar to the QML front-end), then
we'd already have a C++ Front-End to the QtQuick Back-End and there
would be no need for debate. The problem is that QtQuick is an
undocumented and complex beast. It's 'state of the art'. Without
QtQuick, QML is [essentially] worthless. The genius' behind
QML/QtQuick (yes, QtQuick was created with QML in mind :-/) are
[essentially] the only ones who know how it works... so they'd need to
be the ones to either a) create said C++ front-end, or b) properly
document the QtQuick internals (as well as overall design - what
happens when) so someone else can create said C++ front-end. Hopefully
this will be done after Qt 5.0 ships and we can begin playing catch up
with all the QML-specific functionality that has been created (lol,
talk about wasted effort. Qt is/will-be split in half).

QtQuick was developed with QML in mind, and also depends on it (for now).
QML was developed with JavaScript in mind, and also depends on it (for now).

We just want to hurry up and get both of those "for now"s out of the
way. Being fellow developers, we understand that decoupling a design's
dependencies is a lot harder than designing it to be decoupled in the
first place (say, for example, if QtQuick was designed with both a
QML/C++ front-end in mind). At this rate (and especially considering
the lack of interest from practically all of Nokia (hello Nokian who
agrees with us. I don't blame you for keeping your mouth shut. Jobs
are a hard thing to come by these days ;-))), it's going to take a
very long time before we have a C++ front-end to the QtQuick back-end.

Allegedly (according to Caspicse... although he suggests using it
directly like a troll), we just want a front-end to QtQuick that uses
QQuickView, QQuickItem, QSGNode and provides the QML functionality...
but in C++. Sounds easy... except looking at those 3 public classes, I
wouldn't have the slightest clue where to start. What's the difference
between an Item and a Node? They are both used interchangeably in
various contexts. Don't respond to this. Instead, put the
documentation where it belongs ;-).
I actually just spent a few minutes looking at the source code and
already found a problem with this approach: QQuickItem.h #includes
<QtQml/qqml.h> and <QtQml/qqmlcomponent.h> ... LOL WUT? QtQuick
depends on QML internally too? Great. That's as far as I read because
I already knew the design was fucked. lol @ 'decoupling' statement a
few sentences back.

Domino
http://labs.qt.nokia.com/2012/04/18/qt-5-c-and-qt-widgets/#comment-72628
>The decision regarding the C++ API seems to be based on the lack of resources and on time constraints.

"Lack of resources and time constraints" would also make an excellent
cover while still being true. It doesn't account for the fact that the
finite resources/time are already being used on something the majority
don't want.

What happens to QML/QtQuick if/when Nokia goes out of business this
year ( http://articles.businessinsider.com/2012-04-19/tech/31365445_1_nokia-ceo-stephen-elop-oil-platform
)? Ok probably bought out by Microsoft, but sameshit. We'll have an
unfinished/undocumented/incomplete QML/QtQuick implementation and
QML/QtQuick will be practically worthless. Microsoft will own the Qt
trademark at that point and will just sit on it (could be wrong, but
at the very least they're just going to ruin it more (could be wrong
again.. maybe Microsoft will see it for what it is and embrace/develop
it further, now that they own the trademark (pigs fly))).
QtQuick will still be too complicated to just up and create a C++
front-end for and we'd have to decide whether it's worth the effort of
reverse engineering the design of QtQuick or if we should create a
replacement from scratch using similar a design

Marius Storm-Olsen
http://labs.qt.nokia.com/2012/04/18/qt-5-c-and-qt-widgets/#comment-72629
>However, if you feel strongly for it, feel free to work on a code suggestion, submit it for peer-review and discussion at https://codereview.qt-project.org/

Oh, it's that easy eh I just come up with a 'code suggestion' for some
complex undocumented back-end and then just commit it and then it just
works just like that? What am I waiting for!?!?!?!? *codes randomly*
Thanks for closing the comments btw. More discussion is exactly what
we don't need. As you've pointed out, we just need 'code suggestions'
to be submitted from random independent developers.

d3fault