KDE Frameworks 5: Rhythm
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
>> * 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:
>> * 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
> [*] 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