[Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)
alan.alpert at nokia.com
Fri Jul 6 09:08:08 CEST 2012
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
> 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
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.
More information about the Development