Qt5 -> KDE5?

Alexander Neundorf neundorf at kde.org
Mon May 9 21:02:28 BST 2011

On Monday 09 May 2011, Alberto Mattea wrote:
> In data lunedì 9 maggio 2011 18:03:18, Olivier Goffart ha scritto:
> > Hi,
> > 
> > With Qt5 around the corner[1], I think it is time to start thinking about
> > KDE5

That's quite surprising for me.
The last statements I heard about a Qt5 were "not planned for the forseeable 
future". And now next year is quite soon.

> > Raw summary:
> >  - Qt5 is planed to be released in about one year from now if everything
> > 
> > goes well.
> > 
> >  - It should be mostly source compatible with Qt4, and is just an
> > 
> > opportunity to break binary compatibility.
> > 
> >  - QWidget just stay for compatibility. All focus is put on QML. Do not
> > 
> > expect new development on QWidgets from Nokia.
> > 
> >  - The "OpenGouvernance" should finaly come into light, meaning we (as
> > 
> > KDE), can contribute easier to Qt.
> > 
> > 
> > I guess it make sens, as Qt breaks binary compatibility, to do the same
> > in kdelibs.
> > Does that mean "KDE 5"? or "KDE SC 5"? Not necessarily.
> > We can break binary compatibility, and change the .so version of our
> > library without changing the major version of KDE itself.
> > But I think it would anyway still be a smart move to do it.
> > 
> > And I think this is a perfect opportunity to get some KDE class in Qt as
> > we planed. [2]
> > 
> > Some item we might want to think about:
> >  - Do we want "KDE 5" to be a big change, or just a small increment?
> >  
> >  - Do we want to focus on QML, or stay with QWidget?
> >  
> >  - Shall we try drive Qt5 based on KDE5's need?
> >  
> >  - Do we have more visions for what KDE5 should or should not be?
> > 
> > I guess there is as many opinions as people involved :-)
> > Many things to think about, and that can be discussed further, and
> > decided in Platform11 [3] (I will be there)
> > 
> > But in my opinion, if there is something we should learn from the KDE4
> > transition, it is not to be too ambitious.
> Hi,
> my 2 cents as a long time KDE user and recent time contributor.
> 1) The name. Some people have tried KDE 4.0, didn't like it (either for the
> instability ore the missing features) and searched for something else. I've
> personally seen how difficult is to change a "first bad impression" with
> some users. Probably if we took KDE SC 4.6.3 and release it as "KDE5"
> these users would say "wow, that is fantastic! A lot better than KDE4!".
> So a new major version is a big opportunity to "refresh" the name.
> 2) Binary compatibility. It has taken four years to port most KDE3 apps to
> the new infrastructure, and some (like Kooka) never did it. Many projects
> just ended the transition from KDE3. Experience shows that even a well
> alive project may not have the necessary manpower to do a drastic rewrite
> of the code. So I would take Qt5 as an opportunity to fix legacy
> interfaces without caring about binary compatibility, but (following Qt
> direction) the effort to port existing code should be nowhere near the one
> needed from KDE3 to KDE4. This would allow to maintain the good condition
> "there is a KDE app for everything", which has been just recently achieved
> again. So, from a technical point of view, don't rush to drop QWidget and
> switch to QML; let them live together for all the necessary time, and
> ensure a smooth step-by-step migration is possible.

I agree 100%.
We should see this only as a chance to break ABI.
I can remember when the KDE4 efforts started it was three things
* port to Qt4
* break ABI
* "fix" some ugly API from KDE3

... where the last point amounted to more and more small changes all over the 
place for months.
So from my POV, we could use this as a chance to reorganize our libraries to 
make them fit for mobile, and more fit for OSX and Windows and 3rd party 
developers, but try to keep the APIs really as much as possible as they are.
IMO we can't afford another big porting effort already again for all the KDE 
applications which have just been ported to KDE4.

Let QML exist and grow and flourish, but let's not try to introduce it big way 
in KDE in the next 12 months or so.

More information about the kde-core-devel mailing list