Version: 4.5 (using KDE 4.5.4) OS: Linux I launched kde4 and my kde3 kicker and the kde4 plasma panel are both present: [26k] http://www.3111skyline.com/dl/arch/bugs/kde4/k3+k4_panels-640.jpeg So I moved ~/.kde4 figuring it was the problem and launched kde4 again. Still it pulled in my kde3 kicker and background. Huh? So I moved both ~/.kde and ~/.kde4 to make sure there was nothing kde (3 or 4) related in my home directory and I launched kde4 again. To my surprise, kde4 loaded it's plasma panel and then proceeded to load the default kdemod3 kicker and kdemod3 background?? See: [24k] http://www.3111skyline.com/dl/arch/bugs/kde4/k3+k4_panels-new-640.jpg Obviously something is very wrong here. kde4 should not be loading the kdemod3 kicker or background. Looking at the newly created ~/.kde4/share/config files, the kickerrc file contains the following: 15:42 providence:~> cat .kde4/share/config/kickerrc [$Version] update_info=kickerrc.upd:kde_3_1_sizeChanges,kickerrc.upd:kde_3_4_reverseLayout,kickerrc.upd:kde_3_5_kconfigXTize Double-huh? Why would kde-4.5.4 create a kickerrc containing kde3 entries? Reproducible: Always Steps to Reproduce: Have both kde3 and kde4 installed. (using kde4 kdm as display manager) Clean home directory of both ~/.kde and ~/.kde4 Launch kde4 to force defaults to be applied Actual Results: kde3 kicker and kde4 plasma panel are both loaded. Default kde3 wallpaper is used for the kde4 background. Context menus and decorations appear to be kde3 default. Plasma panel is properly styled with kde4 theme. Expected Results: Just a default kde4 panel and theme.
Are you using the "startkde" script from KDE3 or from KDE4?
I am using the kde4 startkde (/usr/bin/startkde) script. The only custom config I have is a simple link of: /usr/share/apps/kdm/sessions/kdemod3.desktop -> /etc/X11/sessions/kdemod3.desktop that is just there so I get the option of launching kde3 from the kde4/kdm chooser. The contents of the desktop file is simply: [Desktop Entry] Encoding=UTF-8 Type=XSession Exec=/opt/kde/bin/startkde TryExec=/opt/kde/bin/startkde Name=KDEmod3 I know that isn't an issue. The problem looks like a config or packaging issue with i686 packages. I upgraded 6 arch boxes to 4.5.5-1 last night and I still get this problem on 1 i686 box and another i686 box freezes during ksplash (both Dell boxes). All x86_64 boxes load kde4 fine with no extra kicker or kde3 background/window decoration/etc... I simply do not know where to look for a hook or config in the packaging to try and figure out where kde4 is pulling in the kde3 settings, kicker, etc.. Any ideas? I'm happy to check if I know where to look.
There seems to be some difference in the Arch kde4 packaging between i686 and x86_64. (I know it doesn't make sense...) I have a dozen Arch boxes and I have no problems with the x86_64 kde4 where kdemod3 is still installed. But for some reason on the i686 Dell boxes, I either get kde4 pulling in its plasma panel & the kde3 kicker or I get lockups of kde4 at the end of ksplash (box hardlocks) On my suse boxes with both kde3 and kde4 installed, both i686 and x86_64, kde4 loads without any of this strangeness. That's the only reason it points me to the possibility of an Arch i686 k4 packaging issue. The biggest difference is the Arch install creates the ~/.kde4/share/config/kickerrc which loads the kde3 kicker panel in kde4. That should not happen. The SuSE install of kde4 creates no ~/.kde4/share/config/kickerrc at all (which is correct because kde4 has a 'plasma panel' and no 'kicker' at all) So why the Arch k4 i686 packaging causes a k4 kickerrc to be created at all is a mystery to me and probably worth looking into as it should not be occurring at all. The Arch x86_64 kde4 packaging does not do this either. On my Arch x86_64 boxes, no kickerrc is created: 13:41 nirvana:~> l ~/.kde4/share/config/kicker* ls: cannot access /home/david/.kde4/share/config/kicker*: No such file or directory So something is not correct with the i686 k4 packaging that causes a kde4 kickerrc to be created when kde4 is launched. What would create this kickerrc under ~/.kde4/share/config? I suspect there is an entire section of the kde4 setup in Arch that is a forgotten holdover from kde3 and needs to be removed. Unfortunately, I have no clue how kde4 is packaged and don't know where to start looking.
Could this be related to some setting in ~/.config? I ask, because basket notepads (fantastic info collection app) is loaded in both k3 and k4 from ~/.config/autostart. Could loading basket notepads be what forces the load of some kde3 runtime which in turn pulls in the kicker panel, background and decorations? Since I have deleted both ~/.kde and ~/.kde4 and still get the kde3 kicker, background and decor in kde4, there has got to be a common-thread somewhere, but where? Let me also correct earlier statements limiting this problem to i686 packages. I have this problem on both i686 and x86_64 boxes. I 'think' it may also be compiz related. Specifically, if you have ever used 'kwin --replace' to drop from compiz back to kwin, I think a default setting gets set for the default wm. When you then launch k4, k4 loads, but then pulls in the k3 settings based on the default set by using 'kwin --replace'. Plausible? If so, what to check? However, I think the issue being in ~/.config may be right on point. I have completely removed ~/.kde and ~/.kde4 and still get the kde3 elements pulled into kde4. I have pulled my hair out trying to find the common-thread, but until now I have completely overlooked ~/.config. I would appreciate any thoughts the kde-devs may have. Like I said, I'm more than happy to test and hunt for why this is happening. But it would really help to get some pointers on where to look. Thanks.
I now think I know what the problem is. The current kde4 build will create a: /var/tmp/kdecache-<user>/ksyscoca and /var/tmp/kdecache-<user>/ksyscoca4 if kde3 is left installed on the system. This is a bug. kde4 shouldn't generate a 'k'de 'sys'tem 'co'nfiguration 'ca'che for kde3 -- period. I know SuSE handles this in some manner so there is no conflict between kde3 and kde4. Why this is a problem in Arch Linux is a mystery to me. Can you guys check the code and find out where it is even possible for kde4 to generate and ksyscoca if kde3 is installed. Further, the big issue is why kde4 then uses the ksyscoca along with ksyscoca4 when loading. Thanks.
Best I can tell, sometime in the kde 4.5.3 time frame is when this problem first appeared. I searched in vain trying to find out why in the heck kde4 loaded the kde3 kicker along with it's plasma panel and then proceeded to load the kde3 background and decorations (and dialogs in some cases) Repeated tests removing both ~/.kde and ~/.kde4 made no difference. Removing items from ~/.config/autostart made no difference. Removing /var/tmp/kdecache-user showed very unexpected behavior. If kde3 was installed, starting kde4 (with a new user account) would create both: /var/tmp/kdecache-<user>/ksyscoca /var/tmp/kdecache-<user>/ksyscoca4 and then for some reason kde4 appears to be loading settings for both. Removing kde3 & deleting /var/tmp/kdecache-<user> and then restarting kde4 was the only way to get kde4 to load on Arch without pulling in the kde3 settings. Remarkably, after removing kde3 and deleting /var/tmp/kdecache-<user> and then restarting kde4 --> no ksycoca is created. Without kde3 installed, kde4 only creates ksyscoca4, as expected. The primary issue remains the same, why is kde4 creating and using /var/tmp/kdecache-<user>/ksyscoca if kde3 is left installed? I don't know kde3 or kde4 well enough to know where or why this behavior occurred, but I have confirmed this behavior on 8 boxes, both i686 and x86_64.
*** Bug 286142 has been marked as a duplicate of this bug. ***
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
No response; assuming it was fixed since then.