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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development