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

[Duncan]

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

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.

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.

But with a quick check (on 4.8.5) confirming it, qt4 is still shipped as 
a single tarball, much as early kde4 still shipped many of its category 
packages (such as kdegames and kdepim) as monolithic tarballs, even when 
they were already split into individual packages internal to the tarball.  
(FWIW, in an ongoing process, those big kde category tarballs have been 
splitting into individual package tarballs as kde4 has matured, with a 
lot more but much smaller tarballs for say 4.11 as compared against say 
4.5.)

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

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

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.

Of course that's mostly at the dev level, as will be the changes at the 
kdelibs and base frameworks five level.  The far more visible results at 
the user level will be as I said, individual kde apps chosen for their 
genre leading features and/or because they are the best match for a 
specific need, as users are able to pull them in with just their direct 
deps, instead of having to pull in an entire kde and qt ecosystem just to 
support a single app they want, thus making it less likely they'll use 
ANY kde apps, unless they happen to be willing to standardize on nearly 
ALL kde apps.

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

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

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

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

I had heard similar rumors, but chose not to explore /that/ whole angle 
of things in an already long post, when their merging or not didn't have 
much bearing one way or the other on the point I was making in any case. 
=:^/

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

=:^) and thanks!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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