It's easy to break your system by having an empty hierarchy of directories where Plasma looks for shell handlers. E. g. have an empty hierarchy under /usr/local (which takes precedence) and actual plugins under /usr I'd say many of the "Plasma starts with a black screen but Alt+F2 works", "Plasma crashes and leaves me with a black screen but Alt+F2 works", etc are caused by this bug. See steps to reproduce. Reproducible: Always Steps to Reproduce: 1. Install a fresh system, e. g. Kubuntu 15.04. KDE and Plasma Desktop will be installed in the default system prefix (/usr) 2. Git clone the Plasma Media Center and build it with the default CMake prefix (/usr/local) 3. Run "sudo make install" 4. Run "sudo make uninstall". This will remove the files that were installed in step 3, but leave an empty hierarchy: /usr/local/lib/x86_64-linux-gnu /usr/local/lib/x86_64-linux-gnu/qml /usr/local/lib/x86_64-linux-gnu/qml/org /usr/local/lib/x86_64-linux-gnu/qml/org/kde /usr/local/lib/x86_64-linux-gnu/qml/org/kde/plasma /usr/local/lib/x86_64-linux-gnu/plugins /usr/local/lib/x86_64-linux-gnu/plugins/plasma /usr/local/share/kservices5 /usr/local/share/kservicetypes5 /usr/local/share/plasma/ /usr/local/share/plasma/shells As /usr/local is usually before /usr in PATH, /usr/bin/plasmashell will find the directories described in step 4 and report "no shell handlers were found". Why, of course! You did not search under /usr but /usr/local, which contains nothing at all! The place to fix this is probably plasma-workspace/shell/shellmanager.cpp. But first of all, a conceptual problem should be solved: a) Should Plasma keep working with one SINGLE prefix (e. g. /usr/local, OR /opt, OR /usr) ? b) Or should Plasma work with SEVERAL prefixes and combine what's found there? In that case, instead of a single QString s_shellsDir, there should be a QStringList s_shellsDirs. That would allow to e. g. have Plasma Desktop under /usr and Plasma Media Center under /usr/local If a single prefix is the preferred route, then: 1. Check if the directories are empty. If they are empty, do not even consider them and skip to the next prefix, in hopes something will be found there. 2. Search for plugins under the same prefix where plasmashell is. If we are running /usr/bin/plasmashell (prefix /usr), does it make sense to try to load the shell handlers from the /usr/local prefix? It would also be very useful if the KMessageBox error (line 187) would inform the user of the prefix WHERE no shells were found. Had I knew the problem was no shell handlers were found under /usr/local, I would have solved the problem instantly instead of wasting a day :-(
I did not explicitly say it but the moment I deleted the directories listed in step 4, plasmashell no longer looked for shell handlers under /usr/local and found Plasma Desktop under /usr. Problem solved.
It's not a critical bug if it only affects people with a slightly weird setup. As for the bug, we're currently only loading and storing the one directory. Given potentially I could install plasma-workspace from packages and compile plasma-media-center into /whatever, we should check all dirs static const QString s_shellsDir(QStandardPaths::locate(QStandardPaths::QStandardPaths::GenericDataLocation, PLASMA_RELATIVE_DATA_INSTALL_DIR "/shells/", QStandardPaths::LocateDirectory)); I'll change this to a locateAll and a list.
https://git.reviewboard.kde.org/r/123870/
Git commit f59164914c46eca3686a3ade63f46bf6489f9193 by David Edmundson. Committed on 21/05/2015 at 15:42. Pushed by davidedmundson into branch 'master'. check all shell directories REVIEW: 123870 M +20 -18 shell/shellmanager.cpp http://commits.kde.org/plasma-workspace/f59164914c46eca3686a3ade63f46bf6489f9193