Qt5 -> KDE5?

Alberto Mattea alberto at mattea.info
Mon May 9 19:17:37 BST 2011


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
> 
> 
> 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.

3) Core apps, or "shall we change again everything?". It took at least 3 minor 
releases (or 2 years since KDE 4.0) to have a fully crash-free experience with 
the plasma shell. Now it looks fantastic, it is modular (desktop, netbook, 
media centre) and light (it is usable on an 800 Mhz pentium III). I would hope 
for a stable 5.0 release, also in connection with point 1). So I'd say don't 
start again from scratch: the current base is solid, extendable, users 
recognize it. Changement is not necessarily for good.

So in the end I fully agree with Olivier: "if there is something we should 
learn from the KDE4 transition, it is not to be too ambitious"

Alberto
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110509/e778c12b/attachment.sig>


More information about the kde-core-devel mailing list