Kügler: Plasma’s road ahead

:-)

Which is why I now use Clementine. "Amarok for KDE 3" rolled forward to KDE4, not the mess that was the KDE4 rewrite.

Cheers,
Wol

It's odd how far/low we're falling in this arena when it comes to the two biggest free desktops, gnome/kde. I believe it was Paul Graham who noted that great code generally comes from redoing existing logic, and that rewrites tend to toss out the baby with the bathwater, that is, all the existing logic that was created to solve issues is removed, and you start fresh, which means you have to fix all the same things again, basically, and things just don't work anymore, until they are fixed. In other words, the kde 3>4.x cycle, then the kde 4>5.x cycle, or the gnome 2>3.x cycle, etc. Horrible waste of finite free software developer hours/days/weeks/years.

I have one program whose code I really dislike because it's a royal pain to work on, but the entire thing is basically logical handling of bad data, very very bad data, so while someone could rewrite it, they'd literally have to do so line by line to not lose all the fixes. That was in fact also a rewrite of an older version of the logic. Not mine. That rewrite lost exactly zero features in the process, just improved overall flexibility and feature support.

Personally I view this problem more as a failure to do good architecture, not at all a question of working on someone else's code or not. The linux kernel is filled with 'someone else's code', and seems to roll along fine without major rewrites version to version. Libreoffice, the same, openbsd, freebsd, apache, the same. These are all old projects that are not rewritten routinely, and that basically keep working over many years time. All with very large code bases. Now and then I assume they are cleaned up, modernized, and of course, there are regressions etc, but in general, the goal is to not do that. Particularly not with user facing stuff like libreoffice.

It's in my opinion hugely disrespectful of the finite man hours available in major free software projects to just blow it all up and have the entire desktop be unusable for a year or more, but I'm starting to believe that certain projects simply are not well run, and don't enforce good coding rules, and don't have good solid architecture that you can work with for a long time, and therefore have to blow it all up fairly routinely, at great loss to users and the overall free desktop experience. One of the, if not actually __the__ reason the linux free desktop has failed to make any significant inroads on the non free desktop market, constant desktop desktop breakages and failures. Lack of reasonably coherent and stable desktop apis for even the simplest things really damage the ecosystem, always have, always will, until you see patches added to patches with things like flatpack/snap etc, which are the proverbial one more standard to fix the flood of standards, none of which would have been an issue with a stable desktop api, which appears to be something that's become taboo to discuss anymore. See for example gnome/gtk refusing to lock down their api until the very end of the 3.x cycle, which is the exact opposite of how it should work, a strong sign of significant lacks in the design/architecture area of the gnome/gtk project. Even the simplest thing, templating, is too hard for them to lock down, so sub releases in gtk 3.x break those apis, making life suck for people who were using the gtk toolkit for their software, but nobody at redhat seems to consider this a valid issue since that's not invented there.

It's actually kind of funny to watch desktops try to do bad copies of OSX, all the while totally failing to grasp that what apple users love fanatically about their desktops is the fact very strict rules are applied to interface changes, and stuff doesn't just change and break all the time. I know apple has really bad internal programming etc, have to deal with those bugs too often, but the intent is to provide a consistent user experience, which is a point the desktops that seem to want to copy the superficial look/feel of osx seem to totally miss, completely, and utterly.

So no, I don't buy that line at all, this is far more about failing to implement much stricter handling of changes, better initial architecture, etc.

I've started realizing that the longer I use free desktops and software, the less interested I am in watching projects break themselves, so now I tend to just walk away, even when I was very heavily involved in supporting them, as was the case with kde, at a certain point it's just obvious to me the things aren't well run, if they were, stuff wouldn't be failing on major version changes.

There's two kinds of rewrites I'd say, the good kind, where the code improves, but the features don't degrade, and the bad kind, where everything is broken for years as people struggle to try to restore features that were removed. Or of course, the gnome way, which appears to just remove any complicated feature that requires skill to handle, until you can commit a new version with only 14k of changed lines. About what one reasonably skilled coder can do in 6 months more or less, give or take.

But the problem is, you really need to be careful designing these things to begin with. My guess is if you started with kde 1 or 2, then started modularizing it, refactoring, abstracting away a bit from the toolkit specific version, you might actually end up with something worth moving forwards with, always with an eye on speed, performance, and eye candy treated as what it is, eye candy, that should never dictate anything central in the desktop.