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.
