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