About c++,Qt,Qml,Qwidgets,broken morale

(I am not sure if this is the right forum section to post,but my question is towards passionate C/C++ programmers,so I decided to send my post under this section.)


Yesterday,I have read that Qt 5 gives programmers two options for GUI design,QtQuick and traditional Qtwidgets.
Unfortunately,to use QtQuick,you have to learn a Javascript like language called "QML".I've read that QtQuick has some additional features (some animation elements I think) which is not available with current QtWidgets,and that nobody is currently working on QtWidgets to improve it.So there is no Qtwidgets/c++ equiavalent of some QtQuick features.

Reading those,really broke my morale.My roadmap was after learning C,I would learn C++ and then I would learn Qt and combine them.But now,I heard about Qml.I've read that a Nokia/Digia officer said QT 5 still has QWidgets and that QtQuick is not superior to it.But unfortunately he also said that QtQuick is the better way to go.I fear that they they may avoid QtWidgets in the future and they may even develop QML more and may
discard C++ and other languages from Qt totally,who knows.

After doing some research on internet,I started thinking about other GUIs and programming frameworks.I like C++ Builder but
unfortunately,when I google it,or search in the forums(other than embarcadero's) for "c++ builder",the results make me think that C++ Builder is not popular,and also there is no new English book of it after it's acquisition and resurrection by Embercadero.All the English books I have seen about it are old books belong to Borland times.

What do you passionate C/C++ programmers do?Do you continue using Qt?What do you think about Qt's future,will they abandon traditional QWidgets in next versions or maybe even abandon c++ and other languages totaly and enforce QML totally?If you left using Qt,or have not been using Qt,what are you using for c++ GUI and API,do you recommend it?

I even started thinking to leave programming totaly or maybe starting Java,but when I faced with difficulties while learning programming,my c/c++ passion always kept me going,but I don't have this passion for Java or any other programming language.

Quote:

---

Originally Posted by Awareness

Yesterday,I have read that Qt 5 gives programmers two options for GUI design,QtQuick and traditional Qtwidgets.
Unfortunately,to use QtQuick,you have to learn a Javascript like language called "QML".

---

Why is that "unfortunate"? I haven't played much with QML, but from the looks of it it is quite easy to follow - Qt 4.7: Introduction to the QML Language

As for your fears, there is an established C++ API for Qt, and I really can't see future versions of Qt abandoning it. When it comes to newer features, it's up to the development team if they want to offer those using the older API or whether you will be required to use a new API, whether it's QML or whatnot. Is that really a big deal?

Quote:

---

Originally Posted by c99tutorial

I haven't played much with QML, but from the looks of it it is quite easy to follow

---

I have, and it is. it gives the programmer the ability to separate the interface design/behavior from the program functionality. this is a good thing.

Quote:

---

Originally Posted by c99tutorial

Why is that "unfortunate"? I haven't played much with QML, but from the looks of it it is quite easy to follow - Qt 4.7: Introduction to the QML Language

---

Because it's an entirely new language, not compiled and not statically typed? (As far as I am aware, anyway.)
AFAIK, it is possible to combine the two: QML and C++.

Stop being <language-x> programmer! <language-x> is a tool, you can have many of them -- what a concept!

If your passion is <language-x> and you're not a compiler developer, then you're doing it wrong! Your passion should be solving problems, not <language-x>. Carpenter's passion is not a hammer or saw -- it's creating beautiful furniture!

Seems like we can't agree,I am not a person who doesn't have favourites,I am not a very neutral person who sees things just as tools,and sorry I have a favourite programming language and I don't want to leave it aside and use another language...

Quote:

---

Originally Posted by Awareness

Seems like we can't agree,I am not a person who doesn't have favourites,I am not a very neutral person who sees things just as tools,and sorry I have a favourite programming language and I don't want to leave it aside and use another language...

---

Everybody has that mentality after learning the first language really well.
You'll get over this after learning and applying a few more languages and tools.

Quote:

---

Originally Posted by Elysia

Because it's an entirely new language, not compiled and not statically typed? (As far as I am aware, anyway.)
AFAIK, it is possible to combine the two: QML and C++.

---

"Not compiled" and "not statically typed" pretty much mean the same thing. Though, if QML is weakly typed, it will work like JavaScript, that way.

Newness doesn't matter if you're in Nokia's position because they could push QtQuick on you.

Quote:

---

Originally Posted by msh

Stop being <language-x> programmer! <language-x> is a tool, you can have many of them -- what a concept!

If your passion is <language-x> and you're not a compiler developer, then you're doing it wrong! Your passion should be solving problems, not <language-x>. Carpenter's passion is not a hammer or saw -- it's creating beautiful furniture!

---

I think the usual case is not that you like a specific language it is just that you don't like learning a new language up to a level to be able to do what you could do with another language. You invest on learning a tool and you expect your investment not to go to waste. So precisely because the carpenter has a passion of making beautiful furniture he doesn't want to spend time learning this new weird looking hammer. Learning a new programming language (really learning it) is not a trivia thing.

But I believe the message is valid nevertheless due to the fact that practically a software engineering job doesn't mean that all the time you will be writing code. You can be designing it. You can be debugging it. You can be documenting it. There are parts that will be the same regardless if the code is in Java or C++. If you don't like the rest of the parts, though, it will be hard to find a job that will guarantee that the main job will be coding. And when you find it you might have your manager walk in one day giving you the good news that you will now be the chief architect of the team where your job now will involve quite less actually coding to care if it is Java or C++...

Nevertheless, I respect any passion, if coding in C/C++ is what you really want to do then choose a field that C/C++ is the "master" language and that coding is the main thing to do. If you think GUI design is one of that, you chose poorly. I mean the "design" part should be a bit of a hint. If your passion is GUI design and C/C++ they you are a way too limited to avoid serious risks regardless what you choose to do. You might just need to keep your passion as a hobby.

Quote:

---

Originally Posted by Awareness

Seems like we can't agree,I am not a person who doesn't have favourites,I am not a very neutral person who sees things just as tools,and sorry I have a favourite programming language and I don't want to leave it aside and use another language...

---

You don't have to abandon one language to learn another, and neither do you need PhD in <language-x> to do something useful with it.

I don't understand the problem. Suppose QtQuick is really great but you just don't want to use it for some reason... it doesn't appeal to you. OK, then just don't use it. It's not like the existing API calls in Qt are going to disappear. In the worst case they will be deprecated, but then you will always have the ability to use a "legacy" version of the library that still has the functions you need.

A language is a tool, and for describing graphical interfaces, C++ is a bad tool. So you have QML.

The reason QML is better than C++ is that GUI's are hierarchal, and have a tree structure. But C++ (at least C++89) does not have a pretty way to write tree structured code and have that structure passed to functions. In QML, the structure and context of an expression is important, so the tree structure of code can match the hierarchy of the GUI.

You don't need to be a pro in QML, but you should use it, because it will result in better, easier to read and debug, code than any C++ you could write.

Quote:

---

after learning C,I would learn C++

---

Look at some examples of both, play around with a few tutorials, and then pick one of those two languages to stick with for at least six months.

Quote:

---

I fear that they they may avoid QtWidgets in the future and they may even develop QML more and may discard C++ and other languages from Qt totally,who knows.

---

"QML" is barely more than a declarative interface into the "Qt" library. (Honestly I don't even know why it isn't just a declarative interface. The use of JavaScript for actions is muddy. They could have provided that, but it could have been a different layer.) Still, point is, if you are worth your salt as a developer, you would have eventually written code to separate the look from functionality.

Quote:

---

I even started thinking to leave programming totaly

---

O_o

Well, that's foolish at a profound level.

If you are really that passionate, which you are obviously not, you'd have taken up the flag to maintain "Qt" for your own purposes. "Qt" is open source; they legally could not stop you so long as you abide by the terms of the license.

Quote:

---

If your passion is <language-x> and you're not a compiler developer, then you're doing it wrong! Your passion should be solving problems, not
<language-x>. Carpenter's passion is not a hammer or saw -- it's creating beautiful furniture!

---

This is true, or at least true-ish, but special familiarity with tools is a thing that exists and is perfectly natural.

If you are willing to explore, you'll eventually find a language that mirrors some of your natural process, and that language will become part of your passion because it lets you pursue the solution of problems with less effort. You get from though, where you should spend most of your time anyway, to good code that much faster.

Simply put, if you aren't attached to your tools, you need to find better tools.

Being able to use multiple tools effectively isn't the same thing as not being passionate about a specific tool.

Soma

Quote:

---

Originally Posted by phantomotap

This is true, or at least true-ish, but special familiarity with tools is a thing that exists and is perfectly natural.

If you are willing to explore, you'll eventually find a language that mirrors some of your natural process, and that language will become part of your passion because it lets you pursue the solution of problems with less effort. You get from though, where you should spend most of your time anyway, to good code that much faster.

Simply put, if you aren't attached to your tools, you need to find better tools.

Being able to use multiple tools effectively isn't the same thing as not being passionate about a specific tool.

Soma

---

I agree. The relationship between developers and their tools: languages, compilers, frameworks, OS and so on, should be one-to-many. Having favorites is good and even desirable; going all exclusive one-to-one isn't.

O_o

s/from though,/from thought,/

That reads... weird.

Soma

I still think they could give a nice equivalent of Qml Ui's advanced capabilities for C++ too,instead of reinforcing Qml...

One hour and I am still thinking why you posted here and not in the Tech board or in the General Discussion thread..

Quote:

---

Originally Posted by Awareness

I still think they could give a nice equivalent of Qml Ui's advanced capabilities for C++ too,instead of reinforcing Qml...

---

they do. from what I've seen, Qml is mostly used to draw the UI. yes, it has some basic event handling and scripting functionality, but it's mostly about drawing the UI outside C++ code, so that an interface can be designed and loaded at runtime without a recompile. basically, you would use the painting and event classes from the Qt GUI Module to do all the stuff that qml/quick does, at least with respect to drawing controls and handling events. that said, you can still load qml objects from C++ code, and use the C++ code as the backend event handlers and other such logic.

Not everything. QML has support for some animation features (if i remember/read correctly) not easily supported by QtGUI/QWidget. Internallly QML uses a scenegraph that makes use of OpenGL in a way that QtGUI doesn't.

My main gripe is, why didn't they add this functionality in C++ and then made QML an interface to those parts? As it is today you can not get this capability directly from C++ (without doing alot of lifting yourself). To me they just did things backwards...

Quote:

---

QML has support for some animation features (if i remember/read correctly) not easily supported by QtGUI/QWidget.

---

O_o

Would you be willing to give an example?

I'm not trying to be a jerk or anything; it just happens that to my knowledge, while the scenegraph stack used by "QML" was feature built for "QML", many engines are available to core "Qt" that use the same underlying primitives and shared drawing contexts.

Soma

Quote:

---

Originally Posted by phantomotap

many engines are available to core "Qt" that use the same underlying primitives and shared drawing contexts.

---

yes, but with QML, the possibility exists to define an animation in a few lines of QML code instead of potentially hundreds of lines of C++. I've only dabbled a bit with QML/Quick but designing an interface is far easier and quicker (pun intended, of course) than with pure C++ code, assuming no RAD GUI designer is being used.

O_o

Either you misunderstood me or I misunderstood him.

If we look at the "Qt" API, which animation features of "QML" aren't easily supported?

Are we talking about animations that are a part of the exported scenegraph API? If so, there exists several scengraph widgets for "Qt" that can trivially expose the same or similar facilities to C++.

Are we talking about a legitimately missing API reference/callback/hook from the native API to even enable such drawing? (An example might be displaying a rendered scene in a secondary widget, like a button, without jumping through the hoops of creating an "owner drawn" widget.) If so, a bug/request needs to be filed.

I seriously don't know which scenario here was intended. I'm used to working with a lot of API so both situations are familiar, but I was fairly impressed with "Qt". I wouldn't have thought that "Qt" developers would bother exposing an API layer only reasonably accessible though a first-party facility so I kind of just assume that the "heavy-lifting" is available as an API from within C++.

Soma

We are talking about QML providing functionality not available in the public Qt API. With the old way, QtGui, everything I did in the designer I could do in pure C++ by hand. I did not have to rely on anything at all outside of C++ and the MOC. This is no longer true for QML. I can not do something equivalent of

Code:

---

#include <QtQuick2>
...
QQRect *pRect = new QQRect(size, position, parent);
QQApplication::addToScenegraph(pRect);
...

---

I can not use QtQuick functionality in my own classes without going through the QML file, unless I want to use the Qt internal API which is not guaranteed to be binary compatible. Want to add a MouseArea to your own class? It is essentially not possible to use QtQuick without using qml files. Here is some more information: How to create an Item from C++ (without QML&#63;) | Qt Project forums | Qt Project

Why would you want to use C++ as your UI description language? Are you some kind of masochist? :p

Just describe the UI with QML and write the important part of your application (the logic) in C++.

Quote:

---

Originally Posted by CornedBee

Why would you want to use C++ as your UI description language? Are you some kind of masochist? :p

Just describe the UI with QML and write the important part of your application (the logic) in C++.

---

Well I must say I can enjoy some pain at times :P

I'm not saying QML is bad, I haven't used it enough to form any form of judgement of it. However I'd like the option of using pure C++ and not have go through the QML parts. QML also introduces a javascript runtime to glue interface events to C++. Again not saying it is necessarily a bad thing, however I would like the option to not have to go through javascript for this.

Quote:

---

Just describe the UI with QML and write the important part of your application (the logic) in C++.

---

I wouldn't necessarily recommend "QML" because I don't have much experience with it, but using tools that can design a "GUI" and build live is a solid win.

If nothing else, such tools can go a long way in simplifying internationalization and localization.

You ever spent hours tuning a "progressive display" "GUI" only to find that one of your target languages needs a much larger set of regions? I have.

Quote:

---

We are talking about QML providing functionality not available in the public Qt API.

---

That's what I thought.

Quote:

---

QML also introduces a javascript runtime to glue interface events to C++.

---

You'd do yourself a favor to look into other scenegraph widgets for "Qt".

Just because the "Qt" developers chose to expose their API through a dependency on a JavaScript framework doesn't mean you can't find a solution.

Soma

Quote:

---

Originally Posted by Shakti

I'm not saying QML is bad, I haven't used it enough to form any form of judgement of it. However I'd like the option of using pure C++ and not have go through the QML parts. QML also introduces a javascript runtime to glue interface events to C++. Again not saying it is necessarily a bad thing, however I would like the option to not have to go through javascript for this.

---

I had a similar experience going from Windows Forms into WPF/XAML and indeed the run time linking had an impact in debugging for example. When the gluing wasn't correct you don't get the nice "failed at this line" behavior. Also quite slower. It was annoying, you are not alone :) But you just get use to it and then realize the advantages you get as well. I almost always had the option to use code, though. Haven't touched QML but I would be curious if you can give an example of something that you are forced to do in QML?

Quote:

---

Originally Posted by Shakti

Well I must say I can enjoy some pain at times :P

---

I want to say there is "good" pain and annoying pain, but I guess we should just not go down that path