335396 2014-05-26 22:11:56 +0000 Assigning a window to an activity has no effect at all 2014-06-01 16:58:45 +0000 1 1 4 Plasma kwin activities git master Gentoo Packages Linux RESOLVED FIXED NOR normal --- 0 mail kwin-bugs-null ivan.cukic http://commits.kde.org/kwin/b995c9da231d65805621f9264975c74ec30fa88b 0 oldest_to_newest 1451311 0 mail 2014-05-26 22:11:56 +0000 Assigning a window to an activity via kwin's context menu has no effect at all. Clicking on once of the activities in the list sets the checkbox for this activity, but even "All Activities" isn't unchecked by this. Re-opening the context menu shows the activity list in the default state again ("All Activities" checked, all others unchecked). It's not only the menu which doesn't work, but it seems to be a general window <-> activity mapping issue, as the windows aren't hidden/shown based on the current activity. Unfortunately kwin doesn't log anything when assigning windows to activities, so I can't provide any debug output here. 1451340 1 mgraesslin 2014-05-27 05:27:36 +0000 I have to admit that I haven't tried with KWin/5 yet. Ivan are there any changes needed in the activities code? 1452328 2 mail 2014-05-31 15:43:56 +0000 Added some debug statements to the code and the most useful pointer I could find so far: client.cpp:1606 → QStringList allActivities = Activities::self()->all(); this returns only a single activity: 00000000-0000-0000-0000-000000000000 1452504 3 ivan.cukic 2014-06-01 16:58:45 +0000 Git commit b995c9da231d65805621f9264975c74ec30fa88b by Ivan Čukić. Committed on 01/06/2014 at 16:55. Pushed by ivan into branch 'master'. KWin activities usage ported to the new library paradigm Since the KActivities library now keeps an internal cache (and is non-blocking), there is no point in thread-based information fetching. REVIEW: 118443 M +2 -78 activities.cpp M +9 -12 activities.h M +2 -3 useractions.cpp M +0 -3 workspace.cpp http://commits.kde.org/kwin/b995c9da231d65805621f9264975c74ec30fa88b