Qt’s commitment to C++?



  • @Andre - I am sure with your programming experience you can conceive moving this block of code to a class definition, you can also add pointers and dynamic memory allocation to the mix, your thinking it will break down smells more like wishful thinking, C++ is inconceivably better at building immense dynamic program structures QML will most likely never even be the foundation of in its lifetime.

    There was a call for objectivity in this discussion, but apparently it was only regarding me, as your previous post is anything but objective. I work in a company that churns out dozens of UI designs each and every month, and in my 8 years of experience there was not even one assignment to request the expression of a UI in a non-graphical representation, and hey, we do that for a living. And this is professionals at work, surely, if you want to be "special" you could probably do it in Morse code, but since UIs are to be looked at, it is only logical to go for a graphical approach which gives an instant idea of the interface instead of having to parse lines of code, trying to IMAGINE what it would look like. You are simply coming up with more and more absurd ways to justify the enforcement of QML, which is fairly biased of you, but entirely in the realm of the expected.

    I've been using Flash extensively for like 4 years, only recently backing down on it due to corporate decisions - there are generally two types of flashers - flash designers, which use the graphical facilities of Flash to design, and flash developers, which use designs created by designers as a graphical representation to implement via code. This is the professional way, as nonsense as you may find it.

    And... umm, no, ActionScript is a C-style syntax language, it is far from being similar to QML, and so is the MXML atrocity, which although declarative in nature is an XML style language. MXML is just as pointless, introduced for the sake of simplicity without being all that simple at all, plus it is only suitable for object structure, all functionality you still have to implement in ActionScript, which you have to add extra tags to embed in the MXML, so there is a lot of overhead both in code length, code readability and that "simpler" way actually requires you to learn more syntax to to the same thins you can do with AS alone.

    At least MXML is just an alternative to AS, just as QML should have just been an alternative to C++. So while Adobe might have done stupid and pointless, AT LEAST THEY DID IT RIGHT.

    You are right thou, since QML is a parsed and interpreted language it can be interfaced, but QML is not UI description, it is UI implementation, and if you are willing to pick nits, you could twist it and say the implementer only describes the UI to the API and the QML API implements it on the fly, but this does not change the concrete fact every professional UI begins as what is usually a PSD Photoshop file, which can later on be implemented as a functional UI in any language out there, probably with the exception of machine.

    What I miss is the option to use C++ to access the new GUI API of Qt that gets all the attention and development efforts, that is the point of using a framework - tapping into what it offers. And surely, C++ is supposed to be an imperative language, but object orientation actually makes it much more dynamic than an old-school imperative language.

    Could I introduce a C++ API for the same technologies as are underlying QML - technically, probably yes. But it would cost me tremendously more time and effort, whereas it would cost very little to the full team of people who designed, implemented and are intimately familiar with the API. I spent a full year learning Qt, don't think the decision to walk away comes easy, but I will have significantly easier time implementing a similar API from scratch than the effort of plugging it into a vast and complex API I am not familiar with.

    But I get the reasons behind the absence of such an API for C++, it would have made QML optional, which would inevitably lead to a much weaker adoption compared to now, when it has been made mandatory, and after all, whether you are capable of admitting it or not, this whole endeavor is to establish QML not to ease us developers. There is no ease in having an additional language, additional glue code and additional performance overhead, if you know C++ you can already to everything you can do in QML, surely, in a different, but even more powerful and performing way.



  • @Lukas Geyer - I often feel like you guys don't even bother reading and trying to understand the base of my complaints. Here you go, stating what I've been complaining all along, that the old C++ APIs are... old and unsuited for today's needs, which brings us to the point we need a better API, which brings us to the point the solution is there but exclusive to QML, leaving C++ GUI development behind.

    You ask how can we bind properties at run time, well I think it is possible, the underlying C++ API behind QML seems to do it, and you seem to be trying to convince me that QML DOES IT ALL, but QML is just an interface, it is words, it is not even code that gets executed, it is just interpreted and used to control the QML API, which is C++, and the JS API, which is written in C.

    bq. And all this stuff does not come for free. Each of these classes have to be QObjects

    Oh yeah? And which QML component doesn't have AT LEAST a QObject behind it? Which custom QML component doesn't require to inherit AT LEAST a QObject if not any bigger interfacing class? I mean, really? This is a lousy form of argumentation..

    Network transparency - well, thanks to pointing out yet another aspect QML is better than the C++ API, simply because the same feature has not been implemented there.

    Everything else - it can be done in C++, it wasn't skipped on because it is impossible, but because of a decision not to do it. I don't thing QML has an advantage when working with threads, it has the advantage of having its API threaded, which is yet another benefit it exclusively get, leaving the C++ APIs behind.

    The reason doing all those new things in the OLD C++ is hard is... because it is old and not really designed to do them, that is not a feature of QML to make those things possible, it is a feature of its underlying API. You make it sound like a QML feature simply because that C++ API is only accessible through QML exclusively, which, for the n-th time, is a design decision not a must.

    Now runtime optimization - this I give to you, you cannot optimize compiled code, so finally, score 1 for QML.

    My mention of Metro also contained the qualifier "sucks", I didn't mention it because I think it is awesome, but because it is a modern UI API that allows native access. And as bad as it is, I am willing to bet ANYTHING in just a few months its user base will exceed even the wildest dreams behind QML. I am not familiar with its internals and very vaguely familiar with its interface, mostly because I am not interested in platform limited APIs. No doubt as a native support API, Metro has a much larger footprint which does mean it will take longer to learn it all, but chances are you are not going to have to learn it all, just because it offers more features than QML doesn't mean you have to use them all. The same applies to C++, you can be a fully proficient programmer by keeping it to 5% of the C++11 specification, the rest if there if you so choose, entirely optional unlike QML. Qt as a whole has a very steep learning curve, it has so many APIs, but it is a fact you don't need to know them all, you only need to know those you need to use.

    bq. But let’s turn the tables. Where is your evidence that this was a pure political discussion? Where is your evidence that Qt Quick is 10.000 times slower than pure C++? How would you implement all the core features of Qt Quick in C++? How can you make sure that this is more efficient then using QML?

    Here we go again, putting words in my mouth - can you quote me stating QML is 10000 times slower? Didn't think so, as this statement was regarding Python performance I profiled in a specific computing task. Luckily, QML is supported by a C++ API compiled to native code, and it is not that much slower, but still it is slower, uses more memory, more CPU cycles, plus needing a running VM which all is avoidable by keeping it all native.

    bq. Maybe someone is idolizing and idealizing C++? It almost smells like “fanboyism”.

    Now you are just being a parrot, how mature of you. I remember explicitly stating that C++ might not be the best tool to do this, but it suffices and has quite a lot of advantages QML could not possibly ever match. Your (lack of) objectivity only equals the lack of a C++ interface to use like 90% of the innovations Qt has received the last year. Isn't ironic, since you are the one who called for objectivity to begin with? I never claimed C++ is perfect, it is you who claims QML is invaluable even thou it is just a collection of words used to control a C++ API.



  • I think the whole c++-Qml thing is miscommunicated. C++ is not going away. There is C++11 support coming in Qt 5.0. But there seems to be an over emphasis on Qml on many of the related blogs. UI is best done using a visual designer. What code it generates shouldn't matter, be it c++ or Qml. Hand coding a UI is tedious whether it is Qml or c++.

    Somebody at Nokia have decided that a fluid UI can be better done using a declarative language and I can't find any good reason. But they have made the decision and the developers have to accept it regardless it is right or wrong. iPhone don't have any declarative thing. We use interface builder and OBJ-C code to do all the fancy UI tricks and it is easy. Qml seems difficult for html / css folks and alien to c++ developers. I hope the Qt visual designer would support (would hide) Qml and those can be manipulated with c++.



  • Well, I think I have supported this thread long enough so that the open-minded reader can conceive an objective opinion on the commitment of Qt to C++, Qt Quick and QML and the reasons behind on his own later on (and therefor I see the initial, or even any goal achieved).

    And I think we all gave you more than one chance to actually understand why things have been done they way they have been done. It is your sole responsibility to accept it, and it is your sole free decision to like it or not.

    Let's agree that we don't agree. I wish you the best finding what you are looking for, it obivously isn't Qt - but it is for a lot of us, including me, including Qt Quick. Does this mean that I would have done the same thing if I were in charge of Qt? Probably not, but I can understand the reasoning behind the decisions made - and after trying the result I am more than convinced (and, actually, I am glad that I wasn't in charge of).



  • @temp - I do not really understand what QML can do (I'm no QML expert yet), that you are missing in the Qt C++ world.

    QML is based on C++ API's that are already there for a long time. QDeclarativeView is derived from QGraphicsView. So instead of creating components in QML you can create QGraphicsItems in C++ easily with a very nice and comfortable C++ API.

    In QML you can do state changes of components - in C++ you can use the powerful Qt statemachine framework (QState) to do the same - its C++ API is really great.

    In QML you can easily create animations of visual (and non visual) components - in C++ you can use the Qt animation framework (QAbstractAnimation...) to do the same.

    So all you can do with QML you can also do with C++. For each QML thing there is a C++ API. Ok, maybe it is not so easy and comfortable in C++ to get the same results like in QML, and maybe you need to spend a lot more time to get the same results, but you can do all the fancy UI stuff in C++ already. So what are you missing exactly in the Qt C++ world that you can do with QML?



  • @Uwe Kindler - you are thinking Qt Quick 1 and the old API. We are talking Qt Quick 2, which is based on the SceneGraph, which is exclusive to QML. Surely, you can do all this in the OLD C++ API, you are correct on this one, however you don't get the extra development ease, the extra performance, and basically you isolate yourself from the vast majority of improvements made to Qt the last year or so. What's missing is a new, elegant, contemporary GUI API for C++, that should have been perfectly clear by now.

    @Lukas - so now I am close or narrow minded for not agreeing with your lack of arguments? All this time you did not present one technical, factual argument to support the need of QML, maybe you can't, maybe you think I am too stupid to get it, maybe because you fear I might point out a way to do it in C++. The fact is QML is not any more powerful than C++, and everything to can express in QML in a declarative way can be expressed using C++ in an imperative way, and in both cases it will be C++ doing the heavy lifting behind the scene, only if you chose C++ as a front end you have the advantage of keeping it all native, with all the benefits and with the elimination of interfacing, glue code and so on.

    How can you even be convinced QML is the better and should be the only way when there is no C++ interface to use the same API, so that you could actually compare and have a base for your conclusion rather than bias?



  • After all the "it is not possible", "QML is innevitable" and so forth, finally some information from someone who appears to know what he is saying, a quote from a lab comment by someone, named Rupert:

    bq. c++ binary contracts bind our hands, hence the lack of a c++ API to scenegraph.

    Anyone care to elaborate on that?



  • Find some clarifications on the topic from Lars Knoll in his recent blog post: http://labs.qt.nokia.com/2012/04/18/qt-5-c-and-qt-widgets/



  • Yep, the power of rant is amazing, capable of un-censoring censored comments and provoke LABS posts. However, this LABS post "clarifies" that QWidget is not gone, which totally misses the point of this thread, as I never complained about QWidget getting sacked, but about QWidged being outdated, while the 21 century-adequate UI solution is exclusive to QML and enforces a proprietary language (QML), additional scripting language (JS), QML interpreter, JS VM and glue code overhead.



  • Can you please stop ranting about (un)censoring comments. This does neither happen here nor in any qt.nokia.com sites. So quit stating false assertions here. If you do not adhere to it, I will close this and any other thread containing that statement for further comments. This is the last warning. Thank you.



  • I see you are quite dedicated to your role and sensitive on the topic of censorship. Entirely out of respect for you I will no longer raise the issue of comments mysteriously disappearing and just as mysterious reappearing after the issuing of a certain statement. Lets just say it was an amazing coincidence, caused by a possible technical glitch, hopefully this will not put you in the awkward position that provokes you into issuing such warnings ;)



  • It is not only me who is is sensitive on that topic.

    This site, as every other on qt.nokia.com, is free for everyone and every opinion. There are only very rare cases where posts or comments are actually deleted. This includes mostly SPAM and obviously insulting messages. From this point on I can only speak for this site: while we kill the former silently, we always leave a comment when moderating the latter, usually after consulting at least one fellow moderator or site admin. If a thread goes out of control it is closed, but not deleted.



  • OK, let me put it this way:

    I wasn't like posts were offensive, I try my best to keep it on point, and if I use some "qualifiers" that can be interpreted offensively, it is never in a demeaning context, but justified. That explains why my comments were not actually deleted, they just did not appear, both posted from home or my work IP, while comments of other users kept on popping up. And it wasn't until I pointed out this "issue" when all those comments magically appeared in an instant. So pardon me if this looks suspicious, and sadly it doesn't end there...

    I honestly don't mean to nag, but after yesterday I stated I will no longer raise that issue of disappearing comments, my comments mysteriously stopped appearing AGAIN, while comments from other users keep on going on. Is this purely coincidental? I am willing to assume even an amazingly improbable coincidence once or twice, but this keeps on repeating and IT WILL NOT BE MY FAULT if I start calling things as I see them, it will be well justified.

    I know my comments are INCONVENIENT, and for about a year I kept away from doing or saying anything, waiting for an indication someone will address the issues at hand, but there was no indication whatsoever that anyone at Qt is concerned with an up-to-date GUI API for C++ despite the many requests from developers, and I REALLY HATE to be that guy, but someone had to do it. For my time in this forum I did my best to be polite and as helpful to everyone as I could, and I really hate to have to be the "persona non grata" but looking at the responses from the community it does seem to appear I have a point and am not a vocal minority. I never wanted to provoke this wave of complaining, I spent lots of time hoping someone at Qt will take on that issue, but since no one did, well, "a man has to do what a man has to do", and forcing things is really the last resort. Apparently Nokia has no problems renaming blind and deaf to individual requests from developers, hence my actions aiming to combine all those requests so that Qt managers finally notice we are not talking a few dinosaurs' last stand against this devolutionary form of "evolution", we are talking ABOUT A LOT OF PEOPLE, and hopefully pay attention to what the developer base wants instead of pushing people to adopt fancy and useless new tools we can easily do without.

    I brings me no joy to do what I do. To be honest, I think this sucks, and the reason I don't blame myself is things would have never come to this if the managers behind Qt listened to what developers want. Someone had to do it, and it is not that important if it is me or someone else, perhaps it would have been better if it was someone with a milder and softer personality, but if we're all silent there is nothing to put Qt back in the tracks of C++ dedication, not as a low level language to extend QML but as a fully fledged programming language with access to modern APIs and the option of keeping applications simple and native.

    Keep this in mind, my actions are merely a reaction to the direction Qt is being pushed since the acquisitions. To quote a smart man who lived a long time ago:

    bq. To every action there is always an equal and opposite reaction

    If the vector of my reaction is inconvenient to Qt managers, it is entirely their own fault for directing Qt in this direction and ignoring developer's requests for so long. And if it sounds a bit too intense - let's just say I speak for all of those too polite to do it and for all of those who were too quiet to provoke any attention.

    And just to keep it on the bright side ;)
    !http://i39.tinypic.com/dbhyqo.jpg(guiapi)!



  • Where do your comments stop to appear? Here in the forums of Qt DevNet?





  • I sense severe unhappiness, temp. :(

    While I obviously have very little influence on Qt development, I can at least assure you that we're not censoring comments. I just approved yours. ;)

    Let me explain. We run quite a picky spam checker (Akismet) on all our comment fields, and we do it for a good reason: we don't want to force anyone to register just to be able to comment, and we would simply be overrun by spammers if we didn't check for anything. In addition to the picky checker, we also have a blacklist of unacceptable words. If either kicks in, the comment is held in the moderation queue.

    In your case, you were probably just unlucky.

    The comment that I just approved had two links. If you add two or more to your, we suspect that something is fishy and you're trying to improve your Google page rank. :P Maybe you have also ticked of the blacklist alarm, and the blog author was less concerned about language and just approved it. I sometimes just take out the problematic words before I approve an otherwise valid comment.

    And then sometimes, people miss the fact that their blog has unapproved comments, which means that it may take a bit before someone happens to take a look and approves pending comments.

    I hope this explains things a bit, we're really not seeing you as persona non grata. And I appreciate your generally friendly tone. :)



  • Thanks for your polite input, I appreciate it, and the links triggering a spam filter sounds reasonable, so I retract my statement. The previous instance I don't recall containing links, but it is understandable if people are not in a hurry to approve the comments I've extensively been bombarding with, so .. like whatever.

    Severe unhappiness is a bit too strong thou, just not being happy with the decision to freeze the C++ GUI API and focus exclusively on QML for future and up-to-date looking interfaces. I honestly like the paradigm behind Qt Quick, the idea of less constrained and easier to build customize components, not to mention the improved graphics back end, separate threads for animation and blitting, it is all a deffinite shift in the right direction, the only thing wrong with it is being locked exclussively to QML.

    And I do get the motivation of QML, I do realize not all people know about program structure, not familiar with the C++ programming paradigm, parameters, constructors, parenthood hierarchy and what not, those people can save a lot of effort using a declarative frontend, with the interpreted doing all that work for them. But keeping in mind Qt has been a long time C++ framework, I am sure I speak for the majority of developers who aren't new to Qt, we do know how to do all this stuff by hand, we don't need QML, interpreters, JS, virtual machines and glue code. QML is simple only when it comes to trivial applications or people that are just making their first steps into programming, if you have experience in C++ and aim at lots of functionality that is beyond the "out of the box" set, keeping it all native C++ is a lot simpler, and adding all the overheads of QML we don't really need just makes it harder. And surely, QML is not that hard to learn, neither is JS (I myself know most of it), glue code and objects could become your second nature, performance and memory footprint overhead people could live with even thou it is a waste, but all those DO STACK UP, and for people like me make Qt "less cute" and more tedious to work with.

    And I know old timers look at me as an isolated case, but that "poll":http://qt-project.org/forums/viewthread/16465/ mlong posted here in the lounge, although too early to be conclusive, shows that for every person, perfectly happy with QML there are two who would like to see the option to do things the native way, which is nothing that should be ignored lightheadedly, considering most of the people who visit the lounge are far from neutral and subjected to the unavoidable, even if denied bias of being long time dedicated community members. And not only this, but I have personally annoyed some of those people, which could easily cause them to vote not with their minds, but just for the sake of being against "my" initiative. There are also many people that are vocal in the labs and blog comment area that may not visit the lounge or have a forum registration at all. In short, I am not a member of a minority, too small for the management team behind Qt to bother with, there are plenty of people who call for nativity (as well as other important things like support for major mobile platforms, which I find just as important), and even those that are silent can easily benefit from it.



  • I agree with Temp.

    Carl and Frank are sitting behind their desk at work when Frank calls Carl to look at his new creation.
    "Carl, look at the cool program I've made!"
    "What does it do?", asks Carl.
    "Ohh, it is a very comprehensive CAD tool!", replies Frank.
    "Cool, let me see it", carl says with a lot of expectations.
    ... The program starts ...
    "Ah, I see you still need to implement some features", carl says after looking at the GUI.
    "Yeah, but look at all those animations. Aren't these cool? Look, when I click on this button, a new window slides and fades from the right corner. Argghhhh... that's sooo cool", replied Frank.
    "Ohh, yes, that is indeed nice", said the amazed Carl.
    ... But Carl wondered ...
    "Can you draw some lines already?", carl Asked?
    "No, not yet, but watch when I click the tool button for drawing a line...", Frank replied.
    ... Some nice graphics appeared ...
    "So..., you've just made some dynamic and animated movie that appears to do something, but it actually doesn't?", asked Carl, who was a little disappointed by now.
    "Can you open Autocad files already?", carl tried again.
    "Autocad? What is that? Ohh, yes, the tool that uses a command line to draw... How stupid is that. My tool actually does some cool animation tricks when you want to draw something. That will up the productivity", Frank said.
    ... But Carl was interested in how Frank made the tool ...
    "Which API did you use to build the tool?", Carl asked.
    "I used QML, which comes with Qt. It's so cool and easy to use.", Frank replied.
    "Ohh, I've heard of Qt before. It's from Nokia isn't it? What can it do?", Carl asked.
    "Well, it has those old classes for cross platform C++ development, but nobody uses them anymore. But they also have this flashy new API for developing fluid and animated GUI's. It's the max!", Frank said.
    "So,", Carl wondered, "are you saying that those old classes aren't maintained anymore? They sound interesting and I remember that's what made Qt big.", carld wondered.
    "Yeah, no, they are still maintained, but by the public. But who cares.", Frank said.
    "Ohh, that's really a shame. So Nokia spends millions of dollars on having animated icons, and because of that they don't have enough people to maintain the rest of the code? That's really awfull for all the people depending on that old code and who've invested in it. That sure sounds like a well meant fck y*!, carl said.
    "I don't care, look at those flying icons on my screen!!!!", Frank said while Carl went away in disbelief.
    ... Some time later Carl sits at his table and sees todays news paper. He notices the following headline:
    "Nokia is looking at a net loss of EUR 929 million..."
    "That explains a lot" Carl thinks!



  • This means, the guy did not understand requirements. If you have requirements to make "old style" apps with QWidget, you can and should do. That is what I do when I work with Qt. I have not used QML in any project up to now and in our domain, we will not switch to QML the next years. And bugs are fixed.

    If you create shiny mobile apps that need animation you can do that using QML and it works fine.

    And if yoiu need such things on the desktop you also can do it. So what the hell is the problem here? The trolls invented an additional way to do things which can be used if needed.



  • Why does it has to be a compromise, either get functionality at the expense of outdated GUI, or get stylish GUI at the expense of making it harder to implement functionality, the whole point is we need both.

    What sucks about the current "toy app" trend is most of those apps are close to useless that is why they rely on eye candy full on, cause simple people are easy to impress.

    And just because eye candy is a money milking marketing strategy does not mean it cannot be incorporated into software whose use goes beyond displaying online service content.

    The reason I went on this "crusade" is for quite a while I tried doing modern design with QWidget, and not only is it awkward and backwards, but performance lacks too. QWidget is built on literally a 20 century concept, and it doesn't fit. And it sucks there is not 21 century, more custom, more fluid, more dynamic and interactive C++ GUI API.

    Kudos to the trolls for inventing the concept of Qt Quick, and I know it must be a nice feeling to have many people using a language you invented (QML) but it is quite foolish to turn your back on Qt's primary programming language for like 2 decades. They could easily have invented Qt Quick to be natively open to C++ and plug QML in as an option, which would save the efforts of having to add C++ frontend support later, when annoyed and disappointed developers call for it. A smart programme will always make a new API open to native use and plugin additional languages support, and the only logical reason I see behind the decision to provide the benefits of a new GUI API exclusively through QML is using innovation to extort developers into adopting yet another limited usage, inferior in terms of performance and efficiency, leading to even more fragmentation of the developer base language, like we don't have enough of those already.

    I cannot shake the felling QML is a little late to the game too, I mean, with HTML5 and all, surely, Qt Quick may have better performance out of the box and the potential to extend it with C++, but HTML5 with JS is quite powerful and has a lot of advantages compared to QML, our company is already developing fluid, dynamic websites with animations and interactive features, and all you need is a browser, even without HTML5 support those are totally doable in HTML and JS. Not to mention HTML is an open standard with quite a lot of users, more than QML is likely to ever enjoy. QML would have been amazing... 5 years ago, but for what QML offers there already many good solutions enjoying amazingly good adoption rate. That is why I feel Qt Quick needs to exploit the advantage of offering native binary performance and efficiency and the power of being free to use C++ without having to base your designs on QML's limitations and write extra code to interface native code to QML.


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.