On 5/23/11 1:09 AM, "ext Coda Highland" <chighl...@gmail.com> wrote:
>>>Why would it be a show-stopper for 5.0? >> >>I believe there is some confusion going on. Some people seem to think >>that >>Qt 5.0 will be QML-based only and that QtWidgets will basically be a >>Qt4-API-compatible module made with QML components for desktop, >>rewritten >>from scratch. >> >>The point of Qt 5.0 is to bring the GL-based scene graph at the core of >>Qt; on the top of that, you will still have two worlds: QML & widgets, >>exactly like in Qt4. The only different is that today QML is painted on >>top >>of a widget (QGraphicsView); tomorrow, QML will go directly to OpenGL >>through the scene-graph, while Qt Widgets will be drawn by QPainter >>onto a >>QImage and the scene-graph will blit it. That's all. But QtWidgets in >>Qt5 >>will still contain 99% of today's Qt4 widget code, so it will mostly be >>compatible with Qt4 C++ code. And you will still be able to create a >>QWidget in C++ and display it without touching QML; it's just the >>internals >>that change. > >I, for one, have no such misconception. I already knew this was true. > >My concern is not that you won't be able to use QtWidgets. My concern >is that Qt5 is going to be released with the "recommended" UI >components being in an unfinished state. Who's going to know how to >write Qt5 programs if QtWidgets is called "old" and QML is showing up >on all of the shiny demos and examples and tutorials but you can't >actually write a normal real-world native-looking app with them? > >This doesn't sound like a good idea at all. It's better than delaying Qt 5 by another year. That being said, we have some efforts going on to implement desktop components for QML. It will most likely not be 100% complete with 5.0, but that's what we have 5.1 for. I remember that when we released 4.0, people where crying out loud because we had removed QCanvas (the predecessor to QGraphicsView from 4.0) and didn't have the replacement ready yet. While not optimal in the short term it was the right thing to do for the long term. And here the situation is a lot better, because you won't loose any features. So I can't really see how this can be a real issue. > >Being combined with there being a lack of certainty about the >migration path only makes the matter worse -- Thiago said just a >couple posts ago that no one knows how the integration between the two >UI tools will work. This is Qt3to4 all over again: Either you're using >a narrow enough common subset of the features that it just works fine, >or you're stuck rewriting large portions of your code before you can >do anything with it. That common subset's certainly larger this time, >but as soon as you want to use one of Qt5's new features (and why else >would you move to Qt5?) the path becomes uncertain. We move to Qt 5, because we need to break binary compatibility if we want to efficiently do certain changes. > >So I think that it's a pretty big showstopper. In my opinion, Qt 5.0.0 >should not be released until the "recommended" way of making user >interfaces can be used for the common use cases without regression and >the migration path for Qt 4 code is clear. No. Release often, release early is what we need. And then build upon what we have and do incremental improvements. I've too often seen projects where you wait until you have 100% of what you think you need implemented and the project never gets released. Cheers, Lars _______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
