Bug 335396 - Assigning a window to an activity has no effect at all
Summary: Assigning a window to an activity has no effect at all
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: activities (show other bugs)
Version: git master
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-26 22:11 UTC by Elias Probst
Modified: 2014-06-01 16:58 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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