On 5/15/12, BRM <bm_witn...@yahoo.com> wrote: > It would probably be good for a statistically significant poll to be > officially done. > I'd expect that it would probably have a 50/50 split, or may be a 60/40 > split in favor of QML > as I do expect there is still a lot of momentum behind the QWidgets and > QGraphics* frameworks. > But I doubt that will happen.
The polls consistently show a 3:2 lead for C++ GUI... but I agree we need a bigger sample size. I don't think even with thousands of votes that the ratio would change much. Thiago: can you use your godlike yet neutral powers in this "open governance" project to put a neutral poll on the front page? Really, the big issue is that Nokia has in effect killed the development of the Qt (sans maintenance, bug fixes, small-medium size features, and R&D that tries to solve Nokias financial problems). ...but there's no better way to emphasize that fact than to highlight the giant split in a) what the Qt _users_ want and b) what Nokia wants On 5/16/12, Robin Burchell <robin...@viroteck.net> wrote: > On Wed, May 16, 2012 at 4:42 PM, Atlant Schmidt > <aschm...@dekaresearch.com> wrote: >> Qt "the product" may be developed by a meritocracy of devel- >> opers but it damned-well better respond in a more-or-less >> democratic way to the needs/demands of the consumers of the >> product. If it doesn't, those consumers will move on to >> using other frameworks. > > That isn't how reality works. You cannot tell me (as a volunteer) what > I ought to be spending my time on any more than I can tell you what > color to paint your livingroom. My interests dictate what I invest my > time into, not random people on the internet. As a developer working > on Qt, I will probably keep users' interests in mind, but at the end > of the day, it's still my decision. For individual contributors + 3rd party contributors, yes, nobody can or should tell you what to work on. This is obvious. But Qt at one point had people who were paid by investors to work on Qt. Improving it, satisfying the _users_, etc. Those developers had an implicit obligation to serve the Qt _users_. It was in their interest to do so and their R&D would reflect it. Trolltech gets gobbled up and all of the sudden the goal shifts from attracting more Qt _users_ (hoping they convert to Commercial someday... or just contribute really) to a highly experimental/obtrusive-to-existing-code/not-source-compatible+not-binary-compatible Toy Programming Language (that is forced upon you if you want to use the recent/updated/enhanced/efficient QtQuick) to hopefully save Nokia in the mobile market (It won't. Microsoft has Nokia by the balls). On 5/16/12, Thiago Macieira <thiago.macie...@intel.com> wrote: > Even though the consumers cannot demand anything from volunteer > contributors, there is a an important overlap between what the consumers want > and what the > contributors want to work on. Or, at the very least, there should be. > > If we, as the contributors, do not pay attention to what our users want, > we'll produce a toolkit that no one wants to use. Therefore, it is in our best > interest to keep the users present and happy with the functionality. That's > the only way to ensure the long-term survival of the project. I think it's in Qt's overall interest for a company to be responsible for paying attention to what the users want. Nokia has the job but is not performing it. Qt is suffering and will continue to suffer, perhaps even until Nokia's inevitable death. > But note also that the overlap is not 100% and will probably never be. > Sometimes, users want too much, or don't know exactly what they want. There > must be room for the contributors to exercise their imaginations and come up > with new, revolutionary solutions. > > I firmly believe that QML is in that camp. QML may be revolutionary, but it does not target the right camp. It targets the designer/amateur-coder audience. "Awww, poor baby. C++ too hard for you? Here's some meta-descriptive-GUI language where you can use simple javascript statements/code to implement all your back-end (and subsequently, perform non-trivial bindings)". Where's the direct/developer/1337h4x0r interface to using the same thing that makes QML so bitchin (QtQuick/Scene Graph)? QML _is_ revolutionary... it just isn't what the average C++/Qt dev (user) wants. On 5/16/12, Thiago Macieira <thiago.macie...@intel.com> wrote: > We need a new architecture, which means building stuff from the ground up > with it. It requires a scene graph with retained-mode painting. Yes, QtQuick is this new architecture. I just wish it wasn't exclusive to QML. I agree QWidgets should be 'Done' (because it is)... but it shouldn't be just left their to die. Imperative Declaration of UI structure from within C++ is how us programmers prefer to do it (QWidgets C++ API). It isn't so much to ask for something similar for the future of Qt GUIs (not just for porting ease... but also for familiarity). The imperative declaration of GUI that C++ developers like to use in QWidgets is there for a reason: preference (it might also be the 'defining' way to do it... as in, the xml .ui might translate into C++ calls, idk tbh). Don't remove/ignore our preference and force your own. On 5/16/12, Thiago Macieira <thiago.macie...@intel.com> wrote: > On quarta-feira, 16 de maio de 2012 13.24.25, Atlant Schmidt wrote: >> The FOSS developers HOPE that their interests are congruent >> with those of the mere customers and at least in QT's world, >> there's some evidence that this is true for some customers >> but there is also mounting evidence that this is decidedly >> NOT TRUE for other customers, hence our current debate >> about QML Qt versus QWidget Qt. > > That's not exactly true. The debate isn't about QML vs QWidget. The core of > the debate, as far as I can see, is whether there should be a C++ interface > for making UIs with the new technology. > > I haven't seen anyone support QWidget itself in this thread. Moreover, I > doubt most people know the challenges with enhancing QWidget further. Consider > this: the QWidget & QPainter imperative painting technology is Done. It's not > a > matter of taste, it's fact: graphical technology has moved on. Imperative painting is done, yes... but imperative declaring (how i'd refer to the QWidgets C++ API) isn't. I am sure someone can design a new imperative C++ interface (with huge similarities to QWidget) that uses Scene Graph/QtQuick. > But the point is that we need something new to take Qt forward and be the > basis for the next 5-10 years. The suggestion so far is QML & scene graph > and with a few tweaks it could be made to suit most people's requests. > > No one has suggested an alternative. The suggested alternative is the Upgraded C++ GUI API! Nobody has funded/researched/developed the alternative, however :( > So I suggest we spend our energy discussing those tweaks I mention, what's > necessary to make the technology more attractive to current developers, what > the impact on maintenance will be, etc. This C++ vs QML discussion is moderately important to Qt as a whole... but what about the "I do not want to contribute" (and therefore I'm assuming/extrapolating that others also won't) problem? I think that's a much larger issue. Sure, who the fuck am I? I am an independent developer who is a _user_ of Qt. I hope to one day be in the position where I can (and want to) contribute to Qt. There are many like us and Qt needs the individual developer to want to contribute if it plans on staying ahead of the market. Ok maybe "needs" is a stretch (companies can/will dump money into it for yeeeeeeaaaaaars, keeping it alive support-wise)... but it will definitely improve the overall Qt experience to have individual contributors WANTING to contribute fresh ideas (without the feeling that Nokia would be wasting the profits said contribution would bring to Qt) and code. The Qt Trademark is what it really boils down to. The Qt Project needs to own the Qt trademark, else it will always be shoveling money into the black hole that is Nokia. How much power do the people "at the top" of the open governance meritocracy really have? Can they change Trademark agreements (doubtful)? How about specific portions of the QCA (perhaps more likely)? On 5/17/12, Peter Kümmel <syntheti...@gmx.net> wrote: > On 16.05.2012 20:31, qtnext wrote: > So all you can do is using a system with a "obsolete architecture", diving > deep into QML and writing your own desktop elements, or waiting another one or > two years. I think you hit the problem square on the head... except that a lot of us don't feel like QML Desktop Components are the answer to the obsolete architecture problem... so we're even more aggravated knowing that we have to wait even longer for a solution. Maybe someone will make a C++ interface to QML (using precompiler or whatever)... which would be possible but makes me want to LoL at such a terrible design decision. Thiago, are these the tweaks you speak of to make QML usable for most? A C++ interface to QML + no-v8-requirement + QML bytecode embedded in executable resources. I think I'd actually settle for that (I'd just lmao at the toolchain). It just seems silly to have the QML be the defining interface for communication to QtQuick. A QML extension to a C++ interface (just like how [I assume] .ui XML extends/translates-into C++ calls) makes much more sense from a design and maintenance perspective (I could be wrong). On 5/17/12, Peter Kümmel <syntheti...@gmx.net> wrote: > Then Qt Widgets is perfect for you: mature, stable API. You > only would have a problem when you have to implement features > which are much better supported by QML. QWidgets may be more stable, but it is NOT the more performant of the two. QML/QtQuick uses hardware acceleration whereas QWidgets uses your CPU. Now tell me better which is better in an emedded scenario. For a very recent example of a low-capable-CPU/highly-capable-GPU Qt 5 device, look no further than the Raspberry Pi. You can't get a Pi and then use QWidgets. I mean you can... but then you're wasting the Pi. I don't know what GUI language I'm going to write Pi apps in tbh: Obsolete/stable/slow QWidgets or New/untested/fast QML/QtQuick. The slow/fast difference will probably be visibly notable for certain GUI events on certain programs -- most notably on the Pi. On 5/16/12, Giuseppe D'Angelo <dange...@gmail.com> wrote: > The OP: > - doesn't like the fact that QML has not a comprehensive C++ API; > - does want instead that API; > - doesn't like the CLA and the fact that he would be giving to Nokia > more what Nokia gives him back under a free license; > - knows that such an API won't come from Nokia "soon"; > > The natural consequence is: OP: go ahead and create this technology. > > Make a startup, hire 20+ world-top-class developers, work hard for 1-2 > years, and release your product as a 3rd-party add on for Qt. > > You won't have to sign any CLA, and you'll be free to release it under > any licensing model you want. > > And any bank will be happy to back your company, since, as you say, > - it's ok for you / you're willing to run in the red for some time > - the huge number of people wanting your product will make it > completely repay for the initial investment. > > Does it sound good? Sounds Great. Can you provide funding ;-)? I've already said that all that's needed is a Charity/Business. But in saying this you are pretty much admitting that Nokia themselves do not have a vested interest. The mere fact that it should be contributed as a 3rd party module should signal a problem with the Qt Project infrastructure. Do we want Qt to have amazing 1st party/supported/maintained/tested modules or do we want to have to rely on the community to contribute BASIC FUNCTIONALITY (modern C++ gui -_-) through 3rd party modules? A huge disadvantage (though also an advantage) would be that said charity/business couldn't use the Qt Trademark. Their 3rd party module would probably be specific to Qt. They could refer to Qt... but they couldn't not call themselves Qt. Profits would suffer (this is also an advantage because of the current work required to support/maintain/fork Qt). On 5/18/12, Uwe Rathmann <uwe.rathm...@tigertal.de> wrote: > What I want to say with this is: speedup numbers heavily depend on the > use case and often doesn't mean much for your application. Well obviously. The difference is that hardware acceleration almost always brings the additional advantage of freeing up the CPU. Let's not even get started on how much better a GPU scales under heavier load. Hardware acceleration can speed up your processes (not referring to CPU processes... but the overall task) by an order of magnitude compared to cpu-based rendering. 2.5x sounds like a safe low estimate to me... Hardware Acceleration is something the C++ and QML camp both definitely agree on. Uwe, if you don't think the performance difference between CPU/GPU is that much... you should be perfectly happy sticking to the 'Done' (which almost actually kind of means perfected... so long as you're ok with obsolete) QWidgets. to end, Qt would never have appealed to me (maybe I would have landed on GTK+ instead idk) if the use of QWidgets required me to define my UI in XML. This is essentially what QML is requiring. d3fault _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development