[Development] Is overriding an existing virtual method 'BC' in Qt 4?

Knoll Lars Lars.Knoll at digia.com
Mon Oct 15 09:52:34 CEST 2012

On Oct 11, 2012, at 5:37 PM, André Pönitz <andre.poenitz at mathematik.tu-chemnitz.de> wrote:

> On Thu, Oct 11, 2012 at 11:48:26AM +0000, Sorvig Morten wrote:
>> [...] In general, I think this is something we'll see again. Platforms
>> change under our feet and we need to adapt. Apple and Microsoft do not
>> put OS updates on hold because we are working on a major release. The
>> fact that Qt often "lags" platform releases is a major point against
>> using Qt and something we must get better at. A sensible solution is,
>> in my opinion, to allow feature and API development in Qt 4 when the
>> platform maintainers find it necessary.
> In case it matters, I fully agree.
> Even with the goal to encourage people to move from Qt 4 to Qt 5,
> backporting the "easy parts" makes sense to give them a kind of
> stepping stone before they actually jump.

> That is "_if_ they jump". A part of the audience seems to be quite
> happy with 4.x nowadays. Forcing them to invest in an upgrade does
> not sound overly prudent, and neither does anything that might be
> interpreted as leaving them behind.

I do agree as well for places where we need to keep up with changes in the underlying platforms. We should make sure Qt 4 users are not feeling like they are being left behind. At the same time we should be careful about what we add to 4.8.x, both to not destabilise it and to make sure most of our focus goes towards Qt 5.

And to address Thiago's question: I'm against making further API additions to Qt 4 than what's strictly required to keep up with platform changes. Ie. let's not add any other new APIs into the 4.x series. Whether we then call it 4.8.5 or 4.9.0 is then a pure policy decision.
> Maybe it's generally time to reconsider the set of existing goals.
> Some of them are from a time when - let's put it politely - the
> circumstances were different. I would be surprised if an honest
> re-evaluation today would lead to the same priorities as a it did
> only a couple of months ago.
> Andre'
> PS: Before the shouting starts: I am all for getting Qt 5 out as
> soon as possible. I am _only_ saying that alienating Qt 4 users
> makes no sense. Not now, and very likely not for quite a while.
> Existing users are a benefit, not a burden.

Yes, many things have changed over the last couple of months. I fully agree with you that there we need to do our best not to alienate any user of Qt (whichever version they are currently using). At the same time getting Qt 5 out should be the top priority for all of us. 


More information about the Development mailing list