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

[Alan Alpert]

On Fri, 6 Jul 2012 18:58:01 ext Philip Ashmore wrote:
> 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 called reading the source code. Try asking questions on #qt-labs if there 
are parts you don't understand. If there's sufficent interest, perhaps there 
could be a session on it at the next contributors summit, but reading the 
source code is always the default option available to you for an open source 
project.

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

Maybe you're thinking of gerrit, where we post all of our pending changes for 
review and comment before they are committed? The gerrit web interface even 
allows you to provide patches :) .

People are already talking about pending changes as much as they feel like, 
creating new forums isn't going to change that. Because private API changes 
more often there's naturally less discussion about it before it happens - you 
don't need a big consensus to change private API, you just need a +2. There 
certainly will continue to be developers who don't discuss changes to private 
API before pushing them to gerrit, because a greater barrier to change 
undermines the whole point of private APIs: rapid change. Furthermore, this 
means developers tend not to have the time or inclination to explain these 
changes to onlookers.

If you have specific issues with the QtQuick private APIs ask about them, or 
provide a patch, just focus on a concrete problem because that's the type most 
likely to be solved. The only 'problem' with the QtQuick private APIs I've 
heard so far is that some people don't like them private, nothing to do with 
the APIs themselves (and the result of that discussion, as I recall, was that 
no-one stepped up to do the API work required to make them public quality).

--
Alan Alpert