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

[Philip Ashmore]

On 06/07/12 02:51, Alan Alpert wrote:
> 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.
Good point. I googled "using qt private headers" - not very useful.
Could you post a link?
>
>
> 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.
>
>
> --
> Alan Alpert
Philip
>