February 25th, 2010 by
Daniel ElstnerAlthough I’m a GNOME and gtkmm guy, my paid work involves Qt. It’s no secret that I have a very strong antipathy towards the Qt mania to assimilate everything into their framework, the culture of their community, and their nonchalant abuse of the C++ programming language. Often, people suggest that I’m exaggerating the faults of Qt, and that there are much worse alternatives out there. Fair enough.
But today I happened onto another one of those little inanities which so often add up to a huge stinking pile. I decided to share this particular example, as I think it may help people to understand why I’m feeling so strongly about Qt.
A while ago, I filed Qt bug #5732, together with a patch to fix the problem. In addition to the fix for the central problem reported in the bug, I also provided a second patch to correct another problem I stumbled upon while I worked on the actual bug fix. The bug was acknowledged by a Qt developer and the code got fixed. They decided to fix it their own way instead of applying my patch, which is fair enough. I may not have agreed with the way it was implemented, but the problem I reported was fixed.
Today, I again looked at the Qt OpenGL code, and happened to stumble upon the OpenGL extension checks. Apparently, the extension checking had now finally been factored out into a separate class, with a more efficient implementation to avoid the numerous temporary memory allocations of the string splitting method that was used before. Of course I was curious and had a look at the code which implements the string parsing.
Here is how it looks like:
// This class can be used to match GL extensions without doing any mallocs. The// class assumes that the GL extension string ends with a space character,// which it should do on all conformant platforms. Create the object and pass// in a pointer to the extension string, then call match() on each extension// that should be matched. The match() function takes the extension name// *without* the terminating space character as input. class QGLExtensionMatcher{public: QGLExtensionMatcher(const char *str) : gl_extensions(str), gl_extensions_length(qstrlen(str)) {} bool match(const char *str) { int str_length = qstrlen(str); const char *extensions = gl_extensions; int extensions_length = gl_extensions_length; while (1) { // the total length that needs to be matched is the str_length + // the space character that terminates the extension name if (extensions_length < str_length + 1) return false; if (qstrncmp(extensions, str, str_length) == 0 && extensions[str_length] == ' ') return true; int split_pos = 0; while (split_pos < extensions_length && extensions[split_pos] != ' ') ++split_pos; ++split_pos; // added for the terminating space character extensions += split_pos; extensions_length -= split_pos; } return false; } private: const char *gl_extensions; int gl_extensions_length;};According to the log message the piece of code just shown went through internal code review. For comparison, here is the equivalent piece of code from my original patch, which was not considered good enough to be applied:
static bool parse_extensions_string(const char* extensions, const char* name){ const size_t name_length = (name) ? strlen(name) : 0; Q_ASSERT(name_length > 0); if (extensions) { const char* pos = extensions; while (const char *const space = strchr(pos, ' ')) { const size_t length = space - pos; if (length == name_length && memcmp(pos, name, length) == 0) return true; pos = space + 1; } return (strcmp(pos, name) == 0); } return false;}So, instead of just taking the code handed to them on a silver platter, the Qt developers decided to roll their own version. Which I wouldn’t even consider a problem if it weren’t for the fact that the code that went in is longer, less readable, and generally ugly. It’s also broken, because there is not a single word in the OpenGL specification about glGetString() always returning a list terminated by a space character, contrary to what the code comment claims about “all conformant platforms”.
Andreas says:
February 25th, 2010 at 18:51
Let me put into pseudocode what you did here:
g_hate_other_toolkit_with_reasons(G_OTHER_TOOLKIT(qt), G_HATE_OTHER_TOOLKIT_REASONS((not_perfect_code | rejected_submitted_code)));
really? says:
February 25th, 2010 at 18:53
geez… really? this is all you could scrape up? They fixed a bug that you reported, but your l33t, uber-efficient patch wasn’t applied? your ego is bruised, so Qt sucks…
Sure the code they came up with wasn’t very good code, but good grief I was expecting an articulation of some fundamental deficiency that causes the programming world to implode… but then I read this… grief… at least you mentioned the space termination on the glGetString(). I wonder what would happen if you report that as a bug?… Maybe they’ll fix it like they did your other report…
Daniel says:
February 25th, 2010 at 19:05
Oh wow, their function is 2 lines longer than yours.
Marcello says:
February 25th, 2010 at 19:05
> today I happened onto another one of those little inanities which so often add up to a huge stinking pile. I decided to share this particular example
I can completely understand how this decreases the motiviation of working with the project. I witnessed that Qt developers tend to work in a sort of enclosed fashion, which is probably due to their commercial background, but on the good side, still more friendly than completely closed companies.
I’m surprised commenters give such primitive reactions to a well told experience report.
Daniel Elstner says:
February 25th, 2010 at 19:06
@Andreas: yeah, that’s a good summary.
@really: Maybe you should read the post again. I just checked and the sentences where I explain why I post this example are still there.
Philip Van Hoof says:
February 25th, 2010 at 19:07
I must say, I don’t particularly like Qt’s C++ either, but “really” is right here. You can come with with far better arguments why Qt’s C++ is far from the painless language they portray it to be.
@andreas: that would require that GOtherToolkit subclasses GHate, though
, and then still is your G_OTHER_TOOLKIT cast wrong.
I think this is more correct:
GHateOtherToolkit *object = g_hate_other_toolkit_new_with_reasons(G_HATE_OTHER_TOOLKIT(qt),
G_HATE_OTHER_TOOLKIT_REASONS((not_perfect_code | rejected_submitted_code)));
xyzzxy says:
February 25th, 2010 at 19:15
@Philip Van Hoof:
g_other_toolkit_hate_with_reasons (G_OTHER_TOOLKIT (qt), G_REASON_NOT_PERFECT_CODE | G_REASON_REJECTED_SUBMITTED_CODE);
Daniel Elstner says:
February 25th, 2010 at 19:15
@Daniel: it’s the entire class, and it’s also broken. Anyway, it doesn’t really matter how much worse it is.
Maybe I should also point out that another reason for my antipathy against Qt is that their developers and even more so the community always go through a list of increasingly lame excuses before they finally admit that there is something wrong with a particular piece of Qt code.
Daniel Elstner says:
February 25th, 2010 at 19:16
@Philip: You, too, need to reread the post.
Roberto Alsina says:
February 25th, 2010 at 19:23
At least their code doesn’t have a
while (const char *const space = strchr(pos, ‘ ‘))
const char *const? I know what it does, I think but …. really? Complainaing that their code
Roberto Alsina says:
February 25th, 2010 at 19:25
Grmbl, got submitted by accident. I was saying
“Complaining that their code”… is uglier is like saying a specific piece of crap is uglier than another specific piece of crap, not because your code suck, but because this is C++ we are looking at
ethana2 says:
February 25th, 2010 at 19:50
C++.
Because people don’t know how to use native platform GUI toolkit functions from Java.
zomg says:
February 25th, 2010 at 21:03
And what exactly is wrong with “const char * const space”? I personally like the code. At least it gives the compiler more hints for optimization (probably irrelevant with newer compilers as they’re smarter anyway, but you could say the same about comments – who needs them?!).
Philip Van Hoof says:
February 25th, 2010 at 21:26
“Maybe I should also point out that another reason for my antipathy against Qt is that their developers and even more so the community always go through a list of increasingly lame excuses before they finally admit that there is something wrong with a particular piece of Qt code.”
That is indeed a far better critique. And I agree with this when it’s about Trolltech/Qt.
Daniel Elstner says:
February 25th, 2010 at 22:44
@zomg: The constness of the pointer has no effect on optimization in this particular case, because it is a local variable on the stack whose address is never taken. The reason I make variables const whereever I can is to tighten the laser maze of static code checking the language provides me with. I don’t have to read any further through the code to find out whether the value is ever modified. It’s a confident promise similar to an assertion, but stronger because it applies statically at compile time.
Apart from that, in my experience tripping over such seemingly odd declarations, and the analysis that follows, often helps inexperienced programmers to acquire a better understanding of pointers and their semantics. In the end it’s just plain old indirection, and if you don’t grok indirection you don’t get anywhere in Computer Science.
Anyway, all this has little to do with the topic of the post.
Daniel Elstner says:
February 25th, 2010 at 23:04
@Philip: Thanks for your partial support, but I must again take issue with your interpretation of the intent of my post. This blog entry is not and never was intended as a wholesale critique of Qt, the toolkit. As you correctly point out, it would indeed suck in that discipline.
This blog post is a snapshot of a moment in my daily life as a developer working with Qt code. Its main target audience are the people who know me and have to endure my frequent rants, but can’t relate to my frustration because they either aren’t involved with Qt coding themselves, or come from a more proprietary development background.
Murray Cumming says:
February 25th, 2010 at 23:16
The title is misleading.
Anyway, when I try to be positive, I like that Qt’s bug tracker is now open so you can at least report a bug now. But there’s a long way to go to actually working well with the outside world and getting the benefit of it.
Tim says:
February 26th, 2010 at 00:10
Well I think you have a point that your code is much clearer than theirs. However, I also think Qt is much better than GTK. For the following reasons:
1. The documentation is *amazing*. GTK documentation.. well… I suppose it is better than WxWidgets’.
2. The code is much clearer. No it really is. The above posts mocking the whole cast macro madness are spot on.
3. It doesn’t abuse the language as much. Sure they add the signals/slots thing; a slight abuse, but they are incredibly powerful and useful so I think it is excusable. In contrast GTK says “OMG object oriented programming is teh stupid… so stupid in fact, that I’m going to use a ton of ugly hacks to emulated classes in C.”
4. Much better cross-platform support. It’s native on linux (as native as GTK) and integrates much better in windows and mac. GTK looks stupid on windows and is a hassle to deploy.
5. More complete. It’s much more than just a GUI toolkit, and it’s still modular so there’s no ‘bloat’.
6. QtCreator is pretty awesome. Lacks some features at the moment, but it has *working code completion*!!!
Now that the licence issues are gone, I honestly have no idea why anyone would choose GTK over Qt. Can anyone give any real reasons?
Daniel Elstner says:
February 26th, 2010 at 00:55
@Tim, lay off the kool-aid… In any case, you crashed the wrong discussion.
Daniel Elstner says:
February 26th, 2010 at 00:57
@Murray: I’d say the title is a bit lurid. But it says “Why I hate Qt”, not “Reasons why Qt sucks”.
Henrik Hartz says:
February 26th, 2010 at 08:47
Daniel, sorry to hear you’ve had such a bad experience with your contribution. Your bug report is of far higher quality than what we traditionally receive (even with a patch!), and we’re very grateful for it! But, please remember that the reasons why we might re-factor code – or have strict reasons why not to change existing code, is that we have a large number of platforms to support. No, we haven’t gotten digested in the belly of the beast, and we still care about all the platforms we’ve historically supported
Not to belittle your post, but you bring up some technical reasons why Qt is bad (e.g. the nonchalant abuse of C++). While I’m not disputing that we do strange and esoteric things in Qt, those claims should be backed by tangible examples and just pointers to what we’re doing wrong. Without that, I really don’t see the merits or reasons of your claim other than spreading FUD.
Daniel Elstner says:
February 26th, 2010 at 09:17
@Henrik: See, your post is exactly what I mean when I say “increasingly lame excuses”. And about the accusation of spreading FUD: You must be kidding. One word: MOC. ’nuff said.
xxx says:
February 26th, 2010 at 09:51
@Henrik: hello? There’s nothing cross-platform in this piece of code. Must be what the author meant by “lame excuses”.
Mathias Hasselmann says:
February 26th, 2010 at 09:56
@all: Everyone trying to nail Daniel on technical issues is missing the point of this post. Daniel explicitly excluded technical merits within the first paragraph of this posting. The issue he describes here is a social problem. Let me summarize:
1. He found a bug.
2. He filed a bug with patch.
3. The initial reactions on his patch made him feel mobbed.
4. Months later he finally finds his bug report accepted and fixed.
5. When looking at the bugfix, the fix turns out to be over designed, and even worse: The applied bugfix is plain wrong.
And now to continue:
6. He talks about this feelings on his _personal_ blog.
7. He once again gets mobbed.
It’s time to start thinking. Seriously.
Daniel Elstner says:
February 26th, 2010 at 10:01
@Mathias: I wouldn’t say I felt mobbed by the reaction to my patch. What riled me up yesterday is this apparent “Worse is better” philosophy taken a little too literally. And actually, I want to be nailed on technical issues. Specific technical issues. Be my guest, tell me where the solution that went in improves upon my original patch.
Henrik Hartz says:
February 26th, 2010 at 10:08
@Mathias: Very good point. @Daniel: sorry for my being too defensive / confrontational; just wanted to point out that we do really try our best here in the belly of the beast
OP is a faggot says:
February 26th, 2010 at 10:27
OP is a faggot!
Let me watch you using Gtk with the same efficiency on multiple platforms.
Thiago Macieira says:
February 26th, 2010 at 10:37
Daniel
I’m sorry you’ve had such a bad time with the Qt developer community. I’m not going to try to justify why it happened to you. There are many reasons why it could have happened, most of which do not circle around “worse is better”. That happens to all of us in any number of projects.
Yes, we make mistakes; yes, we suck at community compared to some projects out there and we’re better than others (we never claimed to be best). We’re learning, just as anyone is.
PS: a discussion on moc and why it’s there to stay requires more than just comments on a blog. I’ve been meaning to write an entire blog on the subject for a while now.
Thiago Macieira says:
February 26th, 2010 at 10:39
And to others posting here: do not bring the discussion down to the gutter. It brings no benefit to doing that (worse: it actually casts a bad light on the side you’re trying to support).
Mathias Hasselmann says:
February 26th, 2010 at 11:11
Thiago: +1
Daniel Elstner says:
February 26th, 2010 at 11:20
@Henrik: You still don’t get it. I expect people to attack, and tell me in what way exactly my code sucks. In response I tell them why their code sucks. The goal of the game is to arrive on a solution where both sides have to grudgingly admit that the result is better than either original.
That is the style of working I am used to. What I am not used to is being addressed in the manner of a kindergarten teacher talking to a kindergarten kid.
Daniel Elstner says:
February 26th, 2010 at 11:30
@Thiago: Hi! Thanks for your honest reply. But please trust me when I say that this is not an isolated example. I am very disappointed with the general attitude to code quality I experienced in the Qt community. There is a lot of lip service being paid, but that’s where it ends most of the time. For example, there is a decent API design guide in the Qt documentation. I just don’t see its rules being followed anywhere in the core Qt API. One always has to keep in mind that the Qt API is already in its 4th generation.
Regarding
moc: Indeed, that’s not something that can be properly discussed in the comment section of a blog post.Murray Cumming says:
February 26th, 2010 at 11:55
> @Henrik: You still don’t get it. I expect people to attack, and tell me in what way exactly my code sucks.
Well, I wouldn’t want to see anything so aggressive. By all means be technical (you do) but people getting emotional about it is often what we’ve found leads to poor decisions in Qt.
Daniel Elstner says:
February 26th, 2010 at 12:00
@Murray: The exaggeration was intentional. Henrik, I’m not trying to attack you personally. It’s more of an attempt to drive home the point that this is more than just a PR problem.
Kazade says:
February 26th, 2010 at 14:12
Slightly off topic, but both solutions look pretty bad to me… does QT not already have string split functionality? Boost has a string split function that can be used with a std::string (and returns std::vector) but I figured that QT would have something similar. If so the code could become something similar to:
vector parts = split(extension_string);
for(int i = 0; i < parts.size(); ++i) {
if (parts[i] == std::string(str)) {
return true;
}
}
return false;
Maybe I'm missing something…
Daniel Elstner says:
February 26th, 2010 at 14:22
@Kazade: Yes you are.
String splitting was the intermediate solution that went in in response to my bug report. Which was fine with me as a choice of style, even though I didn’t like it myself. But later it turned out that the performance concerns are real after all, and the code was changed to do direct scanning as in my original patch. Now the problem is, it does it worse.
dipesh says:
February 26th, 2010 at 17:47
A review just for you;
static bool parse_extensions_string(const char* extensions, const char* name)
// this is C++, no_need_for_super_long_unreadable_names2
const size_t name_length = (name) ? strlen(name) : 0;
// strlen does check for NULL already. ++unreablable and ++unneeded
Q_ASSERT(name_length > 0);
// 3 line first bug. Why assign before 0 and assert now?
if (extensions) {
// to late. if extension can be NULL then this needs to be checked the first line. Also its better to “return false;” direct.
const char* pos = extensions;
// first line that looks fine
while (const char *const space = strchr(pos, ‘ ‘)) {
// hard to read. Split it into 2 lines
const size_t length = space – pos;
// second line that looks fine
if (length == name_length && memcmp(pos, name, length) == 0)
// hard to read. Split it into 2 lines
pos = space + 1;
// theird line that looks fine
return (strcmp(pos, name) == 0);
// remove the additional ()
return false;
// forth line that looks fine
Daniel Elstner says:
February 26th, 2010 at 17:51
@dipesh:You have no idea how much of a fool you just made of yourself.
dipesh says:
February 26th, 2010 at 17:52
> const size_t name_length = (name) ? strlen(name) : 0;
> // strlen does check for NULL already. ++unreablable and ++unneeded
s/strlen/qstrlen/
> return false;
> // forth line that looks fine
Indeed not fine cause that would have been moved to the top as sayed before. So, only 3 lines are okay from my pov.
Daniel Elstner says:
February 26th, 2010 at 17:55
Thanks for demonstrating your understanding of code quality. I fear there are too many mediocre programmers of your type in the Qt community.
really? says:
February 26th, 2010 at 19:23
I’m sorry dude. I’m trying to see through to the constructive, credible criticism in your post and your comments but it’s all smoke and mirrors now. It starting to look awefully similar to the same old tired formula seen on talk radio (the current bastion of trollitude):
1. Find some arguably legitimate point of criticism.
2. Mention the legitimate point in passing while articulating a full blown trollfest.
3. Pretend to be all flabbergasted when everyone decides to call you out on the trollfest.
4. Use the entirely predictable response as “proof” that no-one wants to discuss the arguably legitimate point of criticism.
5. Troll some more to get more “proof” until everyone is bored with you.
6. Rinse and repeat.
To anyone who recognizes the arguably legitimate point of criticism, trust me, there will likely be little to no response to any reasonable attempts to discuss that point. He’s on step 5…
To the OP, if you actually even care to have your concerns addressed, don’t expect people to respond constructively to being called being called fools and “mediocre types”. If the style of working you’re use to is to attack and be attacked and somehow magically find a solution in the middle of all that, then be aware that many people rightfully refuse to work that way.
Daniel Elstner says:
February 26th, 2010 at 19:26
Sorry, but I expect people who boast to nail me down on the technical issues to actually be right.
Jörgen says:
February 26th, 2010 at 19:49
Sometimes I feel that blogs are the year 2000+ version of the 90′s talk-show phenomena.
This really reminds me off an Arabella Kiesbauer show
Daniel Elstner says:
February 26th, 2010 at 19:51
@really: Also, if you look closely you’ll notice that the heat of my replies is a function of what and who I am replying to, and not a periodic cycle as you suggest. Let’s just say I’m not above shooting back in kind.
For the record, while I do believe that “dipesh” is a fool, I should not have suggested that he’s representative for all of the Qt community. Admittedly I went a bit over the line on that point.
Daniel Elstner says:
February 26th, 2010 at 19:52
@Jörgen: Good point — I haven’t watched TV for ages, so that may explain it.
Alex says:
February 26th, 2010 at 23:37
This sounds exactly like the kind of complaints people make about the gnome community. “They have problems! I submitted a bug and they ignored it/fixed it wrong!”
Daniel Elstner says:
February 27th, 2010 at 00:44
OK, now that I’ve calmed down again, I’m going to analyze dipesh’s “review” in detail now. I still think it’s ridiculous to analyze a comment of that quality at this level, but since I got called on having just dismissed it outright, I have little choice.
Overall, what makes the reviewer a fool is that her criticism does not address the logic of the code in any way. Apart from arbitrary and inconsequential reordering, the control flow remains the same. It’s analogous to picking on spelling mistakes. Except that there were no spelling mistakes, but at best minor stylistic quibbles. In her zeal, the reviewer made a number of embarrassing mistakes of her own.
Now to the points made:
I interpret this as an attempt to prove a point by taking a stab at the length of method names in
GObjectC code. The reviewer appears to be under the mistaken impression that I come from a C background. This mistake could have been avoided if the reviewer had read the first sentence of my blog post. And for taking a stab atGObjectmethod names, there is a crucial element missing here: The class name as part of the method name. Fail.Nope,
strlen()does not check forNULL. The reviewer later corrected herself toqstrlen(), which is equivalent to the expression above. Except that I would have to consult the Qt documentation to know this. Fail.Because it catches both
NULLand zero-length strings. Alternatively, I could have split the sanity check into two separate assertions, or I could have used an expression likename && name[0] != '\0'. Neither alternative is obviously superior, and the choice boils down to a matter of taste. Fail.That would mean moving it above the assertion. Assertions on input parameters — also known as preconditions — should ideally be evaluated independently from the normal control flow, so that the code checking functionality does not depend on arbitrary runtime conditions. The suggestion to return immediately is just a minor stylistic quibble, and I personally prefer to use moderate levels of nesting to visualize the structure of my code. Fail.
The problem here is best demonstrated by showing what the alternative would look like:
const char* space;while ((space = strchr(pos, ‘ ‘))) {Which is harder to read, makes it less obvious that the assignment is intentional, does not allow for the Resource-Allocation-is-Initialization pattern, makes it impossible to declare the value constant to tighten the code, and unnecessarily extends the scope of the declaration. Fail. Another alternative would be an infinite loop as used in the code which went in, which however forgoes the expressiveness of a directly stated loop condition.
The condition as a whole is still fairly short, so I fail to see how this is hard to read. More importantly, the length comparison and the
memcmp()call are strongly coupled, as both combined implement a substring comparison. Splitting the test into two nested conditions would only help to obfuscate what the code does. Fail.Minor stylistic quibble. It’s a habit of mine to always put parentheses around outermost conditions, even where the grammar does not require it. I’d happily remove the parentheses if requested.
It feels ridiculous to discuss these matters of style in such meticulous detail. Good style is important, but good programmers should be able to arrive there intuitively. I do not consider these minor stylistic quibbles highly relevant to the subject of this blog post.
Daniel Elstner says:
February 27th, 2010 at 00:53
@Alex: I bet it does. What’s your point?
Richard Dale says:
February 27th, 2010 at 02:38
I can’t get too worked up about which of the fixes for the QGLExtension bug is the best.
But for those people who aren’t so familar with Qt, here is a more typical way you might write it when efficiency isn’t so critical:
static bool hasExtension(const char* extensions, const char* name){foreach (QString str, QString::fromLatin1(extensions).split(' ')) {if (str == QLatin1String(name)) {return true;}}return false;}To me this style of writing C++ looks quite readable and high level.
Daniel Elstner says:
February 27th, 2010 at 03:01
@Richard: Yes, as already said, this was the intermediate solution which has now been replaced again due to performance concerns.
Chris says:
June 9th, 2010 at 15:24
@Daniel: you’re just frustrated…and lame
I couldn’t hate Qt/moc/community, because the end-product is just G-R-E-A-T
Daniel Elstner says:
June 9th, 2010 at 15:45
@Chris: Frustrated? You can say that again. But thankfully, not anymore. For the time being I don’t have to put up with Qt’s inanities.
I happen to care a lot about getting the details right, and very little about marketing bullshit. If you think that’s lame, then you have indeed made the right choice with Qt.
Ricardo Santos says:
December 28th, 2010 at 15:30
Why does qt provide its own strlen (qstrlen) and strncmp (qstrncmp)? If a system supports C, then it will have strlen and strncmp as part of its standard library, and on some occasions done on optimized assembler.
Why inline the match function? Is large enough to put it on its own source file. And what is the need of the class in the first place?
Why not an assert to check if str is NULL?
Why not a “for(;;)” instead of a “while(1)”? for(;;) does not check anything, while “while(1)” could possible check for 1 every time.
Also, when doing a check is good to put the constant in front of the variable. Why?
consider “if(a = 1)” is valid even when you meant “if(a == 1)”, while if do “if(1 = a)” the compiler will throw you an error.
I agree that there is some crappy code on QT. But that is not reason to hate it, maybe to fork it, but not hate it.
Daniel Elstner says:
December 28th, 2010 at 15:45
@Ricardo: To be honest, I don’t care nearly enough about Qt to be willing to fork it.
I’d rather work on something else.
Anyway, have a happy new year!
ad says:
February 11th, 2011 at 09:00
I am also required to use Qt at work. It is a decision made by bunch bonehead people before I joined the company.
First of all, C++ required very skillful programmer and understanding of OO and patterns, and architecture. The entire software fall apart because of incompetent C++ software developers. It has became unmaintainable, inflexible, slow, and inconsistent. You thought one would see something wrong with the picture when all developers spending 90% of time fixing bugs and 10% of the time improving usability or adding new feature. Qt framework is awkward in fitting well with software developing process.
I don’t mind C++ but people who use the tools must be competence. You might think I am arrogant saying someone incompetence. I always believed we should respect all coworkers because people bring all sorts of skill to the table. I still respect them as people but no longer competence software developers. In this case, if you see a small part of the code and the developing process, you will know what I am talking about.
You see why Nokia is in declined? They adopted Qt over other UI platform.
Take me with you if you find somewhere else.