New Feature for kdelibs (Was: The case for a kdelibs 4.8)

[Manuel "Sputnick" Nickschas]

On Thursday 10 November 2011 10:14:58 Aaron J. Seigo wrote:
> On Wednesday, November 9, 2011 23:44:21 Andrea Diamantini wrote:

> > And it will be based on the upcoming (not yet released) Qt 4.8.
> 
> sure; but this is a non-relevant detail.

Indeed...

> > Thinking about "frameworks" without having yet a decent idea of what will
> > be Qt5 is impossible for me.

Qt5 is nearing feature freeze, and there is a pretty decent idea of what it 
will be like. If I remember correctly, the release of 5.0 is currently planned 
for Spring 2012, around April. That is not far in the future, and we're not 
talking vaporware here.

Mostly, it's going to be source compatible (save some easily scriptable 
changes like header/class renaming), the merging of QtMobility into Qt proper 
(probably irrelevant for most of KDE), and modularization (again, irrelevant 
from KDE's perspective when it comes to source compatibility and porting). 
There's also the switch to QtQuick2, which also is irrelevant to most of KDE.

This is not going to be like the Qt3 -> Qt4 transition which required major 
rewrites for consumers. In fact, those of us already working with Qt5 feel 
right at home. At least for me it doesn't feel any different than developing 
for Qt4.

> actually, Qt5 is irrelevant to most of the work that needs to be done in
> frameworks. we can, and are, working against Qt4 right now. most of the work
> is modularization and modernization (while preserving source compatibility)
> 
> we are merging some things upstream into Qt5, and the things that are merged
> upstream are going into a small temporary library call libinqt (lib in qt
> ;). when Qt5 arrives, that library will go away and we will be able to move
> to basing frameworks on Qt5. between now and then there is a lot of work on
> the modularization and modernization work.

That is in fact the major part of the frameworks effort, as I understand it. 
And it is important to identify, separate and port the things that should go 
from kdelibs into Qt5 *now*, as things that require BIC or even source changes 
need to be done before Qt's feature freeze, i.e. before 2012. If that deadline 
is missed, there won't be another opportunity for the lifetime of Qt5. Thus, 
the more people now helping with modularizing kdelibs and upstreaming whatever 
makes sense to upstream, the better. At least from the perspective of someone 
who would love to see useful KDE technologies as a part of the Qt framework, 
to easily use it even on platforms that still don't support KDE deployment 
easily :)

> for instance, Sune's proposal to improve KNotification requires absolutely
> nothing from Qt5. having that done before Qt5 arrives would actually be a
> bonus as we wouldn't have to juggle too many different kinds of changes at
> once.

And the actual porting to Qt5 won't require much effort or time then, I'd 
expect. Maybe on the build system side, but certainly not on the code side. 
Even less so for the things sitting on top of Frameworks.

BR,
~ Sput
-- 
Manuel "Sputnick" Nickschas ("Sput" on Freenode)                  |  (o<
Member of the Quassel IRC Project - http://quassel-irc.org        |  //\
Come visit us in #quassel!                                        |  V_/_