[Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)

Philip Ashmore 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
>>> performance.
>>> 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 
catch up.

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 
involvement.

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.

Philip
>
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



More information about the Development mailing list