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.
