Responses to Qt 5 on the Labs blog
-
The Labs blog just posted a follow up to their announcement of Qt 5 plans.
"Responses to Qt 5":http://labs.qt.nokia.com/2011/05/11/responses-to-qt-5/
I think it's a great sign that they're so up front in their discussion of the concerns people raised to the Qt 5 announcement.
-
Oh, and there's also a new "mailing list":http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback set up so you can follow the discussion around Qt 5 as it develops.
-
I think moving far from a C++ based approach in favour of a pure, JavaScript like approach is a good way to move away a lot of developers. In such a situation, there is the risk of loosing sight of the main goal and moving toward a new, (more comfortable, of course) site that will sound like a goodbye for the old guard. I really (really, really) hope that with Qt 5, C++ side and Qml/JavaScript side will complement each other, nothing more.
Personally, I love to develop Qt based old style application and I'm against the new approach.
De gustibus non disputandum est, is it? :-) -
Nowhere is it said that the C++ interface will disappear or be downgraded to a second class citizen. It is even stressed that this interface will continue to exist, only the expectation is expressed that user interfaces will be designed using QML more and more in the future. I like creating user interfaces using C++, but I like doing business logic more (I also think that a lot more developers would rather do business logic than GUI design). I do therefore believe that if QML/Qt Quick matures, having a GUI designer using QML is way more efficient and more fun as well.
-
Yes, that's it. QML/QtQuick means separation beetwen thinking about the GUI and looking around for a solution. However I often develop using Boost C++ with Qt, because Qt is not always enough for the business logic. So, such separation means that someone will develop GUI for me using QML/QtQuick (JavaScript like approach) and I will say goodbye to Qt. As I said: a good way to move away developers! :-(
-
[quote author="skypjack" date="1305316640"] So, such separation means that someone will develop GUI for me using QML/QtQuick (JavaScript like approach) and I will say goodbye to Qt. [/quote]
Well, you still need Qt to bind the business logic to the QML. So it's not completely gone away from you.
-
skypjack: Are you volunteering to port Qt Quick to boost? ;-) How do you plan to move away from Qt when using a Qt Quick based UI?
I am not really into UI design myself, so I tend to think of QML as a variation of .ui-files... with the added benefit of it being more expressive, easier to use and above all human readable. To me it does not really matter too much whether I use Qt Designer or Qt Quick designer to draw up my UI.
If you do care about UIs, then you can do seriously cool stuff with QML that would be impossible with QWidgets. That cool stuff does not only look nicer, but can be used to improve the user interaction.
-
My Ambassador application, QSapecNG, has a CAD interface for electrical circuit design and I think it is quite difficult to made possible to do such kind of widget using QML/QtQuick.
So, in my opinion, moving far from a C++-based style (or widget like or what's your preferred name) in favour of a less complex approach will drive to control leak in regard of our GUI.
Otherwise, I think QML/QtQuick is a good choice for lightweight application (ie mobile software) but it is not always the better choice for desktop application. I need a more powerful solution, that's all.
I hope Nokia will invest on old-style approach as on the new QML/QtQuick technology, and not only on the latter.@Tobias: my approach is often to develop a core part of the software using C++ and Boost C++ libraries, when I find that Qt is not enough, then I can use those functions from within the GUI, developed as a separated part (ie using Qt libraries). Of course, an example is QSapecNG: it's composed by SapecNG (the core) and the Qt-based GUI (really, everyone can decide to develop a gtk-based GUI, for example). So, there is no need to port QtQuick to Boost C++, also in the case when I intend to use a QtQuick based ui.
ps: my english is terrible enough (really, sorry!) or you can understand me? :-)
-
Hi fully agree with skypejack, the C++ interface is needed. I also develope industrial Qt applications, and I can't think of moving all this to QML/QtQuick.
I think, it's good to have both ways possible. QML for those who need fancy UIs, and C++ for those, who need high performance, tunable, complex UIs. In our business, the customer does not care on fancy UI stuff, but his 10000 parameters in the table are important (or even more). -
Of course QML is not a silver bullet that will work for everything. Nobody is claiming that. We expect to stick with QWidgets for quite a long time in Qt Creator: We will not rip out existing QWidget based code just for the fun of using QML. But we definitely will use QML where it improves the user experience.
skypjack: I do bet though that you are not using QWidgets to draw the CAD area. You most likely are using a QGraphicsView for that or maybe even a custom canvas, aren't you?
So you are not really comparing "QML" with "QWidgets" but "QML" with "QWidgets mixed with QGraphicsView (or a custom canvas)". With QML you are free to do the same thing, using QML for the UI elements and embedding your CAD area into that.
Gerolf: You really should try QML... it is way more tunable than the existing C++ widgets. I am not even convinced about C++ being "high performance" compared to QML. All the critical code is in C++ even in QML. Yeap, adding a lot of Javascript code into the QML is going to have an impact, but you can get away with hardly any of that (really simple JS is optimized out, too) if you do not start to code your logic in JS.
Anyway, we will see what happens when we release Qt 5:-)
-
What are you speaking about? You are planning to develop something like widget using Qml/QtQuick, then I have to embed those items into a C++ old-style QGraphicsScene, that way mixing QML/QtQuick and old-style. At the end, I have to mantain that's... that's... oh, I don't know how to define this mix!!
No, if you want to say me that this is the way Nokia is planning for us, ok: I'm ready to say goodbye to Qt. I'm sorry.
I would like to develop using QML/QtQuick? Ok, that's all. I would like to develop using old-style C++ approach? Ok, I shouldn't use QML/QtQuick!! This is, in my opinion, the best way.
No forced mix for developers.
Don't you think so? -
I am a just a normal developer, so I do not even know "what Nokia is planning" for you. Sorry, I just do not play in that league! I just argue from the (little) experience I had with Qt Quick so far.
My point is that you are not using individual widgets for the stuff you draw in the drawing area. You have some kind of canvas (be it QGraphicsView or whatever) and the performance critical part is happening there. Of course you can write (in C++) one QML element that does similar things and use that in QML. Check Lars and Gunnars blog posts for details how QML elements will handle their drawing.
Feel free to use Qt Quick or use QWidgets if that is better for your use-case. Fact is you can mix both if you want to: QML sits on top of the QObject system which makes it really easy to integrate existing Qt code into a QML UI. I think mixing QML and QWidgets makes a lot of sense, especially if you want to use some of the options Qt Quick opens up for your UI in an existing application.
Seriously, take an afternoon, grab Qt Components and give Qt Quick a try. Evaluate for yourself what it can do for you (and what not:-).
-
[quote author="Gerolf" date="1305393350"]Hi fully agree with skypejack, the C++ interface is needed. I also develope industrial Qt applications, and I can't think of moving all this to QML/QtQuick.[/quote]Obviously you don't have to move them.
[quote author="Gerolf" date="1305393350"]QML for those who need fancy UIs,[/quote]It might be a bit short-sighted to declare that QML is only fit for 'fancy' user interfaces. I've seen demos that show that perfectly usable 'industrial type' interfaces are an option with QML as well as with widgets.
[quote author="Gerolf" date="1305393350"] and C++ for those, who need high performance, tunable, complex UIs.[/quote]What is not fancy about that?
[quote author="Gerolf" date="1305393350"] In our business, the customer does not care on fancy UI stuff, but his 10000 parameters in the table are important (or even more).[/quote]
Believe you me, your customer cares more about the user interface that you are trying to let others believe. The user interface is what gives your customer access to the important data. Access to important data needs to be clear, predictable and easy to do. If QML helps in making the access easier, more predictable or clearer than widgets can do, QML is what you should use. I don't know about you, but 10000 parameters in a table doesn't sound easy to use (parameters are there to be changed, no?). You'll be surprised at how delighted your customer may be when you improve the UI a bit, making it easier for them to use the program and predict what is going to happen. Then again, I don't know squat about your user scenarios. -
Tobias, I spent my QML/QtQuick afternoons some weeks ago. I don't like to speak about something that I don't know, so don't worry about. I am too just a developer and here we are to discuss about Qt future, really without any control over which will be the future.
So, nice to meet you and your opinion. Mine is different? No problem! It's a good start point for our discussion, again and again. Don't you think so? :-)My opinion is that mixing two approach is not a good idea, and making QML/QtQuick a comprehensive solution is quite difficult (someone says impossible?). QML/QtQuick is a really good approach for lightweight ui but it's far, too far to be a valid solution for complex ui like CAD interface. That's all.
Maybe in the future? I don't think so.
Made QML/QtQuick a valid solution for complex ui means drive QML/QtQuick far from the aim. -
skypjack: OK, let's agree to disagree. Will you be at the Qt contributors summit? Maybe we can share a drink and argue over stuff, be it Qt Quick or whatever:-)
-
Ohoo, I'd like to share a drink with you and argue over everything you want, really but I cannot participate to the Qt Contributors Summit! At work I used to develop with Java (it's a bank's partnership company, so they look at Qt like the devil) an my company cannot be a sponsor for me, in addition I'm not really a contributors for the Qt framework (be a Qt Ambassador is not enough, maybe), so I don't have any invitation.
If you would like to visit Florence in the future, I will offer you a beer!! :-)
