Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Does Qt need a modern C++ GUI API?



  • I think that the developer team must join QtWidgets and QtQuick to make a unique Qml based widgets system, and moving from XML ui files to Qml ui files.
    And then map every QtQuick component to C++.
    IMHO :)



  • [quote author="utcenter" date="1355849576"]QML is being made a requirement, QML requires QtQuick2, QtQuick2 requires the scenegraph, the scenegraph requires OpenGL.[/quote]

    -QML- C++ is being made a requirement, -QML- C++ requires -QtQuick- QGraphicsView, -QtQuick- a hardware-accelerated QGraphicsView requires -the scenegraph- QGLWidget, -the scenegraph- QGLWidget requires OpenGL. Therefore the use of -QML- C++ requires OpenGL.

    Doesn't sound quite right, does it?

    Yes, QtQuick2 requires the use of OpenGL or DirectX for hardware-acceleration, and a software rasterizer if there is no hardware-acceleration available, but this is because of the drawing backend, not the language frontend. QtQuick2 with a native C++ language frontend will still depend on a hardware-accelerated, platform-independent drawing backend, and such a backend will depend on OpenGL (as QGLWidget and QOpenGLPaintDevice does).

    [quote author="utcenter" date="1355849576"]My idea was of implementing a low level graphics API that is backward compatible with a software rasterizer, while stile being able to make use of OpenGL hardware when present.[/quote]That's exactly QPainter and the Graphics View Framework, the drawing backend for QtQuick1, which has been deprecated for QtQuick2 because of performance issues.

    [quote author="utcenter" date="1355849576"]This API itself can be ported directly to DirectX as well, making the entire process transparent, without the need of translators and emulators.[/quote]The scenegraph drawing backend does in theory support the implementation of a native DirectX backend; but its creation and maintenance is out of proportion with benefit; that's the reason ANGLE is used (and I honestly fail to understand how creating and maintaining a dedicated OpenGL backend, a dedicated DirectX backend and a dedicated software backend instead of a single backend would "...exhaust..." less "...developer efforts ...").

    In addition, ANGLE does not only do OpenGL to DirectX translation, it also does GLSL to HLSL translation and automatic shader correction, which results in a uniform, platform-independent application interface. A native DirectX backend would result in platform-dependent application code, as the DirectX shader language HLSL is quite incompatible to the industry standard GLSL.

    [quote author="utcenter" date="1355849576"]QPainter already supports hardware accelerated OpenGL drawing and caching...[/quote]Yes, but the problem of QPainter was never missing hardware-acceleration, it was the QPainter API itself.

    Again, the principal reason for the performance advantage of the scenegraph over QPainter and the Graphics View Framework is the tight integration with a hardware-acceleration API and the state-based operating principle of graphics hardware, i.e. not beeing QPainter and not providing its abstraction.

    The scenegraph moved the abstraction from above the drawing backend (as in QPainter or the Graphics View Framework) to below the drawing backend which made the implementation of a highly optimised, high-performance drawing backend possible.

    [quote author="utcenter" date="1355849576"]... and the performance is as good as that of QtQuick2[/quote]No, "seriously":http://blog.qt.digia.com/wp-content/uploads/2011/05/numbers.png, not even close.

    [quote author="utcenter" date="1355849576"]All this threat is asking for is a native API that handles all that stuff without forcing QML.[/quote]Yes, and that's an absolutely legitimate request I do honestly support. But you will have to understand that such an API will not change the requirements for the drawing backend and that OpenGL, DirectX, ANGLE and alike has absolutely nothing to do with QML.



  • I honestly don't know why you keep repeating what is obvious and known by all - of course a native frontend to QtQuick2 would require OpenGL, who ever denied that? How many times do I need to clarify I was talking about a hypothetical native GUI API, not QtQuick as it is, but what could have been if it was properly engineered from the start, instead with the idea to make it a tool to propel QML.

    bq. QML C++ is being made a requirement, QML C++ requires QtQuick QGraphicsView, QtQuick a hardware-accelerated QGraphicsView requires the scenegraph QGLWidget, the scenegraph QGLWidget requires OpenGL. Therefore the use of QML C++ requires OpenGL.

    Now that is just nonsense. First of all - C++ is an industry standard. QML is NOT. Then - C++ does not require QGraphicsView in any way. Therefore it is hardware acceleration that requires OpenGL, and in that context, the best you can say is OpenGL requires C, since it is a C based language, but C++ requiring OpenGL - LOL, just LOL.

    FACT IS - QtQuick requires OpenGL, with QtGui it is optional - you have the option, the choice. See the difference?

    As for QPainter performance - those numbers are clearly plain wrong. I have done stuff that uses OpenGL QPainter with performance gains up to 2.5x. Don't know if the results from your link were deliberately made as to make QML "shine" or it is a half-ass implementation of OpenGL in QtQuick1, or the test itself was not thorough enough, but I can testify to the fact that with C++, QPainter, OpenGL, some caching and optimizations I get about the same performance boost as QtQuick2 is claimed to introduce, sometimes more.

    But if you don't trust me, take a peek at "this video from dev days":http://qt-project.org/videos/watch/graphics-performance-best-practices - obviously the proper utilization of OpenGL can yield significant performance improvement that somehow is magically lacking in the image you linked to.

    Again, QtQuick2 makes all those optimizations, which is great, because it saves a lot of work, but it does it in a way that makes QML mandatory, which sucks, since QML on itself rises even more dependencies, not to mention its overheads, and I don't stress performance as much as I stress the extensive extension of custom QML components, which makes using QML a more tedious process than sticking to plain C++. I mean it is not like we can't do our own markup and interpret it, if declarative was of such importance. As for binding - c++11 takes care of that. So why do we really need QML? Because every company out there is itchy to enforce its own proprietary way and isolate the developer base? It was a big mistake to make QML into more than simple markup, I honestly prefer the JSON syntax to the XML, since it is faster and cleaner, but making that into a mandatory language that absorbs the entire development effort of Qt - BAD IDEA. Qt should have moved faster to embrace C++11 instead of sticking to its ancient toolchain, which is the justification for adding JS to the mix. The whole endeavor looks like a clumsy, ill conceived HTML/FLASH hybrid that fails to deliver on its main "selling" points, on top of arriving a little too late to the show.

    IMO a portable and more powerful low level graphics API was all Qt really needed, on top of that it is easy to implement different GUI paradigms. One with backends for software, desktop and ES GL as well as DX, with the proper performance or memory efficiency optimizations, that still sets a bar of "common functionality shared across the board" but without excluding more advanced capabilities of modern GPUs.



  • [quote author="utcenter" date="1355915239"]C++ does not require QGraphicsView in any way. Therefore it is hardware acceleration that requires OpenGL...[/quote]Exactly. C++ does neither require QGraphicsView, nor OpenGL. The same way QML does neither require QtQuick, nor OpenGL. It indeed "...is hardware acceleration that requires OpenGL...".

    For instance the "Qt Build System":https://blog.qt.digia.com/blog/2012/02/15/introducing-qbs/ uses QML to describe the dependency graph, and does neither depend on QtQuick, nor OpenGL.

    [quote author="utcenter" date="1355915239"]FACT IS - QtQuick requires OpenGL, with QtGui it is optional - you have the option, the choice. See the difference?[/quote]If you want to be hardware-accelerated you will have to use OpenGL, be it QtQuick or QtGui - there is no choice. If you don't want to just continue using QPainter, one of the fastest software rasterizer available (or just use QtQuick with a software rasterizer).

    [quote author="utcenter" date="1355915239"]... but I can testify to the fact that with C++, QPainter, OpenGL, some caching and optimizations I get about the same performance boost as QtQuick2 is claimed to introduce, sometimes more.[/quote]Use QOpenGLPaintDevice then, the new hardware-accelerated QPainter surface which has been added to Qt5 in addition to QtQuick.

    [quote author="utcenter" date="1355915239"]Again ...[/quote]No, not again. All of this has been discussed already.

    [quote author="utcenter" date="1355915239"]IMO a portable and more powerful low level graphics API was all Qt really needed, on top of that it is easy to implement different GUI paradigms. One with backends for software, desktop and ES GL as well as DX, with the proper performance or memory efficiency optimizations, that still sets a bar of "common functionality shared across the board" but without excluding more advanced capabilities of modern GPUs.[/quote]I accept that you do not want to understand the difference between the concept behind your proposed solution and the concept behind a scenegraph.

    But feel free to join the Qt Project and contribute your "...proper performance or memory efficiency optimizations..." which must have slipped through in the past two decades of Qt and QPainter development and optimization and continue using QPainter, it won't go away.

    But don't be peeved if the rest of us leaves this technology behind and is moving on using something different.



  • bq. I accept the fact that you do not want to understand the difference between the concept behind your proposed solution and the concept behind a scenegraph.

    You talking about me not wanting to understand - now that's hilarious ;)

    Of course there is a big difference, the concept I present is what I as a developer need, and I am willing to bet so do a lot more people.

    bq.
    But feel free to join the Qt Project and contribute your “…proper performance or memory efficiency optimizations…”

    So we are back to that, huh? Is there a relation between your ability to comprehend that this cannot be done through individual effort and the amount of times this is being repeated? Pardon my ignorance, but I think it is quite stupid of you to ask me to do what is, in YOUR OWN WORDS, a task too laborious for the big team of people who get paid to develop Qt to bother with.

    bq.
    But don’t be peeved if the rest of us leaves this technology behind and is moving on using something different.

    If my eyes do not deceive me, 7 out of 10 people are not happy about that "amazing new technology" and want something better. Not that I am surprised, neither by the complete disregard for the requests of the developer community, nor by the demeaning and insulting techniques, being utilized to discredit and ridicule those requests, in retrospect I realize it was naive of me to consider Qt of such high esteem.

    To me it seems like there are people in the management of Qt that honestly believe they know what's best for everyone and have a really hard time realizing their solution is far from amazing and in many regards even far from contemporarily adequate. This kind of corporate behavior has driven the previous company I was employed by into the ground, arrogant executives with poor ideas, amazing in their own eyes, costing about 100 hard working people their jobs.



  • Whether you like (and understand) it or not, QtQuick is here to stay - for a reason.



  • Rather than spending a lot of time and effort in creating a whole new thing like Qml, was it not better to improve and add to the QWidget api ? After all Qt devs are c++ devs and they will be more comfortable with a c++ api. As a Qt programmer, that is what I feel. Product developers should always understand what the product user wants rather than do what they think is right. So as a customer, I don't share the enthusiasm for Qml. In this fast paced field I'am won't spend time / money with out any clear advantage. We can't learn something just for the sake of learning a new thing. Digia's focus is somewhat different from that of Nokia and now I guess they would have to work on two GUI apis, the QWidget api (which many apps use and are still going to use) and the Qml ones. Double effort. If my logic can be written in Javascript, I will do the UI in Html 5 / css. The designers are experienced in it. So where do Qml fit. I know there are strong supporters for Qml here. But I still feel it was something that was not needed in the first place. May be some important person in Qt hierarchi, may be in Nokia have decided what is good for developers.


  • Moderators

    [quote author="Jayakrishnan.M" date="1355980522"]So as a customer, I don't share the enthusiasm for Qml.[/quote]

    You will be pleased, then, than Widgets are maintained again (and, for example, received updates to accessibility in Qt5).

    [quote]Rather than spending a lot of time and effort in creating a whole new thing like Qml, was it not better to improve and add to the QWidget api?[/quote]

    Yes and no. Widgets are too rigid and too slow due to complicated layouting calculations. QML works much better here. On the other hand yes, Widgets do deserve more love and will hopefully get it (actually, commit log shows quite a lot is going on in Widgets and Gui).

    This whole discussion does not seem very productive, though. The decisions were made several years ago, there is not much point in arguing over that. We are where we are, and are not likely to change the past. Plus, we all obviously disagree and are not very ready to change our minds ;) As for the topic itself: yeah, maybe a new c++ API would be good. It's another big effort, of course, and would mean another API to learn.



  • [quote author="Jayakrishnan.M" date="1355980522"]Rather than spending a lot of time and effort in creating a whole new thing like Qml, was it not better to improve and add to the QWidget api?[/quote]... and so the cricle is complete to the inital comment I've brought up in this discussion almost ten months ago which is now as true as back then.[quote author="Lukas Geyer" date="1334064028"]I think there is a lot of confusion and insecurity caused by a serious lack of information on both ends, Nokia unable to provide and the developers unwillingly to inform.[/quote]There was never a dedicated explanation on the part of Qt why specific decisions have been made and how they have came into existence - an that's a great pity, because a lot of people felt alienated with good reason; you usually don't support decisions you can't comprehend.

    And then happened what had to happen, people either took a defensive position refusing it or an offensive position attacking it - although the most of them obviously have never used QtQuick or are aware of the reasoning behind.

    Years have been spent on trying to improve QtWidgets. There was the widgets-ng project, there was the itemsviews-ng project - all of them shared the same result: The way QtWidgets, the layout system, QPainter and as a last consequence C++98 works prevents any significant improvment, and it does not support future requirements of high-performant, hardware-accelerated non-uniform user interfaces. QtQuick is a consequence, not a cause.

    People also don't seem to realize that QtQuick does not replace QtWidgets, it is just another option. Noone is forced to use QtQuick if he doesn't want to. QtWidgets is actively developed and maintained and is here to stay.

    Should there be a native alternative to QML in the long term? Probably. But I also understand why there is none yet and I fully support this decision.

    I still think that there should be an extensive explaination on the part of the Qt Project why QtQuick has been brought into beeing so people who are not willingly to inform themselves can at least comprehend the decision - though I am also realist enough to accept that you can't force people to understand if they don't want to; but then QtQuick is the least of your problems.



  • bq. Yes and no. Widgets are too rigid and too slow due to complicated layouting calculations.

    Maybe the discussion should focus on "why QML but not a new C++ API which do not base on QWidget"?.

    I don't know QML is a right choice or not, it is too early to say that
    and useless to argue about the decisions of digia, let time prove the
    value of QML, wether it is an extremely hot, cool features or not

    Whatever, digia and nokia have spent a lot of times on QML, it is too
    expensive to ask them to throw it away even it really is not a good choice.

    I repeat, I don't know QML is a right choice or not, but I will give it a try.


  • Moderators

    [quote author="stereomatching" date="1355993261"]Maybe the discussion should focus on "why QML but not a new C++ API which do not base on QWidget"?.[/quote]

    Because QML does exist, is useful and powerful, and this new c++ API is not even planned as of yet? Sure, if somebody starts design/ implementation, I'll fully support it, and probably I'll also try contributing as much as I can. But it's not the case ATM, and even if this project kicks off, it will take years to get to a working stage.

    [quote]I don't know QML is a right choice or not, it is too early to say that
    and useless to argue about the decisions of digia, let time prove it.[/quote]

    Too early? It's already with us for 3 years...



  • [quote author="stereomatching" date="1355993261"]Maybe the discussion should focus on "why QML but not a new C++ API which do not base on QWidget"?[/quote]In a nutshell, binary compatibility, bindings, runtime optimization, network transparency, rapid prototyping and better tool support, extensibility and versatility (as for example in the "Qt Build Suite":https://blog.qt.digia.com/blog/2012/02/15/introducing-qbs/). But feel free to dig through this thread, I think there is not a single argument which isn't in here.



  • bq. Too early? It’s already with us for 3 years…

    This is just my immature view, don't take it to seriously:).
    I don't know how to design a cross-platform gui
    framework like Qt nor QML yet.

    So I don't want and don't have any right nor knowledges to
    judge QML is a success or not. What I can do is waiting for the
    times to prove the value of QML

    For me, QML lack a place for it to "shine", symbian dead, meego is half dead,
    lack of desktop components, do not support android and ios with a mature release yet.

    QML looks cool, but do not have a good support on major platforms(not even desktops).

    If QDesktop and components for ios release, I would like to implement some
    highly animated gui by QML.



  • [quote author="stereomatching" date="1355994133"]For me, QML lack a place for it to "shine", symbian dead, meego is half dead, lack of desktop components, do not support android and ios with a mature release yet. QML looks cool, but do not have a good support on major platforms(not even desktops).[/quote]

    That's true. But commercial-grade iOS and Android support is just a few months away, the Qt (Desktop) Components are improving daily and there is a lot of stuff in the pipeline like Theming / Styling, Actions, Persistent Properties / Settings, proper Enumeration and Singleton support, a brand new QML Runtime and much more.

    Stay tuned! ;-)



  • bq. ommercial-grade iOS and Android support is just a few months away, the Qt (Desktop) Components are improving daily

    Nice to hear it and thanks for all of the efforts, I believe that there
    are a lot of Qt fans waiting for rigid support of ios and android long
    time ago.Can't wait to give it a try, well done.



  • bq. commercial-grade iOS and Android support is just a few months away

    I'll drink to this, I've pretty much scrapped Qt for non-performance-intensive stuff, but there are still plenty of cases where I need native code for computation and graphics.



  • An ironic response straight from the "Qt5 documentation":http://doc-snapshot.qt-project.org/5.0/qtquick/qtquick-visualcanvas-scenegraph.html to all those "Do it yourself then!" people:

    [quote author="capisce" date="1335560638"]
    Have you looked at making your API on top of QQuickItem and QSGNode which are public API and give you access to the raw power of the scene graph from C++, which earlier seemed to be the main thing you desired?[/quote]

    bq. The scene graph is closely tied to Qt Quick 2.0 and can not be used stand-alone.

    And continuing my angry rant - Qt5 rises the amount of dll requirements even further, now a basic GUI projects requires a whooping 18 MB of DLLs, and still FAILS to run outside of creator.

    And despite the claims of some people here that Qt5 Widgets won't require GL, the two newcomers in the group of dependencies are libGLESv2.dll and D3DCompiler_46.dll

    Way go to and bring holiday cheer with more dependencies and headaches, all this considering Qt5 was released half a year behind schedule...



  • QtWidgets does not depend on OpenGL / DirectX, it is the "OpenGL / DirectX support":http://qt-project.org/doc/qt-5.0/qtgui/qtgui-index.html#opengl-and-opengl-es-integration in QtGui which does. If you don't want OpenGL support or a dependency on it build with <code>-no-opengl</code>.

    This rule also applies for any other dependency (ICU and alike).

    If your application does not run outside QtCreator your deployment is broken. That's something Qt can't or won't fix for you.

    [quote author="utcenter" date="1356717680"]An ironic response straight from the "Qt5 documentation to all those "Do it yourself then!" people.[/quote]I'm not quite sure what you want to tell them exactly.



  • Well, maybe you will be sure about the following:

    A few times already I have pointed out that C++ is no longer the primary language for Qt development.

    Each and every time Qt people have denied that, claiming that C++ is still the primary language for Qt development.

    But how can this be, if it is possible to write entire Qt applications without typing a single line of C++? How can something that you can go without be considered primary?

    On the other hand, it is simply NOT POSSIBLE to write a Qt5 application WITHOUT QML. You can only use C++ to write a Qt4 application in Qt5, but almost all of the Qt5 specific innovations are exclusively accessible through QML, therefore, in Qt5 C++ is no longer the primary language for Qt development, but a language to extend the framework. C++ is optional, QML isn't - which one is the primary?

    Heck, you could even use QML markup to feed the MOC to generate entire C++ files, so that QML can be extended in QML without requiring any C++, while still using it behind the scenes, and call all C++ "boilerplate code" - because that is the purpose it serves in Qt5.

    In fact a thin wrapper allows to use QML to create QWidget applications, so you can even substitute C++ with QML for QtGui...

    The funny thing is that time after time I have acknowledged the benefits of QML, yet on the other side of this argument there hasn't been even a hint of admitting the reality of the situation, instead an idealistic and completely unrealistic picture is being presented with overzealousness and blind fanatical devotion that QML is perfect in every way and is all that Qt developers need. And IIRC it was your side of the argument that accused our in "lack of objectivity".

    Hmm, perhaps some of those 164 people actually have a point over the 71 minority that is completely happy with QML? Perhaps it is wrong to discredit and disregard their opinion? I mean, what kind of community is this, if the few insiders can disregard the vast majority? And yes, I know Qt is not a democracy, I am not expecting of Qt to obey the majority demands, I am expecting of Qt to not disrespect and disregard their opinion.



  • You will have to differentiate between people not supporting a request and not supporting the way a request is made. I, yet again, do support the request for a native backend, but I do not support the negative campaining against Qt 5 and QtQuick, however, because most of it has no basis in fact and it is not beneficial to the original objective (your "...angry rant..." wasn't really thus far, was it). This does not mean that objective criticism is not allowed to level at Qt5 and QtQuick!

    Qt5 is not just QtQuick, it is 30+ modules plus QtQuick, one of them requiring QML. If this means to you that "...C++ is no longer a development language for Qt5..." and that "...Qt5 is completely QML..." you maybe shouldn't recommend people to "...use Qt4 [as well]..." either, because C++ is no longer a development language for Qt4 and Qt4 is completely QML (and HTML/JS, which can be used to create applications in the same way QML can be used, due to the requirement of it to use QtWebKit), because QtQuick (and QtWebKit) exist(s) in Qt4 as well.



  • First of all, don't put words in my mouth, I NEVER said “…Qt5 is completely QML…”, I also NEVER said “…C++ is no longer a development language for Qt5…”, what I said is "C++ is no longer the primary language for Qt development".

    Is it true that you can write complete applications with Qt without a single line of C++? Yes!
    Is it true that you can even write QWidget applications in QML simply by creating a thin wrapper? Yes!
    Is it true the vast majority of cool new features are exclusive to QML? Yes!

    It is true that QML was also in Qt4 - but in Qt4 QML was built on top of the QGV, it didn't had any exclusive features and its backend had a public native API to be used when necessary. That is NOT the case with QtQuick2.

    So how is C++ the primary development language for Qt? Because Qt is written in C++? That's like saying C is the primary language for programming in Java, because Java is written in C and you can call native C code...

    C++ is becoming a boilerplate/wrapper language in Qt. That's a fact!

    QML is not the primary focus of Qt5? What other modules? Most of the stuff in Qt5 is legacy from Qt4, the most significant part of Qt5 is the scenegraph, which is dedicated to QML for as long as there is no public native API. The few other new bits of functionality in Qt5 are there because they are needed by QML/QtQuick. As are the hard-coded dependencies for OpenGL, regardless if a project uses it or not... The rest is just minor improvements of old functionality that was already present in Qt4.

    Then, for the LAST TIME - I have no problem with QML, and in many cases I'd gladly use it. My problem is not with QML, but with the fact it is being enforced and there is no contemporary adequate native alternative. The developer base is being seduced by giving QML exclusive capabilities that are being omitted from having a public native API, even thou they are implemented in C++. So please, do not make false claims I am campaigning against QML. When I get to think about it, you surely do like to make things up and claim I said them... That is pretty lame of you... Especially after I stated explicitly several times I have no problem with the existence of QML. I am not campaigning against QML, I merely point out the downsides of QML while I campaign FOR a native API to use all the nice and time saving techniques that are given exclusively to QML, which is entirely within the realm of the possible, and wasn't done only to pimp QML and give it an artificial edge.

    In "this video":http://www.youtube.com/watch?v=vhWS_bN-T3k, outlining the new features of Qt5, like 70% of the time that actually presents any information is dedicated completely to QtQuick2. 25% are dedicated to the webkit, which is not new just features minor improvements. The rest 5% of the time is dedicated to mostly other old features that got minor improvements, and also JSON, which is once again tightly related to QML. So, if the numbers are normalized it turns out 90% of what's new about Qt5 is QtQuick2, which is QML, and if QML gets 90% of the attention then it is the primary development language for Qt5. Especially considering the many improvements it gets EXCLUSIVELY.

    And finally - I may be making a mistake measuring by me - but if you ask me, a truth is a truth, regardless of its tone. If a person has a point, I don't care if I like that person, or dislike that person, or hate that person's very guts. A valid point is a valid point, regardless who expresses it. So what you are telling me is that:

    • first you discriminate against my opinion just because you don't like me

    • second you discriminate against everyone else who shares my opinion because you don't like me

    You don't like my tone? I can't help you. You can only blame yourself. I am not prejudiced against any anyone, my attitude is determined entirely by the person in front if me. I don't respect people by default - respect is not granted but earned, and let me assure you, weaseling your way out of every inconvenient confrontation by means of false claims about me and throwing rocks back at me doesn't earn you any.

    There was nothing wrong with my tone initially, it got sharper as the direct result of some people, including you, unloading tons of BS in ill attempts to discredit the validity of the community wish, expressed in this poll.

    It is true there is plenty of anger, judging by the comments I read in the blog section, I am neither the only, nor the most drastic case, but that anger is entirely the product of Qt management. DO you honestly think those people are some lifeless, stuck up haters, who have nothing better to do than hate by default? Or is that anger the product of the piling up disappointment that is being completely ignored? The people that ask nicely get the same response as those, who have gone beyond the point of being nice - a broken record type of response that answers nothing, like it came out of the mouth of a politician...

    Character varies, there are mellow people, there are edgy people. It is very childish of you to disregard the opinion people, just because they is not like you, or just because they are not like you want them to be.

    I bet most of those now 166 people are nice, or at least nowhere nearly as unpleasant as me - and if your personal preferences really prevent you from being objective, just subtract me from the count and respect the rest, be an adult for god's sake. But to disregard and dismiss the opinion of what is the majority of people who visit this place, all because you don't like me - that's kind of pathetic, really... I am not running for a president, those are not "my people", your dislike of me should not undermine the validity of their opinions.



  • This is not about the community, their concerns and their undisputed validity and this is not about all the people who have voted in favor of native development, this is solely about your opinion and your way of expressing it I do not agree with and I do not support, not theirs (and if you are out for yet another personal opinion I think that it might be possible that some people who have voted as you do not either); criticizing you does not automatically mean criticizing them. And I do support native development too, have you forgotten? We already have had this, haven't we?

    You are allowed to have your opinion as I am allowed to have mine.

    This does not mean that the request for native development is disregarded or dismissed for no reason or that you are beeing ignored (you have been given the reasoning more than once), that there should be no native development (you've been confirmed that any substantial community efforts will be supported more than once), that you are not allowed to have your opinion or that I express a personal dislike other people will have to take the rap for; it does not even mean that I’m right and you are wrong – it just means that I have a different opinion on points you've raised, and that I do not find your arguments suitable enough to convince me of the contrary. People disagree ever and anon - that's life, which also makes you not always get what you want. But we already have had this as well, haven't we?

    Yes, "...people that ask nicely get the same response as those, who have gone beyond the point of being nice...", no matter whether you are "...mellow.." or "...edgy...", because a "...truth is a truth...", as you have said.

    I also have a different opinion on respect, which is granted by default and unconditionally, as it is fundamental to any interpersonal communication and social interaction. It is reputation which has to be earned, not respect; disagreement does not entitle anyone to lose respect or temper. This discussion has ended as far as I am concerned, because it has passed the point where it is beneficial to anyone.



  • You just don't know any better, do you? This is not about me, and it will not become about me regardless of your ill conceived attempts to make it so. Furthermore, I am pretty sure I can recall you and a few others disregarding the validity of this poll and its results, so if there is a quality you are proving right now, it would be spinelessness and being double-faced. First the poll was, in your own words "biased", then it was, again, in own words, "with insignificant participation", so it wasn't really valid, because "passively recruited or self-selective surveys are generally never representative" and it is "statistically wrong".

    So let me ask you, how your desperate attempts to dismiss the validity of the poll can be considered regarding or respecting it?

    And now, it is all about despicable me, "campaigning against QML" and claiming that "Qt5 is completely QML" and that "C++ is no longer a development language for Qt5", and somehow even thou you yourself claim to want it, you don't think Qt should get a native API because I didn't ask about it the way you think I should have? Funny how you don't stand up for that native API you claim to want, and the entire time are entirely dedicated to downplay me, all based on your personal preferences?

    Well, feel free to create a forum for "Lukas Geyer's personal preferences", and play "virtuous knight on a white horse" there, because last time I checked, this forums was about Qt, not about your "ideals" and not about discriminating against others, who don't share them!

    Furthermore, I don't give a broken penny about what you think, and that is not because I don't respect you, but because I respect the right of people to have their own views and express in their own way, and that includes you. You say that "respect is granted by default and unconditionally" and yet you totally disrespect my way of thinking and expressing, which is technically hypocrisy. So, PLEASE, this is not the place to preach your philosophies, this is a forum about Qt, and this is a thread about the need of a modern C++ GUI API, so if your claims that you want it too are true, then stand up for it IN YOUR OWN WAY like I do in my own... or get lost... If I ever find myself in need of moral lessons you will be the first to know, but if you feel that much about enforcing those, then feel free do it in person, but enough of your lame attempts to downplay the initiative because of your personal preferences, which do not belong here in the first place. And if you are spiteful enough to oppose what you claim to want just in spite of me, well that speaks out loud a lot about your qualities...

    All you try to do is take a thread that is FOR a native API and turn it into a thread AGAINST me, and if you are half as decent as you claim, you should be ashamed of yourself!!!



  • Hey mans you doing great job by developing Qt.

    But what the DUMB DECISION make improvment EXCLUSIVELY for QML. Guys realy WTF? You have new features like making 3D sound and this feature available only from QML. I write my game app on C++ and I wanna use QtAudioEngine but I cant!!! Look... u write feature on C++ and make it available in public only from QML. Are u serious? If so, Qt5 have PRIMARY LANGUAGE -> QML not C++, like utcenter say's.

    Oh maybe I too young and something don't understand, but, this is realy bad way...

    I see it as: create new feature on C++, and make it avalable from C++ and QML. Yes I need cool C++ framework with feature like QML.



  • I'm very disappointed that the new features in Qt5 are not accessible with C++.
    And yes, I know that you don't care about my opinion, I just wanted to express it.

    Anyway, thanks for creating Qt4, I like it very much and I hope it will still be maintained for a long time so that I can avoid to use Qt5... at least till all the new bugs introduced in Qt5 are solved.



  • Paradox in this situation that the new features is written on C++... damn, how this can happen?
    [quote author="Trino" date="1360964774"]I'm very disappointed that the new features in Qt5 are not accessible with C++.
    And yes, I know that you don't care about my opinion, I just wanted to express it.

    Anyway, thanks for creating Qt4, I like it very much and I hope it will still be maintained for a long time so that I can avoid to use Qt5... at least till all the new bugs introduced in Qt5 are solved.
    [/quote]



  • The decision certainly has been influenced by marketing trends.We are going to see a lot of programming oriented to smart phones and all those tiny devices in the future.Digia has certainly seen that and is trying to be at the right place at the right time.



  • Yes trends... but answer me on one question: why new features writed on C++ not available from C++? They have some things that make him technically not compatible with C++ programs? Or what?

    Looks like I asked several questions)))

    I wanna say: guys u can kill two rabbits, have good C++ framework, with feature like QML.



  • Qt has really satisfied many of my programming needs,but the decision has kind of pissed me off too.I do not know much about the whys of the decision,but one thing is sure:companies go after profit and they probably have found more in promoting QML,guess we should keep our eyes open for alternatives and never put all the eggs in one basket.Any way c++ is still there and we just need to keep looking for good frameworks and libraries that fit the job.



  • There aren't many alternatives to Qt, and I won't be far from the truth if I chance the "many" to "any"... There is the morally outdated GTK built on top of the horrendous GObject, there is the morally outdated wXwidgets and probably the most viable "alternative" - JUCE, which is actually decent but APIs are a little illogical and do not cover as much ground as Qt (even though it covers some ground that Qt doesn't), not to mention the rather "humble" documentation and hardly any educational materials available.

    There really aren't that many cross-platform C++ baskets to put your eggs into. You'd have to actually learn a few platform limited ones, with different APIs and potentially a different language, which is hardly convenient.

    Qt is far from perfect and in many aspects deeply flawed, but the sad reality of the situation is there is no comparable tool that is better or comes sufficiently close, which makes the leaning towards QML that much worse. That is why many developers find themselves extorted into adopting QML, because that is what Qt is focusing development efforts on and the alternative to Qt and QML is even worse than QML, which conveniently sits in the role of the "lesser, more digestible and appealing evil".



  • [quote author="utcenter" date="1357401855"]
    On the other hand, it is simply NOT POSSIBLE to write a Qt5 application WITHOUT QML. You can only use C++ to write a Qt4 application in Qt5, but almost all of the Qt5 specific innovations are exclusively accessible through QML, therefore, in Qt5 C++ is no longer the primary language for Qt development, but a language to extend the framework. C++ is optional, QML isn't - which one is the primary? [/quote]

    Can you give an example for that? Which functions are exclusively accessible through QML?
    QML is mighty, but not so mighty like the C++ Framework, I think. Somewhere was written, that C++ are the primary language for Qt, but I read it, when Nokia owns Qt. I don't know the plan of Digia, but if the C++ framework will be droped down, I will have to switch to HTML5...

    I also used another libraries like OpenCV and I cannot easily acess them through QML.

    [quote author="utcenter" date="1361286905"]There aren't many alternatives to Qt...[/quote]

    But for QML, the (better) alternative is HTML5.



  • [quote author="Serenity" date="1361352789"]
    Can you give an example for that?
    [/quote]
    Qt5 have new features like making 3D sound and this feature available only from QML. Can u show me please how use this feature from C++? I wanna use QtAudioEngine but I cant.

    Without using hacks... after that I can say QML is primary language.

    And like I say, what the dumb write features on C++ and make them available only from QML... maybe someone has "Woe from Wit"?



  • 3D sound? interesting, got a link?



  • [quote author="Thomas Zander" date="1361353747"]3D sound? interesting, got a link?[/quote]
    Use search... http://qt-project.org/doc/qt-5.0/qtmultimedia/audioengineoverview.html
    Excellent features that I cannot integrate in my game app on C++ ...



  • @hronom; you do realize you can combine QML and C++, right? Doing audio in QML while doing graphics and logic in C++ should be perfectly possible.
    Saying you can't use it in your game is wrong, you can use it, the question is if you want to spent time learning QML ;)



  • Yes I can go from one office in New York to another office in New York by flying through Ukraine.
    @Thomas Zander; do you realize that something wrong in this situation? Or its normal?



  • [quote author="Hronom" date="1361353124"]
    Qt5 have new features like making 3D sound and this feature available only from QML. Can u show me please how use this feature from C++? I wanna use QtAudioEngine but I cant.
    [/quote]

    :( :( :(

    But there are still so a lot of much other things, which are not working in QML.

    btw: Is that, what you are looking for: http://qt-project.org/wiki/QtAudio3D ?



  • In math you often have to change to a different domain to find a better solution.
    For example to convert a waveform to a fourier domain in order to fetch the frequencies.

    QML is a better domain, as it were, for many tasks that are of a more declaritive nature. Of which audio-playback is an excellent example.

    Its good to learn more languages, it gives you freedom to pick the right one for the job.



  • [quote author="Serenity" date="1361356800"]
    :( :( :(

    But there are still so a lot of much other things, which are not working in QML.

    btw: Is that, what you are looking for: http://qt-project.org/wiki/QtAudio3D ?[/quote]
    Oh thanks, I'll try that. But its looks like spike, than I have already in Qt5 this features writed on C++.

    @Thomas Zander; Oh I understand you... I just wanna say one thing, why need divide Qt on two parts?

    We have Qt C++ code part that available for C++ apps, and Qt C++ code part that available for QML.
    This is normal situation?
    Or maybe we can create framework that have Qt C++ part that available for C++ and QML apps. Looks like it be epic win, do you think so?

    Guys look here: I dont hate QML, I just say one simple thing, and i wanna that guys that creates this beautiful framework heared this thing.

    I don't have big skill in C++, but, for the first view of sources of backend QML, i think: why this guys do this divide? Oh I understand may be something technically not compatible with C++ apps, but if not, why you do this?



  • Having Qt do QML as well as C++ are two domains, they have different strenghts and weaknesses. The main reason for QML is because it is really really good at some things. Things that C++ is not really useful for. You'd have to write many classes and many many lines of code to do stuff that in QML takes no time at all.

    Stating you really want to write those hundreds of lines of C++ and you dislike you have to write QML instead, sounds a little like you are asking to use the hammer you know so well instead of learning a new tool that is much better suited to the task.

    Damn right Qt is divided into those two domains, and its a great thing too since they are for different things and you likely will keep using both of them in apps.

    So, in short, because its too painful to use C++ for some things, we invented QML to do it easier. Thats why we did this.


Log in to reply