Does Qt need a modern C++ GUI API?
-
[quote author="temp" date="1334845740"] I actually asked mlong if it is possible to put the poll in a more visible place like the main page or something. This way it will bulk up faster and give a more definite view what percent of Qt developers are interested in a new and better C++ GUI API.[/quote]
Tricky. I'd rather not promote single threads, it will open a can of worms. And that is regardless of the topic. :P But of course, you're free to push it through your online channels, whichever they may be. :)
[quote author="mlong" date="1334848264"]In a perfect world, both options would be worded much more carefully (and neutrally.) It's very easy to slant a poll's results by the wording of the options. Some pollsters make a tidy living doing such.[/quote]
Writing survey (or interview) questions is an art. There are complete books on the topic.
-
[quote author="mlong" date="1334848264"]In a perfect world, both options would be worded much more carefully (and neutrally.) It's very easy to slant a poll's results by the wording of the options. Some pollsters make a tidy living doing such.[/quote]
I'll admit to giving directionality to the wording, but after all, QML is here to stay, it doesn't need justification, more important is to present its drawbacks, since those are a significant part of the reasons we need the option to skip all that not-really-necessary stuff. Also, the benefits of QML have been promoted at a large scale on DEV talks, the LABS and BLOG sections and what not, we all know the benefits but I never saw any blog post or tech talk focus on its drawbacks, so I did, for the sake of objectivity and restoring neutrality by providing the "other side of the story".
Also, in a perfect world Qt would have an awesome, hardware accelerated, fragment shader painting, openCL advanced blending C++ GUI, so this poll wouldn't even exist ;)
-
I voted "yes", but only because QML is not a golden bullet. But I'm also 100% sure that the Trolls know that.
And IMHO some people are just blowing stuff out of proportion when b..ing about Qt5 being too QMLcentric.
#1 C++ will always be a core language for Qt (I love C++ and can't imagine it being anyother way)
#2 Most of the time QML actually improves your software architecture by drawing more solid lines between the front-end and the back-end.
#3 It's not like C++ support has been dropped or anything. -
bq. Also, the benefits of QML have been promoted at a large scale on DEV talks, the LABS and BLOG sections and what not, we all know the benefits but I never saw any blog post or tech talk focus on its drawbacks.
Hmm, why not write such a blog post then, maybe with some benchmarks showing how terribly slow QML is, or how much glue code and proxy objects is needed compared to a hypothetical pure C++ API? I presume you have some experience backing up your claims?
-
I think that in a perfect world, C++ API and QML are equal. In addition, I would be happy if there is an easy tool for converting between the QML and C++ code. But the world is not perfect, so I say, "Yes, we need a native C++ GUI API". Maybe I even prefer it to be incompatible with the old one to make it faster and better, but without losing the existing features (AFAIK in Qt5 we lose some functionality of QMainWindow based on QWidget while having QWindow class).
-
If anyone believes that with C++ you can write modern GUI, so be it.
Wrong tool.
-
[quote author="minimoog77" date="1334961907"]If anyone believes that with C++ you can write modern GUI, so be it.
Wrong tool.[/quote] Nobody said that QML is not perfectly suited for it. Question is why Qt not follow the successful Apple native sdk policy. Or ... are Apple "iOS Graphics and Animation":https://developer.apple.com/technologies/ios/graphics-and-animation.html or "Mac OS X Graphics and Animation":https://developer.apple.com/technologies/mac/graphics-and-animation.html perfect native development kit ?
-
I voted with Yes. I do indeed like QML for creating neat UIs, but I think it's not the best approach to introduce a new design language for that task - or at least not in a C++ centered application framework. I would appreciate a possibility to access the advantages of QML from within a pure C++ framework without much coding overhead...
-
1: Since C++ cannot possibly be a viable replacement for a declarative language (like XML, HTML, JS/JSON et al), how is this "100% native" approach going to be solved - by publishing all private API's and possibly remove all the QML code?
2: Assuming this is what is called for, what is "modern" about making and emerging and unfinished C++ API public? Since this mistake has been repeated since the dawn of C/C++, wouldn't this rather make this proposal "old fashioned" and "unguided" instead?
Why not just use the private API's (or publish them at your own liking)? This is after all an open source project.
-
[quote author="minimoog77" date="1334961907"]If anyone believes that with C++ you can write modern GUI, so be it.
Wrong tool.[/quote]
What??? :):):)
Every serious software is written in C++, even the QML and JavaScript interpreter too.
A lot of (if not all...) high-level programming language compiler is written also in C++. The very new Win8 is written native C++ too. The Android and the iOS are written also C/C++.
An so on... -
C++ cannot describe UI in a declarative, structured way, nobody claims that, with C++ the developer must structure the design himself, BUT it is not that hard AT ALL, and it allows you to skip two extra languages, glue code between them and C++, and the CPU cycles and memory needed for interpreting and running a VM.
bq. #1 C++ will always be a core language for Qt (I love C++ and can’t imagine it being anyother way)
#2 Most of the time QML actually improves your software architecture by drawing more solid lines between the front-end and the back-end.
#3 It’s not like C++ support has been dropped or anything.1 - the problem is that "core" turns out to be low level logic. Let me give you an example - with QtGui everything you can do in the designer or with XML you can always do in C++, with QtQuick you no longer have that option, and unlike using the designer or XML, QML comes with a solid dose of various overheads
2 - I guess what you actually wanted to say is something like "draws more solid lines between GUI structure and application logic" - but not more so than for example HTML5, where you separate an application even further, you have structure, styling and logic, which is even more flexible. I hope you do realize the more a frontend is separated from its backend, the more overhead is induced? There is nothing faster and more efficient than using a C++ backend through its native C++ frontend. Even language bindings induce some overhead, not to mention the QML approach.
3 - C++ support on the low level has not been dropped, but C++ support for developing GUI applications is pretty much done, there is absolutely no indication Qt will dedicate any significant efforts into improving the outdated QtGui or change it for a better native GUI API@capisce - what would be the point of stating the obvious, I am quite sure you as well as others know the cost of running a VM and interpreting code, as well as being isolated from C++ and only be able to access it through gluing and exporting stuff explicitly. I never claimed the performance overhead of using QML is dramatic, just that IT IS THERE and there should be an option to avoid it. I am sure there must be some kind of moral gratification from people using what you designed and working in the way you intended them to work, but the wheel has already been invented, and inventing other shape wheels may not always be the best idea, sure it may work for some, but I for one would like the option to keep it native, and it looks like I am not alone in this.
bq. If anyone believes that with C++ you can write modern GUI, so be it.
Wrong tool.C++ may not be designed from the ground up to write modern GUI, heck it is a GENERAL PURPOSE LANGUAGE, so while it is not THE BEST tool to write GUI, it COMPLETELY SUFFICES to express any type of structure, be that of a UI or anything else. What people seem to fail to realize is QML is not code that gets executed, it is data that gets parsed by an interpreter which builds the structure entirely in the C++ way, the way I and many others want to be able to use Qt Quick.
If you think C++ is the wrong tool for you to write GUI, then by all means, DO NOT USE IT, but C++ IS THE RIGHT TOOL if you want to keep your application compiled to native binary, including the GUI, that is totally doable in C++. To you it may seem it is a tremendous difference between QML and C++, but whether you will inline an element into the body of another element to parent it in QML or whether you will create the element and pass a reference to another object in the constructor to parent it - it is not all that different, two different ways for doing exactly the same.
As I said in another thread, for people that are not used to C++ structure QML is easy since it allows you to describe the structure in code and have the interpreter build it for you. But many developers don't really need that tool to build structure. You DON'T DO PROGRAMMING IN QML, just because it is tailored to look like JS it is not a programming language, stating you program in QML is just like stating you program in XML, in both QML and XML you write data structure which some program will then read and do something with it.
So in the end it boils down to this - some of us appear to want the option of doing GUI programming rather than GUI describing. For describing GUI we already have tools that go beyond QML and are enjoying amazing worldwide adoption. It would have actually been better if Qt chose a HTML+CSS like approach instead of QML which mimics a programming language syntax but is a data structure language, which is a little backwards, and as I already said, HTML+CSS offers even more flexibility since you can separate structure from design. I honestly don't see enough benefits in QML to chose it instead of HTML5 for rudimentary app development. It has the benefit of being extendible through C++ but HTML+CSS+JS has many other benefits QML simply cannot offer like for example running on Android and iOS which totally dominate the booming mobile market, while with Qt the "running everywhere" is currently just an empty slogan that has little to do with the reality of the market.
Come on now, we don't even ask of Qt to be perfect, only to not be worse than MS and Apple, who do offer the option of keeping it native. Since when is it too much asking to be a tiny bit better than the world's greediest, monopolistic enforcers of proprietary technologies?
-
[quote author="broadpeak" date="1334990942"]
[quote author="minimoog77" date="1334961907"]If anyone believes that with C++ you can write modern GUI, so be it.Wrong tool.[/quote]
What??? :):):)
Every serious software is written in C++, even the QML and JavaScript interpreter too.
A lot of (if not all...) high-level programming language compiler is written also in C++. The very new Win8 is written native C++ too. The Android and the iOS are written also C/C++.
An so on...[/quote]The thing here is that C++ is a great language for all the heavy lifting that should be performed in the back-end. And QML is great to develop fluid and visually attractive front-ends.
So I my self have to agree that QML is a far better tool for the GUI, witch does not prevent you from performing most of the core operations using C++. That's actually a more modern and maintainable way of writing software if you ask me.
I think I shouldn't have to convince anyone that having your code neatly separated into a portable back-end and possibly multiple easy maintainable front-ends is a good thing.
Don't get me wrong I love C++, but some times having your entire application written purely in C++ is like firing a cannonball at a fly. Sure if you aim it properly you'll get to hit the fly and it's going to be spectacular, but than aiming it at a different fly will take far to much time and effort to be effective. (I know this is very exaggerated) (does “CODE LESS DEPLOY EVERYWEHERE “ ring a bell)
@temp you are wasting far to much energy on this (and sorry I have far better things to do than read your ... long posts write a blog or sth.) And IMHO Qt + QML is way better than what WP7 has to offer, so you're wrong when requesting Qt to be "a tiny bit better" when it's a hell of a lot better. Also if you think Qt is missing something no one is stopping you from contributing (IT'S OPEN SOURCE).
-
@temp: Have you even given the C++ API a try by using the private headers in QtQuick? Sure, for a couple of Rectangle and Text elements in a hierarchy you can do that easily from C++, but once you want to define custom behaviors, states, animations, and bindings it's just so much more convenient in QML that I believe many of the people who are asking for the C++ API would end up using QML in the end after all.
bq. with QtGui everything you can do in the designer or with XML you can always do in C++
The difference from XML and HTML 5 is that QML is very readable and pleasant to use even from a stand-alone text editor. Noone is forcing you to use Creator.
-
@kkrzewniak - as a tool, dedicated to GUI structure and design description, QML is the easier to use tool, there is no arguing here. The same applies to training wheels, it is surely easier to drive a bicycle with training wheels if you are new to it, but if you can drive a bicycle without training wheels already, then those become a limitation instead of а facilitation.
@capisce - No, I haven't, I don't know the internals of Qt Quick. If you don't mind, please do get a little more technical concerning techniques that will not be possible to do in C++, I am honestly curious. Property binding - I don't see an issue here, attaching states and animations - it depends on how is this actually implemented in the backend, something you could tell me perhaps, since finding out myself will require quite a lot of digging through a not exactly easy to read API. If it is done in the spirit of Qt, then I don't think it is that hard creating a state instance, attaching it to a parent, setting up and pointing it to the properties it needs to modify and connecting some signals and slots. No rocket science at all. Maybe a little harder than doing it with QML, but potentially a little easier (for programmers) since some of the work can be done in the very constructors of objects.
It all depends on how would an eventual C++ frontend will be designed. If out of spite for being forced to do it, your team decides to make a half ass job just to get it back at us, then sure, it has a very good chance of being too tedious to work with, and achieve a purpose it was designed with - to convince us QML is better. But I can also imagine an elegant way to do it, one that will make QML pointless for many people, which I don't think your managers are too keen on.
Surely, making it nicely fit with a C++ frontend MIGHT require some reworking, but it is your fault for not building Qt Quick with the idea of native usage from the ground up. Seriously, who writes an API in C++ without considering the most obvious option of using it natively? Someone, looking to enforce their own "language" for sure, but who else?
I cannot do a C++ frontend to Qt Quick myself, but I am willing to contribute to it whatever I can, and since I notice you as well as other people claim some stuff is not doable, perhaps I will be able to offer a workaround for those cases? Just post a QML snippet, accompanied by eventual backend catches that would make it hard to do natively, if there are such, and I will do my best to propose an elegant solution.
///
So what you want to tell me the main purpose behind the invention of QML instead of using already established and widely used standards is so that you can use Notepad for programming? Heck, there is a ton of text editors that support XML/HTML syntax highlighting and structuring out of the box or through a few clicks away downloadable extension, and I don't buy it that QML is any more readable than HTML, maybe to you, a person who has extensively used and potentially designed QML and may not have used HTML that much at all, but objectively it is about the same... Sorry but I am totally giving the edge to HTML+CSS, it is much more flexible, it is much more widespread and supported virtually everywhere.
I chose Qt for its ability to deliver applications in native code, and it makes sense I want that feature being improved on rather than being left just for compatibility purposes. If I wanted to lean on something like QML, I'd never bother with Qt, I already know HTML and JS, so I am good to go with trivial apps that will be supported on every major platform out there.
-
Qt has a had a C++ API for animations and states for some time, see http://doc.qt.nokia.com/4.8/qabstractanimation.html and http://qt-project.org/doc/qt-4.8/qstate.html
Behaviors in QML is simply an easy way to bind an animation to property changes: http://doc.qt.nokia.com/4.8/qml-behaviors-and-states.html
As for the QtQuick internals, see src/quick/items/qquicktext_p.h, qquickrectangle_p.h, qquicklistview_p.h etc. There's your C++ API, and you're free to use it as long as you accept that it's private API and thus offers no source or binary compatibility guarantees. I guess it could in theory be polished and made public if there is enough interest, but for that to happen it might be useful if people give it a try and offer feedback. I haven't tried to use these existing items from C++ myself, but I have made custom C++ QQuickItems for use with QML. I don't think the reason for not offering a C++ API from the start is malice, but rather a lack of resources and (until now) request.
An XML-based syntax was initially considered for QML, but dropped in favor of the more readable JSON-like syntax. HTML has a lot of legacy cruft, and no good support for animations and transitions without using WebKit specific extensions and such, and from what little I've seen the syntax is not ideal. I think most people using QML would not prefer to use HTML.
-
[quote author="cincirin" date="1334963428"]Nobody said that QML is not perfectly suited for it. Question is why Qt not follow the successful Apple native sdk policy. Or ... are Apple "iOS Graphics and Animation":https://developer.apple.com/technologies/ios/graphics-and-animation.html or "Mac OS X Graphics and Animation":https://developer.apple.com/technologies/mac/graphics-and-animation.html perfect native development kit ?[/quote]
What is the definition of native? For example is Angry Birds native? But if somebody told you that Angry Birds is using Lua for scripting then maybe it isn't? :)
Anyway, I am looking at this QML scaaaary thing like this:
You have a 2D/3D rendering engine which is optimizing the rendering on the GPU (scene graph). Written in C++. You can also add your own nodes (rendering yourself) if you want.
On top of that you have some kind of scripting language which defines the 'scene'.
Heh, it's like any modern game engine. :)
Also, you have easy (not perfect) access from scripting language to 'native' C++ objects and vice versa. Nice. So you don't need to write IDL. :)
-
[quote author="temp" date="1334993354"]C++ cannot describe UI in a declarative, structured way, nobody claims that, ...[/quote]
(just pulled the last quote regarding C++ and UIs, not replying to that post)
C++ is very capable of creating UIs in a declarative way, it is just that QWidgets are not implemented with that kind of API. One could create an API that would allow this to be a valid C++ code:
@window (
name = "winMain",
button (
name = "buttonBig",
size = parent.size,
title = "Click me!",
onClicked = something
)
)@--
p.s. If a "modern GUI" can be done in HTML+JS, it can be done in anything :)