KDE Frameworks 5: Rhythm

Stephen Kelly steveire at gmail.com
Sat Jan 21 19:49:40 GMT 2012

Kevin Ottens wrote:

> On Saturday 21 January 2012 16:17:38 Stephen Kelly wrote:
>> Kevin Ottens wrote:
>> > There's three main reasons for this rhythm:
>> >  * Qt 5.0 feature freeze is upon us now;
>> >  * CMake 2.8.8 will be released in April;
>> >  * it'd be nice to release KDE Frameworks 5.0 at Akademy[*].
>> You mean 'some of the frameworks'? They won't all be done by then. More
>> stuff will need to get into Qt before that's possible.
> Yeah, I know a couple of them will need some merging scheduled for Qt 5.1
> already (like equivalent to KSaveFile for instance). But if I reintroduce
> the few words I forgot to type which were "a technology preview of" I
> think it's doable. It means it'd build against "qt master" likely
> earmarked to become 5.1[*].

Honestly I don't see a point in aiming so early. It makes mistakes and 'I 
thought it would behave like ABC' more risky and costly. I know you're 
'only' talking about technology preview, but once a technology preview is 
out, some people will say things like 'We shouldn't change things 
significantly now that the technology preview is out' and there will be long 
threads on some mailing list somewhere.

>> > To that effect we did some modifications to the active wiki pages:
>> >  * Now we have one page per Qt version we want to target for pushing
>> >  features
>> > 
>> > in Qt, the Qt 5.0 page contains the really critical stuff we want to
>> > see achieved:
>> > http://community.kde.org/Frameworks/Epics/Qt_5.0_Merging
>> Some of the stuff on that page that isn't close to done is almost
>> impossible at this point.
> Come on, it's just *almost* impossible? So still deserves to be attempted.
> :-)

By someone, but not me. (Apart from the timezone stuff which I am willing to 
do, but it's likely that if I try to submit it to Qt it will be blocked with 
'What does John Layt say', which I can't answer because I can't get a hold 
of him).

>> * command line arguments - potential bikeshed. Discussion would have been
>> needed weeks ago on the Qt5 list for it to be possible. Is anyone driving
>> it? If it really can't wait until Qt 5.1 there needs to at least be a
>> subtask for it here: https://bugreports.qt.nokia.com/browse/QTBUG-20885
>> * KAction/QAction stuff - Don't know what's needed. If QAction needs new
>> virtual method that would need to be determined soon. Is anyone driving
>> that? Again, needs subtask here if it's going to happen:
>> https://bugreports.qt.nokia.com/browse/QTBUG-20885
>> * Ssl stuff - I don't know.
>> * i18n - AFAIU nothing is going to happen in that area.
> Yep, that one we can do without.
>> * refcounted quit - might happen.
> I actually wanted to talk to you about that one. Didn't you have a patch
> aeons ago? What happened to it.

It spent a long time in limbo because some people didn't want it the feature 
in Qt at all, then it was a question of how to prevent bugs in applications, 
but now that might have turned. There's still a long way to go for the patch 
though (at least several days I'd guess), even after more than 5 weeks in 


> Regards.
> [*] That said this mistake of mine in the previous email could have been a
> lapsus in the true sense. Now that we pointed it out (and no it definitely
> wasn't in my plans), it makes me wonder if around that time we wouldn't
> end up in a situation where we'd only miss a handful of class which aren't
> used in API... the list we have targetted for 5.1 seems to indicate that.
> So a small statically linked library 

Which everything depends on ? :) 

> with those class would allow us to
> release against Qt 5.0. Again, not making plans, but to keep in mind maybe
> once we get closer to a splitted kdelibs world.

Again, I don't see the point. I'd prefer to keep full license to change 
things without complaint until we know it works and have started porting 
some applications to it, and have some idea of what the impact on 
applications actually is.



More information about the kde-core-devel mailing list