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

Wed Oct 30 09:41:53 GMT 2013

On Wednesday, 2013-10-30, 08:59:34, Duncan wrote:
> Kevin Krammer posted on Tue, 29 Oct 2013 22:02:12 +0100 as excerpted:
> > 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:

> >> 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.
> 
> Agreed, but I think that misses a part of the overall picture just as I
> did, because we're focusing on different close-ups of the overall picture.

I am not sure. I think we were both looking at it from the app developer's 
perspective, but lets see :)

> At least here on gentoo, qt4 has in fact already been for some time a
> convenience metapackage that simply pulls in all the separate qt4 module
> packages, while individual apps depend on the individual qt4 modules the
> need, tho I'm unaware to what extent other distros have split up qt4.

Also true for Debian.

> But with a quick check (on 4.8.5) confirming it, qt4 is still shipped as
> a single tarball

True, but that is of no concern to the application developers.
They have not only the option of specifying concrete dependencies, they 
actually have to do it.
There is no such thing as "enable all of Qt", it is always a concious choice 
of individual Qt modules, with only "QtCore" and "QtGui" being preselected by 
default.

> For both kde and qt, those tarballs generally reflect upstream
> development repo layout altho I guess there are some exceptions.

Mostly correct. I think the Qt5 packages contain most repos, e.g. qtbase + 
qtdeclarative + qtwebkit and so on.

> But I don't believe "mostly on the repository level" fully reflects the
> reality of the situation, however, tho you're correct in that it's part
> of an ongoing process.

Well, that is the main change, splitting wise, between Qt4 and Qt5 :)
It is not even important for most people working on Qt since there is a way to 
checkout all repositories that make up Qt in one go.

> The repository splits do indeed reflect an
> ultimate separation that has in other regards already occurred, yes, but
> it's my belief that despite the earlier conceptual separation, the
> combined repositories were holding the otherwise mostly separate modules
> hostage to a combined immediate future, and that fully separating them
> not only reflects evolving reality, but will in fact free them from the
> limits that were being artificially imposed on them due to that current
> situation and immediate qt4 future, such that we will now see the
> individual modules evolving further now that those restrictions are
> lifted.

All the modules that are not considered addons are still developed together. 
It makes developing Qt a bit less resource intensive since you don't have to 
checkout or build repositories that you are not working on and the Continous 
Integraton system does not have to do that either.

But I think most developers still run the scripts that checkout all of Qt.

> In the qt realm, that's likely to result in the individual modules
> becoming far more popular as library dependencies, since it'll be much
> more like pulling in an individual library dependency to take care of a
> specific function, instead of having to pull in the whole heavy ecosystem
> when most of it wasn't to be used.

But for Qt that was never the case after Qt3.
As I wrote above, each module has to be explicitly activated. The only module 
that changed was QtGui, so one can now do a QtQuick application without 
pulling in QtWidgets.

Most desktop applications use widgets, so there is no change for them in 
matters of dependency size.

> > 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 I said, while (AFAIK) that's literally true, I believe it's missing
> the larger picture, and that now freed from the heavyweight bonds of
> having to depend on the entire qt package in many cases, individual qt
> modules and libs will likely see dramatically increased use over the
> coming years, as more distros (generically, not just Linux) split up qt
> into these modules and thus dramatically lower the dependency cost to
> depend on the functionality of just one or two of them.

Most parts of Qt are still in the same repository and the release package 
contains at least the same modules as before, i.e. now the code from muliple 
repositories.

Whether or not that is packages as one package or separate ones will still be 
up to the packagers.
This has never impacted developers, who always (since Qt4) had to chose 
modules explicitly.

I am not aruging about the kdelibs case, which is entirely different.

> >> 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.
> 
> Thanks for pointing that out.  I did mention in passing, but arguably
> should have given more emphasis to, the likelihood that some category-
> modules (I gave the example of kdegames, but kdepim is likely one of the
> more obvious ones due to a common dependency on akonadi) will remain
> unified.

Actually the common dependency makes it easier to ship the applications 
separately, since they no longer depend on each other.
The binding factors are now the shared libraries that are not considered 
viable as public API and, to a lesser extent, the Kontact shell.

> So instead of everything being part of say kde 5.1.2, we might have
> kdegames 5.3.5, kdepim 5.4.3, and plasma-workspaces 2.1.2, but still
> possibly have dolphin 5.2.0 and konqueror 5.0.3.  (This takes into
> account the elsewhere mentioned plan of plasma going with a 2.x version
> number for frameworks five, but other apps or category-modules may
> similarly choose "non-five" majors or start with 5.x but evolve to 6.x
> and beyond during the life of frameworks five.)

My guess is that most application modules will keep the same version number, 
i.e. release together like KDE SC, but yes, that would be possible.

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/20131030/8b89c36f/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.