When you run plasma-desktop the first time (without configuration files) and show the activity manager, in addition to the standard activities there is an activity that does not display a name. It cannot be started or removed. Reproducible: Always Steps to Reproduce: 1. Create a new user and log in (or run a live CD) 2. Open activity manager (click on the 3 dots in the plasma panel) 3. Actual Results: An empty activity is present that cannot be started or deleted. Expected Results: Empty activity is not there, only the default activities. This seems to be related to the showActivityManager plasmoid. If I remove this from the default panel, this broken activity doesn't get created.
Created attachment 77320 [details] offending entry in plasma-desktop-appletsrc Attached is an excerpt from plasma-desktop-appletsrc showing the offending entry. Notice there is nothing set for activity or activityId. If this section is manually removed from the config file (and plasma is restarted), the activity is gone.
Created attachment 77321 [details] screenshot showing the problem Attached is a screenshot showing the problem on openSUSE 12.2 with KDE 4.10. Note that this bug is also present on a Kubuntu 13.04 Alpha 2 Live CD.
Well, I've tried to debug this issue and found out where this strange activity comes from: In kde-workspace/plasma/desktop/shell/desktopcorona.cpp the method checkActivities() calls m_activityController->setCurrentActivity() with a valid id at the end (line 673), but m_activityController->currentActivity() still returns "" afterwards... How can this possibly happen??? AFAIUI m_activityController just issues DBUS calls to the activity manager. But calling SetCurrentActivity/CurrentActivity using qdbusviewer works without problems... Maybe there is a timing issue when plasma-desktop starts up? How could I further debug this? Any help is welcome!
Created attachment 77582 [details] patch that makes this problem disappear I've managed to "fix" this bug with the attached patch, which removes the caching of currentActivity in KActivities::Consumer. So it seems there is some issue there... Therefore I have changed the product accordingly.
I know now what the problem is exactly: Controller::setCurrentActivity() calls Manager::activities()->SetCurrentActivity(id), which emits the currentActivityChanged signal. But Controller's inherited Consumer class never gets this signal (maybe because it's in the same class?), so Consumer::setActivityChanged() doesn't get called and the cached currentActivity stays on its old value. A way to fix this would be to declare ConsumerPrivate * const d; as protected instead of private in consumer.h and change Controller::setCurrentActivity() to: bool Controller::setCurrentActivity(const QString & id) { if(Manager::activities()->SetCurrentActivity(id)) { if(currentActivity() != id) Consumer::d->setCurrentActivity(id); return true; } else return false; } in controller.cpp This fixes the issue for me. And I think the same should be done with the other methods in Controller.
This bug is still reproducible with KDE 4.10.4
Somehow missed this one. Is it still an issue with 4.13?
(In reply to comment #7) > Somehow missed this one. Is it still an issue with 4.13? Yes. I updated the version accordingly.
This should not happen in latest Plasma. Plasma 5.x should no longer create activities willy-nilly like the 4.x version did.