Version: (using KDE 4.1.0) Installed from: Mandriva RPMs If you have GNOME installed, KDE's keyboard settings in System Settings - Keyboard & Mouse is missing: there is simply no section "Keyboard" in the left panel in that window. This is caused by by the presence of GNOME's /usr/share/applications/keyboard.desktop (KDE's one is in /usr/share/kde4/services/keyboard.desktop). When GNOME's keyboard.desktop file is moved or renamed, KDE picks up the right one and the Keyboard settings become visibile again. The problem seems to be that KDE's System Settings ignores the OnlyShowIn=GNOME; which is present in GNOME's keyboard.desktop. This is how GNOME's keyboard.desktop looks like: [Desktop Entry] Name=Keyboard <...snip translations...> Comment=Set your keyboard preferences <...snip translations...> Exec=gnome-keyboard-properties Icon=preferences-desktop-keyboard Terminal=false Type=Application StartupNotify=true Categories=GNOME;GTK;Settings;HardwareSettings;X-MandrivaLinux-System-Configuration-GNOME; OnlyShowIn=GNOME; X-GNOME-Bugzilla-Bugzilla=GNOME X-GNOME-Bugzilla-Product=gnome-control-center X-GNOME-Bugzilla-Component=keyboard X-GNOME-Bugzilla-Version=2.23.90 X-Desktop-File-Install-Version=0.15
to complete this report, this is a part of the output in console when the bug appears ... systemsettings(8725)/kutils (KCModuleInfo) KCModuleInfo::Private::Private: Could not find the service. systemsettings(8725) MainWindow::readMenu: " " Looking for children in ' "keyboard-and-mouse" ' systemsettings(8725) MainWindow::readMenu: " " found module ' "Clavier" ' "keyboard.desktop" >>>>>>>>>>>>>>>>>>>>> systemsettings(8725) MainWindow::readMenu: " " filename is "/usr/share/applications/keyboard.desktop" <<<<<<<<<<<<<<<<<<<<< findServiceByDesktopPath: not found systemsettings(8725)/kutils (KCModuleInfo) KCModuleInfo::Private::Private: Could not find the service. systemsettings(8725) MainWindow::readMenu: " " found module ' "Souris" ' "mouse.desktop" systemsettings(8725) MainWindow::readMenu: " " filename is "mouse.desktop" findServiceByDesktopPath: not found systemsettings(8725)/kutils (KCModuleInfo) KCModuleInfo::Private::Private: Could not find the service. systemsettings(8725) MainWindow::readMenu: " " found module ' "Raccourcis clavier" ' "keys.desktop" systemsettings(8725) MainWindow::readMenu: " " filename is "keys.desktop" ... the problem seems in readMenu from mainwindow.cpp, in this part of the code 118- // scan for any modules at this level and add them 119- for (int i = 0; i < modules.size(); ++i) { 120- KService::Ptr entry = modules.at(i); 121- QString category = entry->property("X-KDE-System-Settings-Parent-Category").toString(); 122- //kDebug() << "Examining module " << category; 123- if(!parent->name.isEmpty() && category == parent->name ) { 124- kDebug() << space << "found module '" << entry->name() << "' " << entry->entryPath(); 125- // Add the module info to the menu 126: KCModuleInfo module(entry->entryPath()); 127- kDebug() << space << "filename is " << module.fileName(); 128- //append(module); 129- MenuItem * infoItem = new MenuItem(false, parent); 130- infoItem->name = category; 131- infoItem->service = entry; 132- infoItem->item = module; 133- } 134- } at line 126 with entry->entryPath() for entryPath, api says QString entryPath ( self ) Returns: the path of this entry The path can be absolute or relative. The corresponding factory should know relative to what. It seems that it isn't very safe here, and a wrong path can be used. It seems me safer to use the ptr entry directly. That fixes this bug for me. I'm not a kde developper. Please could you review the patch in attachment, and apply it if it is OK, and there isn't side effects to use KCModuleInfo module(entry); instead of KCModuleInfo module(entry->entryPath());
Created attachment 27116 [details] patch for systemsetting reading /usr/share/applications/keyboard.desktop from gnome-keyboard-properties
still valid with kde 4.2 RC1 (4.1.96)
*** This bug has been confirmed by popular vote. ***
I see this behavior in my Gentoo system as well. 4.2.0 release
*** Bug 171453 has been marked as a duplicate of this bug. ***
I can confirm this bug in trunk (svn r943250). Actually, the problem doesn't seem to be only in systemsettings. Running 'kcmshell4 keyboard' from the terminal doesn't show anything either. As for the bug description's comment about renaming GNOME's keyboard.desktop: renaming KDE's keyboard.desktop works too. The problem seems to be in kbuildsycoca4/KService.
SVN commit 944091 by dfaure: The analysis and patch from 169710 are correct: better pass a KService::Ptr than an entryPath QString. Faster and more accurate in case of duplicate desktop files for the same entryPath. Doesn't fix kcmshell4 though. CCBUG: 169710 M +2 -2 mainwindow.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=944091
SVN commit 944097 by dfaure: Rename keyboard.desktop to kcm_keyboard.desktop to avoid conflict with gnome's keyboard.desktop (but they should also rename theirs, it's in our namespace after all, it starts with a k :-) Left keyboard.desktop around so that `kcmshell4 keyboard` still works, for compat. BUG: 169710 M +1 -1 CMakeLists.txt AM kcm_keyboard.desktop keyboard.desktop#943053 M +5 -3 keyboard.desktop WebSVN link: http://websvn.kde.org/?view=rev&revision=944097
SVN commit 957518 by mleupold: Backport of r944097. Rename keyboard.desktop to kcm_keyboard.desktop to avoid conflict with gnome's keyboard.desktop (but they should also rename theirs, it's in our namespace after all, it starts with a k :-) Left keyboard.desktop around so that `kcmshell4 keyboard` still works, for compat. CCBUG: 169710 CCMAIL: dfaure@kde.org CCMAIL: toma@kde.org M +1 -1 CMakeLists.txt AM kcm_keyboard.desktop keyboard.desktop#957514 M +5 -3 keyboard.desktop WebSVN link: http://websvn.kde.org/?view=rev&revision=957518
SVN commit 944091 should be backported on 4.2 branch too (we can have other duplicate desktop files). http://websvn.kde.org/?view=rev&revision=944091 944091 comment: " ... better pass a KService::Ptr than an entryPath QString. Faster and more accurate in case of duplicate desktop files for the same entryPath. ..." regards, Luc
*** Bug 189822 has been marked as a duplicate of this bug. ***