Bug 306680

A snippet from the debug output when clicking on an activity it doesn't open:

kactivitymanagerd(15938) Jobs::General::Call::start: >>> Calling the method "emitCurrentActivityChanged" with "1f0db545-22a7-40a6-b3aa-66c9d18b08c0"
VirtualDesktopSwitch::currentActivityChanged 
kactivitymanagerd(15938) RankingsUpdateThread::run: This is the activity we want the results for: "1f0db545-22a7-40a6-b3aa-66c9d18b08c0"
kactivitymanagerd(15938) RankingsUpdateThread::run: "SELECT targettedResource, cachedScore FROM kext_ResourceScoreCache WHERE usedActivity = '1f0db545-22a7-40a6-b3aa-66c9d18b08c0' AND cachedScore > 0 ORDER BY cachedScore DESC LIMIT 30"
QFileSystemWatcher: failed to add paths: /home/einar/.kde4/share/config/activitymanager-pluginsrc
kactivitymanagerd(15938) Jobs::Schedulers::Abstract::Private::jobFinished: Job has finished with this result 0
kactivitymanagerd(15938) Jobs::Schedulers::Ordered::jobFinished: no error, no jobs

I did some more digging. The issue manifests itself when kwin is restarted. Also, if I create a new activity, KWin's activity context menu shows double the entries as normal. They are "back to normal" if KWin is restarted, but in that moment the problem manifests itself.

Further investigation shows that KActivities, before the KWin restart, reports duplicated activities. This happens with 3 running activities:

kwin(27514) KActivities::Consumer::listActivities: Returning the running activities ("301a9cf9-82e2-4ccb-b24b-c9facc6a4ef1", "42c47e52-2898-41af-8cc2-014347aabafc", "42c47e52-2898-41af-8cc2-014347aabafc", "f3d7acbe-f1d1-4b4f-968f-03cb4bc93d14", "f3d7acbe-f1d1-4b4f-968f-03cb4bc93d14")

I have to amend the d behavior: it's not that you can't switch to activities, rather than the stopped activity is started and then immediately stopped.

I did quite a lot of debugging and bisecting and I found the problematic commit:
f150230436ba950b18bb163bed80c508501e7936 in kactivities.

This is the commit that introduced caching for listing activities: if it is reverted, everything works as it should.

Investigation showed that if this commit is not reverted, allActivities_ in KWin's startActivity method (allActivities_ got from KActivities:Consumer:listActivities)  will only contain activities added during the session. If KWin is restarted, the list will be empty:

kwin(13498) KActivities::Consumer::listActivities: Returning listActivities ()

the check in startActivity (KWin side) will return false and nothing will be done.

It appears I messed up with git-bisect.... The real first bad commit is 74f0cbffc9c2be2f2108691876b6b312d6fe7561 in kactivities.

The more time passes the more I'm puzzled. Even with the offending commit removed, there's something else contributing to the issue because I need to rebuild kactivitymanagerd every time I update KDE from git, or the issue appears again.

Created attachment 74193 [details]
Plasma crash backtrace

I can reproduce the reported issue with the following:
Create new activity
Switch back to 'main' one
Restart kwin
Stop newly created activity
Try to start it --> can't be done, also, plasma crashes in the process

Fixed for a while, closing.

FTR:
with kdelibs 4.10, kactivities master and kwin master i do still observe issues

1. activities but the default one are stopped and cannot be started (using dbus directly!) - no matter what (i tried to investigate on preserving window attachment across sessions)

2. we still get an undeduplicated list for at least the openactivities (at least for activities added after the re-login / kwin restart), see bug #310850

Assigning windows to running activities works, but if you got 
Default
dummy
dummy

and "dummy #2" is actually "dummy #1", assigning a window to Default and dummy (#1) will oc. also asign it to dummy (#2) thus "ALL" activities.

From what i can say this bug essentially is very apparent and i could at bes workaround issue (2) but not (1) and that might actually be the more severe one (right now, i've got kwrite/sm.cpp on dummy & dummy2 (yeah, actual dummy2, not dummy #2 ;-) and no way to access it (unless i would of course know how to manipulate xproperties directly ;-)

Good part is that the session crossing attachment actually sees to work (bug body =)

gah, blast!

PS: the current activity "Default" is not member of the openActivities return list.

@Thomas You need to send me the config files for activities. I can not reproduce this issue.

Created attachment 75868 [details]
activity settings

It seems to affect activities with clients on (exclusively) them, but not being the active one - just a gut feeling atm, though.

Activities:

238d4803-a10b-4279-9be2-c516b8d0c7b0 ("dummy2") : Stopped
-------------------------------------------
abcd24bc-aa4d-4c7e-bb11-ae8c3ffb2dce ("Default") : Running
-------------------------------------------
da2b49ef-5344-4d76-a3da-44c2bc0160c4 ("dummy") : Stopped
-------------------------------------------

This does not change, no matter how often i try to start/stop/start an activity

The list of openactivities is count 1 for kwin unless i either
a) add an activity (running, shows up twice, but not present ones, iirc. not even if running)
b) restart kwin (clears the stage)

Created attachment 75869 [details]
convenience script to manage activities

managing scripts for more comfort - utilizing dbus and hashes directly does not change anything (the script does work ;-)

random guess: setActivityState is called during a pending dbus call or somehow else before addActivity adds it (and only checks for listActivities presence, while the state setter only checks the runningActivities presence?)

"yes"

void ConsumerPrivate::setActivityState(const QString & activity, int state)
{
    if (!listActivities.contains(activity)) {
        qWarning("trying to alter state of unknown activity!!");
        return; // denied
    }
...

fixes it (and i get the warning)

Next question (sorry) - what is the "nulluuid" supposed to be good for (it's currently not handled in kwin and i twice or thrice ran into it being the only activity windows being assigned to (ie. they were always hidden)

Either we treat it as "junk" in kwin (remove it from the list to add windows to) or as "ask me again later" hint?!

*** Bug 310850 has been marked as a duplicate of this bug. ***

Catching the dupes does not fix unstartable activations.
Can you reproduce that one?

nulluuid is for when the activity manager service is not running. So that clients don't need to handle special cases when they get an empty list of activities.

I can reproduce duplicates, will be fixed soon.

I can not reproduce the unable-to-start activiites. Will need more testing :/

Reopening as *cough* reminder, because yesterday evening i could not spot any fix.

Do 3. Jan 00:59:00 CET 2013      :  KDE SC 4.10 Tagging Freeze for Release Candidate 2

Git commit 9edd34f978627a94b6f5f0c6a88f6c00eec21cc5 by Ivan Čukić.
Committed on 02/01/2013 at 12:10.
Pushed by ivan into branch 'KDE/4.10'.

Ignores state changes for unknown activities

Patch by Thomas Luebking

M  +5    -0    src/lib/core/consumer.cpp

http://commits.kde.org/kactivities/9edd34f978627a94b6f5f0c6a88f6c00eec21cc5

Thanks for the reminder - forgot to push the change ARGH