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

[Michael]

Am Tue, 29 Oct 2013 14:35:29 +0000 (UTC)
schrieb Duncan <1i5t5.duncan at cox.net>:

> Michael posted on Tue, 29 Oct 2013 06:48:40 +0100 as excerpted:
> 
> > Oh, KDE4 is more or less in "maintenance-mode"? Err... scratch
> > that. As of now I still believe maintenance is something that does
> > not apply well to the KDE-kind-of development-style, so KDE4 is
> > more or less obsolete now?
> 
> That would seem to be the case, yes.
> 
> > Well, it would fit the (current and as of now unofficial)
> > description. If KDE5 will have the same QA-style, I guess KDE will
> > go into the history books of open source software, as always shiny
> > but buggy to a degree that it may even be unusable.
> 
> Call me an optimist (heh, wrote that before noting your email address 
> =:^) if you will, but I believe the kdeers are on the right track
> with this kde frameworks five stuff.

That means you think with QT5 and KDE5 the overall bug- and
maintenance-situation will improve?


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

How I see it, that would only help to get the issue-list down for
people NOT using the full-stack of KDE.

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

More community-driven as non-qt frameworks as well, or at least on par
with them? And regarding the issues discussed in this thread, I don't
see a necessary benefit from the possibly higher factor of
community-drivenness there too. And I doubt the issues I have in mind
here are QT-issues.

> 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.  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.  But at the same time, because qt's becoming more modular and
> much of it is now optional, all those extra features aren't bloating
> qt5 out of control, because if a developer doesn't need them he
> simply won't pull them in, and the modular components that are pulled
> in may well be far slimmer with qt5 than with qt4.
> 
> At the same time, kdelibs and the kdebase platform is similarly 
> modularizing, allowing the same choice at the kde developer and user 
> level as well as blurring the lines between what's qt and what's kde, 
> since parts that were once kdelibs are now qt, but either way,
> they're now optional, so a formerly kde app may actually find itself
> only needing qt now, and even if it does pull in some kde libraries,
> because both the kde libs and qt are going modular, the dependencies
> may now well be smaller as a full kde app than they were previously
> as a qt-only app!

Off-Topic (writing style): Both paragraphs repetition over repetition of
former statements with only small amounts of new arguments. Do you see
that now in retrospect?

On-Topic: Nothing new to add. At least nothing that screams to be added.


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

With QT4 / KDE4, could applications not just build against maybe older
qt- / kdelibs which would then not prevent fast-paced
application-development?


> So the kde frameworks 5 core is going to be MUCH smaller, while most
> of the bundled apps we know as kde today will be unbundled and
> shipped separately, either as individual apps or possibly as a
> functional bundle -- dolphin and kmail and rekonq and konqueror and
> plasma will likely all release separately, with their own versions.
> (Actually, some of them have their own versions now; kmail is version
> 2.something these days for instance, but nobody knows their kmail
> version without looking, they simply say kmail 4.11.2 or whatever,
> the kde version.)  But kdegames (for example) may still ship as a
> kdegames bundle, with a common kdegames (not kde) version.

OffTopic: Different view / some new arguments on previous statements.
Apart from that: repetition. And you somewhat answer stuff that was not
asked for. You went into a possible direction ahead which hinders me
from a natural way of the "asking and answering"-thing, as you did
answer stuff that would fit a question I might ask at least partly.
That means if I ask a slightly different question which you might have
anticipated, you'd have to recap stuff you said already in earlier
mails again or point others to that former mails from you so they can
do the recapping on their own. EIther way, it confuses people and makes
the whole discussion needlessly complex.

OnTopic: See the question I asked in the last paragraph. The new stuff
you wrote here would fit there to a degree, BUT the answer would go in a
slightly different direction, as my interest lies (more focussed)
elsewhere. That means I can't ask a question here, as it would mean
repetition on my part with a slight change of direction. So I guess I
ignore this paragraphs content altogether and just wait on the answer
of the question in the paragraph before.


> That means currently qt-but-non-kde apps and desktop options may
> become more popular as well.  There's smplayer, and the razor-qt
> desktop.

Right, there *is*! No idea why the new "de-coupling style" benefits
such projects. BUT ignore the question you might see here, as it will
go in a direction which is out of the scope of this thread. Really,
don't answer the question, ignore it.


> The effect should be that individual kde apps will be chosen on their 
> merits, no longer simply because they're part of kde, and people
> doing what I'm effectively already doing here, mixing a few kde apps
> with a few gtk apps with a few independent apps, picking the app in
> each case that best fits their needs, will become much more common.

I really don't see *any* important change there. As all sensible users
already know that they can mix applications today. There was never an
issue with that. And no one I know would suggest otherwise. I use
K3b and Amarok for years now on all DEs. The only benefit I see would
be a possibly smaller dependency impact, slightly less used
harddisk-space, which isn't a big problem these days anyway and wasn't
for a long time. But of course a good thing nevertheless. And even
here, out of the scope of this thread.


> Of course since I'm effectively already doing that, rejecting kmail
> since I don't like its akonadi and semantic-desktop dependencies and
> don't need that additional functionality, preferring the gtk-based
> claws-mail, and preferring firefox to konqueror/rekonq, but running
> it all on a (semantic- desktopless) core kde desktop including plasma.

So do I, and many others (repetition on my part).


> But what's going to be interesting is what happens with plasma vs the 
> relatively new and much lighter razor-qt.  I expect the latter to
> become very popular as a kde-lite desktop base, while plasma will
> continue to be 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 expect quite
> a few former lxde folks will end up running more kde apps, since the
> dependency gap will be FAR smaller than it was with gtk, and some
> former kde/plasma users will end up finding they prefer the lxde
> desktop as well, since it'll now integrate far better with the kde
> and other qt apps they continue to run.
> 
> 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.  Throw in the coming
> X-to-wayland switch, and the Linux application and desktop landscape
> could look VASTLY different five years from now!  Which apps will
> survive and thrive, and which will lose popularity and may even cease
> development all together?  Will there be a new sort of bundling going
> on to replace the desktop environment paradigm that seems to be
> dissolving before our eyes, or will independent flexibility be the
> rule of the day?

We'll see, but different topic (but interesting nevertheless). So let's
drop that kind of future-predictions here. :)

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