[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 07:23:11 ext Philip Ashmore wrote:
> On 06/07/12 02:51, Alan Alpert wrote:
> > On Fri, 6 Jul 2012 02:32:06 ext Philip Ashmore wrote:
> >> ...
> >> 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
> > 
> > As I understand it, this approach requires you to have the exact same
> > libraries as the point in time which you built against, due to the
> > unstable
> > APIs. This is a feasible approach for open source, because you can go back
> > in the history to get it or just build your own copy.
> > 
> > If this is the route you want to go down, then what's stopping you from
> > using private headers? The main constraint with private headers is that
> > you need the exact same version of Qt on the system as you build against
> > (because the API is unstable). Accept that problem and you can use the
> > private headers from today, or even from quite some time in the past.
> 
> Good point. I googled "using qt private headers" - not very useful.
> Could you post a link?

I don't think it's in the public Qt docs, because private headers are not 
documented as part of the 'public' Qt docs. Here public is meaning what Qt 
publishes as its official API, and the private headers are not part of that 
because they don't meet the compatiblity guarantees of the Qt product. Due to 
their rapidly changing nature, private APIs also don't need to meet the 
documentation requirements of public API. But adventurous people rarely read 
the docs anyways, so it's not a practical problem ;) .

To use private headers, you may need to have built Qt from source as they 
aren't usually part of installed packages. If you have them, they'll be under 
include/QtModule/5.0.0/QtModule/private for each module. Then you can include 
them as private/header.h, e.g. #include <private/qfile_p.h> . For qmake to add 
the right include paths, you have to add module-private to your QT variable, 
e.g. QT += core-private to get qfile_p.h.

To continue the example of using QtCore internals, don't go crying to Thiago 
if qfile_p.h changes. It's allowed to do that at any time, *without warning*. 
By using private headers you assert that you know this can happen and that 
you'll deal with it in your code if an internals change breaks code that 
depends on private headers. This is why it's not recommended for most 
developers, and this is why there are warnings everywhere. Only use private 
headers if you understand the risks.

Another complication is that some symbols also aren't exported out of the 
library, for example most of the QtQuick private symbols are only exported for 
developer builds. That's easy to workaround though, especially if you're 
building your own patched Qt.

> > Simply by being open source the private headers of Qt would seem to meet
> > your requirements. Qt still provides API stability in the public headers
> > because it is of enormous value to some people, I see no reason that the
> > other people can't use private headers as much as they want (just keep in
> > mind the warnings like "This header file may change from version to
> > version without notice, or even be removed" ).
> > 
> > Just keep in mind that the average developer probably prefers stability
> > (and probably doesn't work on clang :P ). So Qt shouldn't be pushing
> > using private APIs as the recommended approach. But it's there for the
> > adventurous.
> 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.

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.

If you want to discuss specific changes to QtQuick internals, e.g. something 
which improves the API of private headers, you can use the standard channels 
like this mailing list; #qt-labs; or posting something to codereview. There 
may even be less argument than usual, because if we make a mistake in private 
API we can just change it back immediately.

--
Alan Alpert