[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 02:32:06 ext Philip Ashmore wrote:
> On 06/07/12 02:05, d3fault wrote:
>  > For programmers, a lot of you are pretty bad at reading. Hopefully you
>  > understand designs better:
>  > 
>  > Current Non-Interoperable Design: http://bayimg.com/oapnKAAdJ
>  > Which will probably eventually turn into: http://bayimg.com/oAPnpAaDj
>  > 
>  > Ideal Solution: http://bayimg.com/PaPneAadj
>  > 
>  > The sooner we get off the wrong path, the less code/resources we waste.
> 
> I usually resist the temptation to jump onto a shaky bandwagon, but I've
> yet to
> hear any clear arguments against
> 
>     class QtQuickSceneGraph : public QSceneGraph {...}
> 
> as being the way ahead.
> 
> Take a quick look at clang's development progress.
> They have api changes as the result of community effort and everyone plays
> catch-up.
> 
> Their focus isn't on the api everyone will be using in 5 years because
> they'd
> rather write something that's as good as it can be now.
> 
> The whole point of open source is that you can work with a changing api and
> still burn it onto DVD or firmware, just as long as you can get the
> version used
> if you need to change your code.
> 
> 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.

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.

--
Alan Alpert