KDE's rough edges... what are your experiences?

Kevin Krammer krammer at kde.org
Tue Oct 29 21:02:12 GMT 2013


Hi Duncan,

as usual thanks for the thorough explanations.
I've noted a couple of minor inaccuracies, so here we go :)

On Tuesday, 2013-10-29, 14:35:29, Duncan wrote:

> Both the kde foundations and the qt it's based on are becoming a lot more
> modular, with the ability for developers to pick and choose the
> dependencies they want/need without having to bring in the whole big
> currently monolithic qtlibs and kdelibs.
> 
> Qt itself is maturing as a developer-community-based toolkit in its own
> right, and qt5 is far more community-driven than any qt ever before in
> history.  As part of that, it's both expanding and going modular, with
> most of its components becoming optional -- developers only pull in what
> they need, and will no longer have to depend on (and ship, for platforms
> where bundling is common) the parts they don't pull in.

The modularisation of Qt5 compared to Qt4 is mostly on the respository level 
though.
Qt4 is already split into several modules which can be used individually, e.g. 
a program can choose to use QtCore, QtGui and QtNetwork and not choose to 
depend on QtXml, QtSql and so on.

That change already happened at the Qt3 to Qt4 transition.

The Qt5 transition splits QtGui into two (QtGui and QtWidgets) but most other 
modules remained the same (library wise, some got their own respository source 
wise as noted above).

> As part of the
> expansion and because it /is/ more community focused now and kde has been
> and remains a large part of that community, parts of what were kdelibs
> are now becoming part of qt5.

Mostly single classes though, nothing in the scope of a Qt module.
Also some contributions of new code inspired by KDE code, contributed by KDE 
developers who worked on the original KDE code.

> Up the stack at the application level, kde5 is breaking up and shipping
> most individual apps with their own version tagging and release timing,
> so apps that are evolving fast can ship updates every month or even every
> week if they wish, while already mature apps in primarily maintenance
> mode might ship an update a year, mostly just to keep them building on
> current libraries with current tools, with the occasional security update
> as well when necessary.

I am not sure that this has been fully established as the new procedure yet, 
but it is one of the possibilities.
Applications might still be released together or in sets, etc.

> the full-featured alternative.  And then there's lxde, formerly a gtk-
> based "lite" desktop, that's switching to qt and cooperating with razor-
> qt in some development areas.

I think they actually are planning to merge. But I could be misinterpreting 
things.

> So the qt5/kde-frameworks-five generation is going to bring with it an
> entirely new level of choice and flexibility, both at the developer and
> user levels, and it's going to be very interesting indeed to watch how
> that ends up working, and what the fallout is in terms of app popularity
> say five years from now.

Indeed!

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20131029/0e0c1d77/attachment.sig>
-------------- next part --------------
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.


More information about the kde mailing list