On 06/07/12 02:05, d3fault wrote: > For programmers, a lot of you are pretty bad at reading. Hopefully you > understand designs better: > > Current Non-Interoperable Design: http://bayimg.com/oapnKAAdJ > Which will probably eventually turn into: http://bayimg.com/oAPnpAaDj > > Ideal Solution: http://bayimg.com/PaPneAadj > > The sooner we get off the wrong path, the less code/resources we waste. > I usually resist the temptation to jump onto a shaky bandwagon, but I've yet to hear any clear arguments against
class QtQuickSceneGraph : public QSceneGraph {...} as being the way ahead. Take a quick look at clang's development progress. They have api changes as the result of community effort and everyone plays catch-up. Their focus isn't on the api everyone will be using in 5 years because they'd rather write something that's as good as it can be now. The whole point of open source is that you can work with a changing api and still burn it onto DVD or firmware, just as long as you can get the version used if you need to change your code. Qt itself is IMHO strugging with the divide between closed source == api stability but dates badly open source == dynamic and occasional api breakages but keeps current My vote would be to have QML/QtQuick follow the clang route and not be frozen, and let the api changes fly - the QML layer won't change as frequently as the c++ interface, so that would make QML people happy, and c++ people less sad. The previous arguments about what does and does not belong in QtCore are evidence that Qt has components that are at different stages of maturity, and dealing with that reality is something that I think should affect the release schedule. Regards, Philip Ashmore > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development