Yet another failed KDE release?

[Duncan]

dE . posted on Thu, 28 Mar 2013 09:53:39 +0530 as excerpted:

>> Yes, that's the same base kde2 config now running kde4.  Every once in
>> awhile, especially after the 2.x to 3.x upgrade and later the 3.x to
>> 4.x upgrade, a few months after the upgrade I go thru and check file
>> times, moving files to a backup location if the mtimes haven't bumped
>> since the update, to see if they get recreated and/or whether they're I
>> lose any customizations.
>>
> Major releases, (1.x, 2.x, 3.x, 4.x), use different config directories.

While 2.x -> 3.x was too long ago for me to remember, as shipped by kde, 
3.x and 4.x used the same config and data dirs, both system (share/config/ 
and share/apps/, usually with installation variables set so it's /usr/
share/config/ and /usr/share/apps/)  and user ~/.kde/share/config/ and 
~/.kde/share/apps, with the $KDEHOME location if unset defaulting to 
~/.kde), except that kde4 added the freedesktop.org standard config and 
data dirs/vars for some things, but most existing apps still used the 
existing locations.

Some distros modified that so they could ship kde3 and kde4 side by side, 
with separate configs (often ~/.kde3/ and ~/.kde4/ as the default-if-
unset $KDEHOME location), but that was a distro modification, not kde as 
shipped.  The standard as-shipped-from-upstream location remained the 
same.

And actually, I deliberately did the same split user config here, early 
on, as I ended up having to switch to kde4 an app at a time.  (Start with 
a kde3 desktop, run the kde4 version of an app by path so I'm running it 
not the kde3 version, configure just that app, when I'm comfortable with 
the results, uninstall the kde3 version so the kde4 version is run by 
default.  I had to do it this way as the kde4 desktop was simply too slow 
and broken when run as a whole that it simply didn't work to try to do 
the initial config there.  Move the mouse, wait 10-20 seconds for the 
system to move the pointer, see if it was pointing where it needed to 
point to click, repeat move and wait until it was pointed where I wanted, 
finally click... slow!  The major desktop repaint bug that was triggering 
a good share of that was finally fixed in a 4.3.something bugfix update, 
which along with the many many other fixes and introduction of previously 
missing features that had worked fine in kde3, is why I say 4.2 was still 
alpha, many feature simply not implemented yet, 4.3 beta, most features 
implemented but many still broken for many use cases.)

But in deliberately splitting it, I copied the existing kde3 config over 
to the new kde4 location, so I was starting with the kde3 config, for 
apps that made the transition.  Of course many apps were new to kde4, 
including the plasma desktop itself, so they started with a clean config 
regardless, but for the apps that made the transition from kde3, most of 
the config carried over.

Then about three months later, I went back thru my kde user config and 
sorted on mtime, looking for config and data files that hadn't changed 
since the transition, experimentally renaming them to see if I lost vital 
config or not.  If not, I removed them (tho I still had backups for 
awhile, in case I made a mistake).
 
> I remember reporting a phonon bug a year ago related to the config and
> deprecated xine backend; but the devs ignored it possibly cause they
> were rushing through releases, and creating a new tags every 10 days.

More likely because it was announced to be deprecated (as you mentioned 
yourself) and no longer maintained.  The phonon-xine backend was I 
believe the initial implementation, thus for early kde4 adopters the most 
mature and stable one, but in the process of working with it, the devs 
learned quite a bit about what features they actually needed in a phonon 
backend, and how deficient xine was in that regard.  So at some point 
they switched to phonon-gstreamer as the default implementation, with 
phonon-vlc also available for those (like me) without gstreamer installed 
or who have problems with it, and deprecated phonon-xine, eventually 
dropping support for the xine backend entirely tho that took a couple 
releases.  But they didn't stop shipping it right away, as why break 
existing working setups?  But as it got more and more broken, eventually 
people had to, and did, switch, either at the distro or user level.

By a year ago phonon-xine was well deprecated and definitely on its way 
out, likely with distro-only support for those distros still shipping it; 
no upstream support or bugfixes as all.  So that'd be why the bug was 
ignored.

Of course the whole question of whether once shipped for kde4 they should 
have continued to support it thru the entire kde4 cycle is another 
question indeed.  But the reason you attributed for ignoring the bugfix 
was demonstrably false, as they simply weren't maintaining phonon-xine 
any longer, and it was up to individual distros whether they chose to 
continue shipping and supporting it, or not.  (FWIW, gentoo/kde was 
printing an ewarn on upgrades by then, suggesting people switch over, and 
may have actually stopped shipping it; gentoo doesn't ship it any more, 
but I don't remember precisely when they dropped it.)

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