[Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)
contact at philipashmore.com
Fri Jul 6 19:58:01 CEST 2012
On 06/07/12 12:24, Thiago Macieira wrote:
> On sexta-feira, 6 de julho de 2012 17.08.08, Alan Alpert wrote:
>>> Most c++ developers wouldn't want to choose between stability and
>>> I'm adventurous, just point me at the "qt private header forum" where
>>> interface changes are community-driven and I'll sign up.
>>> I'll understand if this has to wait until after Qt5 is released.
> There's a mailing list you can join that discusses the development of all Qt
> internals... oh, right, this is it :-)
> Welcome to the community-driven forum to discuss changes to anything.
>> Private headers are not discussed in some private forum. They are subject
>> to the same governance structure as the rest of Qt, except that there's
>> less impetus to talk about API changes. At the end of the day interface
>> changes are still driven by the people who write them and the discussions
>> during code reviews. The "private" refers to the level of compatibility and
>> documentation guarantees (none), not the development process. For example,
>> I got the impression that most of the container refactoring that Thiago was
>> discussing on this list were changes to the private implementation classes,
>> not the public API.
> It was. The public API for QVector, QString, QByteArray, QVariant and QList
> was exactly the same.
It would be great if there was an opportunity for those interested to
get acquainted with QtQuick + QML implementation design, so they can
It's been a while since I looked at Qt5 source code, but if it included
documentation relevant to the code included, that would be ideal - this
documentation would/should then keep in step.
Also, a Changelog detailing private header changes plus the change
motivations/objectives would give private api users a most welcome heads
up - but by then it would be a fait-accompli - the opposite of community
So maybe there should be a forum specifically for private api design
discussion, where contributors could interact before changes are
committed, allowing them to participate, even provide patches.
> Development mailing list
> Development at qt-project.org
More information about the Development