On 4/22/12 9:14 AM, "ext d3fault" <d3faultdot...@gmail.com> wrote:
>Yes, it is strongly biased due to the wording. Fix the wording and post >it anyways. The numbers will not change. > >I got bored and drew a pretty picture to summarize my feelings for QML: >http://bayimg.com/jaooAAaDC > >Hope you laugh. > >But back to being serious. How can anybody in the QML camp argue against >this: Modern, Hardware Accelerated GUI Defining/Declaring/Creation does >not require QML/JS Interpreter/Virtual Machine. > > >It's like these genius' (QML/QtQuick is still brilliant) got so caught up >with what they were working on that they forgot the big picture: Hardware >Accelerated C++ GUI. Forcing the use of a declarative language, a JS >Interpreter, and a virtual machine just makes most of us want to stab >ourselves in the eye out of principle (our principles differ from yours). And who says that 100% of the code has to be C++? I bet you are also happily using Perl/python where it makes sense. .ui files in Qt 4.x are XML, yet nobody complains about these. Qt is about finding pragmatic solutions to problems. Yes it comes from a C++ heritage, but I don't see why we should limit ourselves to purely C++ if we can create better solutions to the problem. This complaining sounds a bit like all the C++ purists that think Qt is bad because it includes a code generator (moc) for signals/slots and properties. Yet they all happily use tools like flex and bison and don't write their parsers by hand. >To quote Lars, > >We want to make the usage of Javascript supported as well as C++ is >supported. We are not making it the superior way or even the only way. > > >...except that the javascript way currently is the superior way. If you >want a hardware accelerated UI (without hacking together your own... >defeating the purpose of using a UI toolkit), you are forced to use >javascript (QML). No, you should be using QML. That doesn't imply that you have to write any application logic in Javascript. As I said, use it as a better .ui language. You can still do all your app logic in C++ if you so want. When you ask for simply exposing all a C++ API to all QML items, you're missing a point. QML is a language that include states&transitions and a binding engine. The binding engine works on arbitrary expressions and needs some backend to evaluate these. That backend happens to be V8. I don't see a problem with that. You're also not complaining that we have PCRE as a backend to implement regular expressions. We are already exposing most of the the C++ APIs that make sense for application developers to use. Simply exposing the C++ interface of all QML elements won't buy you anything, as the most important feature of Qt Quick (bindings) still can't be handled that way. There's zero value in exposing the C++ class that implements the QML Rectangle element. There's nothing you can really do with it anyway. If you need to create your own QML elements in C++ we have QQuickItem and QQuickPaintedItem, which form a very good and solid basis. And as others already pointed out, we need to be careful as to what we expose in C++. Any API we add comes at a large cost (that you probably do not see) in terms of maintenance and limitations to what we can change because of binary compatibility. Cheers, Lars > > >d3fault > >On Fri, Apr 20, 2012 at 3:59 PM, <marius.storm-ol...@nokia.com> wrote: > >That's a strongly biased poll due to the wording. And it's missing the >points the Lars has been trying convey, but some seem to ignore. > >-- >Sent from my Nokia N9On 4/20/12 17:31 ext d3fault wrote: >*cough* > >http://qt-project.org/forums/viewthread/16465/ > > >Does Qt need a modern C++ GUI API? >-No, I am perfectly happy with QML, JavaScript, interpreters, virtual >machines, glue code, glue abstract and proxy object >-Yes, I¹d like the option of 100% native development without being left >behind with a last century GUI API > > > >Can someone put that poll, or at least a link to it, on the front page of >qt-project.org <http://qt-project.org>? > > > > > > > >_______________________________________________ >Development mailing list >Development@qt-project.org >http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
