Does Qt need a modern C++ GUI API?
-
bq. All I said is if Embarcadero provide official iOS and Android support, I can live with it, as it will beat having to deal with two different frameworks with inconsistent APIs for desktop and mobile, as I am forced to do presently.
Here are some infos about C++ Builder:
http://docwiki.embarcadero.com/RADStudio/en/FireMonkey_Application_Platform
bq. Visual Component Library (VCL) is an object hierarchy of visual components that are supported on Windows only (in Win32 and Win64 applications).
The VCL is the C++ "widget" library of C++ Builder - comparable to the Qt C++ libraries. This library is supported on Windows only.
bq. You can create FireMonkey applications that target the Mac OS X, Win32, and Win64 platforms.
...
You can freely use the RTL in a FireMonkey application, but you cannot directly use the VCL in a FireMonkey application module.So you don't have consistent APIs for Windows and Max OS. Linux is not supported in any way. Android and iOS support is not available yet - only announced. In my opinion C++ Builder does not provide real cross platform support if an important desktop platform like Linux is missing completely.
And regarding development of Windows 64 Bit applications with C++ Builder - forget it:
bq. (C++Builder supports Win32 and Mac OS X applications, but does not support Win64 applications.)
-
Cross platform support including iOS and Android support is also provided by the C# Mono Project:
I haven’t used it so I can’t say anything about its quality.
-
^^ - C# Mono performance sucks BIG TIME, which is the last thing either a user or a developer needs on a mobile platform with weak CPU and low memory. Heck, even Java is faster than C# mono, albeit with an ever more horrendous memory bloat. And on Android, with C# mono you simply add yet another VM to run on that poor hardware, it is certainly inferior to use a Java frontend with a native C++ backend with the NDK.
@Jayakrishnan.. - yep, I've been using Mosync, unfortunate it is not a complete solution either, it supports all major mobile platforms allright, but for some reason they decided to not support desktops.
I am also looking at Juce, which fully supports Windows, Mac, Linux since kernel 2.6, iOS and there is even an android port being actively worked on. It is not very expensive too. It does seem as the most viable solution for me at this point.
There are also a few lower level C frameworks that support Android and iOS, SDL for one, but it is strictly low level, no widgets, components or whatsoever, not even a complete painting solution, although OpenGL is supported and there are already a few OpenGL accelerated OpenVG implementations, which could be of use. It is still too much work for me right now.
Sadly, the APIs of all those alternatives are inferior to Qt, which kind of makes me sad Nokia purchased Trolltech, for if not, today we could very well have had a still C++ centred, more flexible Qt with official support for those platforms.
-
bq. Sadly, the APIs of all those alternatives are inferior to Qt, which kind of makes me sad Nokia purchased Trolltech, for if not, today we could very well have had a still C++ centred, more flexible Qt with official support for those platforms.
I'm not very sad that Nokia purchased Trolltech because I use the LGPL version of the Qt framework and this license is only available because Nokia made it available. That decision gave Qt a great boost and accelerated further Qt development.
In my opinion Qt is and will remain a C++ centered framework and QML won't change that. I think, if QML desktop components are released and the first GUIs based completely or partly on QML will popup many concerns about QML will dissapear.
-
I don't think anyone will argue that LGPL licensing is a good thing, especially with commercial licensing being so ridiculously expensive... But the LGPL license through Nokia comes at a steep price - no hope of officially supporting the most popular and profitable mobile platforms. On the other hand, it is possible that Qt would have been opened to a LGPL license even without Nokia, whereas the lack of platform support can concretely be associated to Nokia.
Also I don't think Qt is C++ centered any more. C++ is being shifted in the bowels, from a primary language of programming to a language of extending and writing custom QML components. I can see the merits of such an approach, but when chosen to be exclusively developed, I can also see many downsides, which arise due to the lack of an alternative native API, not a public one anyway.
There are many areas where QML is a winning combination, may I say applicable to the majority of developers and application scenarios. There are however the scenarios where QML is no longer an advantage and becomes overhead, the only way to avoid is depriving yourself from all the features that are exclusive to QML.
QML is similar to a LEGO constructor, you get a number of ready-to-use components with different shapes and purpose, elements you can easily and quickly achieve general results. QML is applicable for people relying on extensive reuse of a few either stock or custom components , but when you change the components from few to many and reuse from extensive to none, the outcome of the equation changes. In my more custom line of work, like that of many others, the number of components is very high and the amount of their reuse is very low, to the point interfacing the component to QML becomes an extra and wasted effort, designing and connecting an application on QML and native level is a wasted effort too. This just adds another layer of considerations and work that has no actual purpose. At this point using QML is no longer about the ease and speed it normally brings, but a tedious task just to get the new nice features which aren't being incorporated into the old, "DONE" native API. And all this doesn't really stack with the resource overheads of QML too, as minimal as they might be on desktop machines.
I for one don't think the issue of so many people with QML is a product of finding QML hard, fearing change or whatnot. QML is simple and in many scenarios - perfectly applicable with great results. But then again, there are the "deeper", more "out of the box" scenarios where you are faced with the following choice:
a) - deal with QML interfacing even thou you don'y really need to, spend extra efforts so you can use all the new ready-to-use features
b) - keep to the old API, avoid the extra work to interface components to QML but spend extra efforts to replace the beneficial aspects of Qt QuickSo, while an undisputed improvement for many, there are those, to whom QML adds extra efforts, whether they chose to use it or avoid it or use it. And surely, you are free to pretend like QML never existed and in this regard neither did all the benefits of Qt Quick and do everything yourself, but THE POINT of using a framework is not having to keep reinventing the wheel but take advantage of that huge team of developers who got paid good money to add features to it.
That is the reason I think so MANY people are in favor of a new native API - because for as long as QtQuick's nice features are exclusive to QML, users are put in a situation, where using Qt becomes less than optimal, either by having to incorporate QML's limitation in your design and interface your components to it, or by having to re-implement QtQuick features you lose if you chose to avoid QML. It is discriminatory to the needs of many developers, benefiting some while hindering others. And as it turns out, despite such scenarios being fairly rare, and most developers are after more trivial apps, where QML is an undisputed advantage, this poll indicates 2/3 of the Qt developers visiting this forum want an alternative. This is not surprising at all, since we are talking about C++, which is a complex and performance oriented language, after all, if a developer is after lush eye-candy, C++ is probably the worst choice, developers vote C++ when they are interested in deeper, more complex, more advanced and out of the box scenarios, in which the merits of QML aren't that pronounced but questionable and often - an obvious downsite. Qt made it easy to achieve results with C++, and it is just wrong for all those benefits to be redirected away from C++, the language that made Qt, both literally and figuratively speaking.
-
I think there are a lot of fears and "maybes" and "negative expectations" around QML that hopefully will vanish when QML matures and also the sceptical developers realize, that it is a good and easy solution that partners with QWidget very well.
I thinks it is no surprise that a lot of people have fears because of this completely new thing. This always happens when something new comes out - even when the first train hit the rails many people had the strangest fears. They will dissapear if QML meatures and if there will be books and best practices that will answer the open questions.
So I'm quite optimistic that also you will change your mind - maybe sooner, maybe later :O)
-
You seem to have troubles understanding English, I am not quite sure what gave you away thou, is it your wait on QML to "meature" or is it the fact you completely failed to address anything of my long previous post, and instead just repeated what you said your very last post.
There is no problem with QML being new, complex or anything like that, on the contrary, it is nothing hard, nothing complex, it is just not applicable in many scenarios, and what is worse, it is not applicable when it comes to programming complex, productivity related software with vast functionality.
It is not an issue of maturity either, no matter how mature QML will get, it will not get any more applicable where it is simply not designed to be applicable, high productivity, custom, specialized software is simply NOT an issue addressed in its fundamental design. Just like maturity will never make PHP as fast as native code and applicable for writing operating systems in PHP, QML will never be applicable to writing big, complex, productivity oriented applications. QML is perfect for the applications it is being showcased with - media hubs, frontend to web services, trivial applications with limited functionality and whatnot, in other areas it becomes a burden to use for the sake of getting the benefits that are exclusive to QtQuick, not included in the design of the old GUI API and hard to implement. You end up either bothering with using QML or bothering with implementing the things you lose by staying away from QtQuick.
And just you still fail to understand this, let me put you in a way language will not be a barrier for you:
!http://i48.tinypic.com/35jf9es.png(qmlsucks)!
In general, the idea of QML is to improve on GUI implementations. In trivial apps there is little business logic and GUI represents a big part of the total code. With QtGui you can very well end up with more GUI code than logic code in the case of trivial applications, and QML addresses that issue perfectly, cutting on a significant portion of the code.
BUT then again, there are the kind of applications where GUI is a miniscule part of the total application, a negligible amount compared to the logic. There is a high number of custom UI elements that need to interact with the core logic, but the overall GUI portion of the code is tiny, elements are responsible for their custom drawing. In this case QML helps you save on that INSIGNIFICANT GUI part but adds significant overhead having to interface the SIGNIFICANT component logic to it, so the little benefit if QML is totally displaced MANY TIMES OVER.
And again, to avoid language barriers, here is an easy to get visual representation of this concept:
!http://i47.tinypic.com/jpvw2d.png(youlose)!
Hopefully now you, as well as others who have problem understanding finally get it :)
The one big point you seem to keep on missing is that logic cannot always be isolated from the GUI, and in many creativity/productivity oriented applications you need to have it exposed to the user interface, and it is at this point where interfacing it all to QML becomes more prominent than the saving on GUI construction and QML miserably fails and becomes a burden you have to conform to for the sake of the technical benefits of QtQuick, which are absent from and hard to implement with QtGui. Or alternatively, you ignore QML and act as if no one moved a finger at Qt to make it better the last 3 years, both cases suck!
And even thou serious software is a minority compared to trivial software, it is still FAR MORE IMPORTANT, as it is far more productive to both its developers and to its users. In this regard Qt is simply turning its back on developers of professional software, which perfectly explains the voicing of concerns from such people here in the forum as well as in blog and lab comments.
-
Thank you for this detailed explanation. I appreciate, that you have put a lot of energy into this work - it is almost worth an own wiki page.
But I do not completely agree with your statements.
Depending on your application and what you want to do, you always need to choose the right tool.
If QWidget is better suited for some parts of your application, then you should choose widgets and use QML only for those parts where it is better suited.The point that logic cannot always be isolated from the GUI might be true - but you should always try to get a separation between GUI and logic. We developed a quite complex application in Qt with a lot of GUI and lot of backend logic or device control functionality.
"http://www.cetoni.de/products/microreaction-system-qmix/software.html":http://www.cetoni.de/products/microreaction-system-qmix/software.html
In this application we achieved a quite good separation between GUI and logic. And I think QML can even help you to improve this design princible of GUI/Logic separation. We used QWidgets for our application. But now more and more customers ask for touchscreen support to control their devices. And I think, we are going to implement this with QML because it is simply better suite IMHO for such an interface. That means, we are going to mix QWidget and QML - we pick the right tool for the right task.
You always need to connect your GUI with your business logic. If you call it "glue code" for QML it is o.k. but also in C++ you need to write code to connect logic and GUI.
I do not see the real big differences between defining GUI in a .ui file and in a QML file. You do not need to implement javascript logic in QML and can simply use it as a kind of .ui replacement.
-
[quote author="utcenter" date="1339619270"]BUT then again, there are the kind of applications where GUI is a miniscule part of the total application, a negligible amount compared to the logic. There is a high number of custom UI elements that need to interact with the core logic, but the overall GUI portion of the code is tiny, elements are responsible for their custom drawing. In this case QML helps you save on that INSIGNIFICANT GUI part but adds significant overhead having to interface the SIGNIFICANT component logic to it, so the little benefit if QML is totally displaced MANY TIMES OVER.[/quote]
Like what? -
"http://mobilecorner.funkruti.com/2012/06/qt-5-withdraws-support-for-symbian.html":http://mobilecorner.funkruti.com/2012/06/qt-5-withdraws-support-for-symbian.html
I wonder what platform Qt 5.0 will run on. Find the discussion here regarding Qt as a next gen mobile declarative framework rather amusing, considering the fact that there are no supported platforms.
-
The probably best answer is, although beeing quite unsatisfactory, be patient. There will happen a lot at Nokia within the next months, and I can understand the decision to not risk the possible waste of resources (especially on a platform, which is dead end in pretty much every scenario).
Windows Phone 8 will have native code support, which will most likely result in Qt beeing available, Samsung will be pushing Tizen, already having a Qt port and Neccessitas will at this point pick up pace again - which means Qt beeing available on almost any smartphone (and tablet and desktop platform) sold.
Elop is stripping out the family silver wherever possible to fund his highly questionable enterprise policy, but there is still commitment to Qt, which is most probably an indication that it is still a staple in their vision - which is clearly mobile for Nokia. We will know more as soon as either Windows Phone 8 or Meltemi is ready to drive the frequently invoked next billion (the new Asha devices powered by -Symbian- Series40 are just a temporary solution).
It is a rocky future (especially for Nokia and even more its employees, including those other 10.000 which "just got laid off":http://www.bloomberg.com/news/2012-06-14/nokia-to-cut-10-000-jobs-as-elop-tries-to-stanch-losses.html) but it is for sure premature to turn one's back on Qt.
-
-
@Uwe:
1 -You don't necessarily have to abstract a "different tool" on language level, especially when it is just a data structure description and the language is pretty much irrelevant, it could be QML just as well as it could XML, plain text or whatnot. A "different tool" can just as successfully be abstracted on API level, and indeed, the body of QML is not the language abstraction itself but QtQuick - the API abstraction. That is what this whole thread is all about - that same tool being publicly available natively instead of mandating QML, which is not applicable in all cases. QtGui is "fine", it is what I keep on using, but in that case you completely miss out on everything, done for Qt the last 3 years or so. That is the grand problem - QtGui is flawed by design, as a result, modernizing it is hard and awkward, QtQuick has the right design to enable neat modern features, but it is exclusive to QML without a public native API.
2 - Separating core from GUI is best practice, and I too follow it and separate those as much as possible, but there are the cases where "as much as possible" is very far from "completely" - my area is Audio/Video/2d/3d/CAD where all elements are two way interactive, it is not just a matter of user doing 1 data input and getting 1 data output after a ton of computations, most elements are not just data representation but alive components that are connected and interact with the entire application.
Your program looks really nice, it is always nice to see a designer has been employed and there is also aesthetics besides functionality, I am not a big fan of just slapping stock buttons and sliders, which will make an app just as functional, but without a feel to it. From personal experience, QtGui works fine on touch screens, even by sticking to regular events and not making use of explicitly touch events, which are more about pressure and gesture support, and it doesn't look like your application can take use of both. What I mean touch support enough is not enough to justify switching over to QML on its own, but you could just as well do it for the sake of doing it. Perhaps then you will share your impressions on porting it, even thou the application is basically a hardware controller, while I wouldn't call it trivial by no means, it is still far from the scenario where QML becomes a major pain in the lower back area ;)
3 - you seem to get "glue" in the wrong context. You always need to connect program logic to GUI, just in C++ it all happens on the same level, whereas with QML you have to interface everything to the runtime, so by glue I mean all this stuff you need to do on top of C++, wrapping, importing, proxies and so on. It is not that hard to do for a few components, but when components are numerous and GUI is just a tiny portion of the whole app, you get to the scenario I visually represented in my post, where the little overhead of QML gets multiplied by a much larger number of elements you have to do it for, and the big improvements on GUI implementation multiply by a tiny number:
"Small QML overhead" * "big number of components" = X
"Big QML GUI gains" * "small GUI relative to full app" = Y
X > Y
or QML overhead is more than QML gains4 - I don't really use .ui files or the graphical designer, I do for very basic things, for complex apps I build it in C++. That is the good thing about the old approach, everything is optional, you can do it in C++, you can do it in XML, you can do it with the designer, and worst case scenario is you get a single ui pointer to access the GUI through. With QML you don't have that kind of optionalily, and it is significantly harder to interface logic to GUI, you have to use wrapper classes, you have to export stuff to the runtime, you have to do workarounds for stuff like enums and so on.
-
..continued...
bq. Like what?
Oh my, it is you again, and what a comeback. Again, no offence, but you shouldn't be asking me this question unless you've been living under a rock for the last 20 years :)
The most significant thing that might happen at Nokia the following next moths is its cheap broke behind gets bought off by Microsoft. And I am not very optimistic that such a move will be of any good to Qt. We all know MS are not too fond of competing frameworks, especially not such with cross platform capabilities, especially not those, which allow TOP TIER HTC and WORKSTATION apps to migrate to other competing platforms, or, GOD FORBID" to FREE open source operating systems. I for one know of a few 5 digit price tag software packages that switched to Qt the last few years, which made MS quite "unhappy".
I am perfectly sure old Trolltech employees are still very committed to their product, it is not them but those on top of them I am worried about. Nokia was just fine a few years back when it purchased Qt, but today it is pushing to get into the big, warm, cash suffed bed of Microsoft, which could only spell trouble for Qt.
The last thing I want to see is MS purchasing Nokia's mobile business and Qt being thrown in the deal, it is a common practice to take over competitors to eliminate them and maximize market share. But even if it never comes to this, MS can still "influence" Qt through pressure on Nokia executives, at this point it surely looks like MS has found its open way into Nokia.
Funny that you mention Neccessitas - as it is a shining example of what community efforts can achieve, only that porting is much easier than creating an API. At this point Neccessitas is not a viable market solution, more of an experiment, like putting roller blades on a horse, you do it for the sake of making it work, but it is a long way from a complete and finished product you can rely on for more than just toying with it. Hopefully Qt5 and QPA will make it easier for Bogdan and that other guy, whose name I forgot, but seeing how Qt5 slips out of schedule is no source of optimism either.
This whole poll is about not turning our backs on Qt. Turning our backs would be just walk away, that is the WHOLE REASON why people insist on a new native GUI API so they DON"T get chased away, for turning the back on works both way, and the last few years it is Qt that turns its back on its developer base, that is why I feel it is IMPORTANT for Qt to address the needs its developer base voices here, so that neither Qt turns its back on us, nor we are forced to turn our backs on Qt.
But hey, at least now we have desktop components for QML, the one thing it was designed to help developers break free from
:D :D :D -
bq. it is what I keep on using, but in that case you completely miss out on everything, done for Qt the last 3 years or so. That is the grand problem – QtGui is flawed by design, as a result, modernizing it is hard and awkward, QtQuick has the right design to enable neat modern features, but it is exclusive to QML without a public native API.
I don't agree. QtGui works perfectly well for the current applications. During development of our quite complex multi plugin "Qt application":http://www.cetoni.de/produkte/mikroreaktionssystem-qmix/software.html we hardly had any problems with QtGui or QWidget and there was nothing we really missed - and if something was missing we could implement it quite fast.
So what are you really missing from the development of the last 3 years?? QtGui works perfectly well for current desktop applications.
And for the future user interfaces, there is already a new solution under heavy development: QML.
I do not see the need for a C++ API for QtQuick. But this does not mean, that I think there should not be a C++ API. Maybe a C++ API will come - you never can tell. But at the moment it is more important to focus manpower on further development of QML desktop components. If QML works perfectly well and desktop components are available than maybe a C++ API will come (although I dont think it is required and that IMHO only a minory of the developers would use it).
And as a software developer one should always be open to new inventions and new things. If a developer stops to learn new things and stops to be interested in new trends and developments he can quit. And I think QML is e really interesting new trend and it looks really promising - will it be a success - I don't know - will it fail - I don't know. But I'm ready to learn something new - because it is part of my daily job.
-
[quote author="Jayakrishnan.M" date="1339661577"]Hope your words come true. I guess the ' Asha powered by Symbian ' is a typo. Lack of progress in Necessitas has been disappointing. Lack of info regarding Qt4ios also has been disappointing. I hope both of them attains production quality.[/quote]
Me too. ;-) But there are actually more quite bad news (as far as I can see), escpecially for Meltemi (you've already found the article).
Yes, it actually is a typo, they are powered by Series40 6th Edition.
-
[quote author="utcenter" date="1339663530"]Again, no offence, but you shouldn't be asking me this question unless you've been living under a rock for the last 20 years.[/quote]
I've always been told that there is "... significant overhead ..." and a load of "... stuff you need to do on top of C++, wrapping, importing, proxies and so on..." and I've always been asking what this "... stuff ..." actually is and where this "... overhead ..." does come from and how relevant it is for the actual application.And even though I've never got a mentionable answer I still keep asking because although creating quite complex applications QtQuick has never required me to add a load of stuff nor did I suffer from significant overhead so far.
Yes, creating QtQuick items is different from creating a QtWidget - for the simple fact that the scene graph requires a declarative, state-based drawing model instead of the imperative drawing model we know from QtWidgets and the Graphics View Framework (which is also still available using QQuickPaintedItem). This is nothing a native interface would change.
But I'm quite sure you have some examples, code snippets, use cases, benchmarks or anything, which visualizes or materializes the significant overhead and the load of additional work, for me, do you?
Please don't get me wrong, I'm not beeing a drag here. I'm just in search of something I can actually look at to understand the worries (and to re-evaluate my perception if neccessary).
-
@Uwe - no one argues about how well QtGui works, as I said it myself, it is still what I use. The problem of QtGui is not with its functional aspects, but its fundamental design, which makes it less-than-optimal to create modern GUI. It is still possible, you have multi-touch, you have states, you have animation, it is just harder to work with it because it QtGui wasn't conceived with those things in mind and designed around them.
You keep insisting that developers who want a C++ API are a minority and efforts are rightfully focus almost entirely on QML, but this doesn't really fit with the opinions, voiced by the Qt developer base here in this thread. I am sure there are plenty who call for a C++ API for the wrong reasons, but there are also quite many who really see the fundamental design flaws of QML and its inapplicability in many development scenarios. You act as if QML is the best thing since sliced bread, but it isn't, and it is far from addressing all development scenarios. There are too many people for whom QML is unattractive, and focusing the development efforts of Qt entirely on QML is literally turning the back on those people. People like me are in a suboptimal situation whether we go for QML and deal with its overheads or stay with QtGui and deal with its fundamental design flaws.
@Lukas - I am not talking about performance overhead, that would be critical on mobile platforms, which QML doesn't seem to support any time soon, at least not the major ones. On the desktop the performance overhead is negligible. I am talking development overhead, where you have to wrap and export every program component to QML, something you don't have to do with QtGui. And again, it is not hard to do once or twice or even 10 times, but as the number of such elements increases so does the overall overhead, to the point it becomes more prominent than the savings you get from using those components in QML. Gosh, it is not that hard of a concept, why is it so hard to wrap your mind around it? It is an overhead that cannot be demonstrated with a code snippet, I am sure you know the workflow of interfacing native components to QML, the overhead is in doing it over and over again. It is not an issue of complexity that can be indicated in a code snippet, it is the total instances of snippets like that you don't really need but have to do in order to take advantage of modern GUI features absent from QtGui.
-
====================== C++11 version =================
@#include <QtQuick2>class OuterRect : Rectangle {
struct InnerRect : Rectangle {
MouseArea mouser;
slist<State> states;InnerRect(Rectangle *parent) : Rectangle(100,100), mouser(this) { colorChanged().connect(&ColorAnimation); anchors().centerIn(parent); mouser.anchors().fill(this); mouser.hover_enabled(true); states = { { "GreenState", mouser.containsMouse, { this.color, "green" } }, { "RedState", unary_negate(mouser.containsMouse), { this.color, "red" } } }; } } coloredRect ; OuterRect() : coloredRect(this), Rectangle(400, 400) {}};@
Quoting c++freeloader....
Simply beautiful