|Summary:||Assigning a window to an activity has no effect at all|
|Product:||[Plasma] kwin||Reporter:||Elias Probst <mail>|
|Component:||activities||Assignee:||KWin default assignee <kwin-bugs-null>|
|Latest Commit:||http://commits.kde.org/kwin/b995c9da231d65805621f9264975c74ec30fa88b||Version Fixed In:|
Description Elias Probst 2014-05-26 22:11:56 UTC
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.
Comment 1 Martin Flöser 2014-05-27 05:27:36 UTC
I have to admit that I haven't tried with KWin/5 yet. Ivan are there any changes needed in the activities code?
Comment 2 Elias Probst 2014-05-31 15:43:56 UTC
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
Comment 3 Ivan Čukić 2014-06-01 16:58:45 UTC
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