Registered Member
|
Using Plasma 4.11.12 on KDE 4.11.5 on openSUSE 13.1, I just dived into using Activities, and they're slightly more useful than using virtual desktops alone for my use case. But after about a week and a half of mucking about, the functionality is suddenly weirdly broken. Hitting Meta-Q, I see a list of my activities. Clicking on an active activity changes the activity, but the applications present stays the same -- the only evidence that the activity is changing is that the virtual desktop may change, but every application seems set to "present on all activities". Clicking on a sleeping activity either does nothing or crashes plasma. Rebooting didn't seem to fix the problem.
I thought that maybe my config/apps entries relating to plasma might be messed up, but then I noticed that there is no longer an "Activity" option on the menu that pops up when you right-click on the title bar. This doesn't seem like a change that would happen from a corrupted configuration. Has the place where you select which activities apply to a given window been moved elsewhere? Is it now hidden deeply inside "Special Window Settings", as happened to the opacity setting years ago? Or am I doing something fundamentally wrong here? |
Registered Member
|
Hm, as it seems to be present from a fresh user with an empty .kde4 directory, it's likely a configuration error after all. Can configurations really alter menus like that? I guess so.
I tried removing *activity* from .kde4/share/apps and .kde4/share/config, and it understandably started me off with no activities (or just one default activity) but the rest of my session unscathed. Creating new activities made the "Activity" menu come back. So now the question is: What file or files caused this problem in the first place? I'm going to restore the files in share/config and see if it was weirdness with files in share/apps. It'd be nice if I could restore at least some of my prior activity configuration without having to do it all from scratch. |
|
The activity entry is only shown if
a) activity support is compiled into KWin (seems the case, given it works on the other accoun) b) there are more than one (started, I think) activities (b) implies "kactivitymanager" is actually running. What's the output of
|
Registered Member
|
Apologies for the long delay in response. After removing the config files, it worked for a week and change, so I promptly forgot about the initial posting. After this latest reboot, the problem has returned. Here's a relevant screenshot which includes the output of the command you requested: In case the image gets broken, the output is:
...and there is no Activity menu. Curiously, the activities are still functioning otherwise. Hitting Meta-Q will allow me to switch which activity I'm in, and windows are generally in their proper activities, at least those restored properly by the session manager. But I cannot tell a window which activity to go into. |
|
timing issue?
what if you either a) restart kwin
b) alter the activities (add one)
|
Registered Member
|
`kwin --replace` seems to work, or at least it did when I tried it just now. I believe I tried adding activities manually before (which can still be done with the Meta-Q shortcut), but I don't recall it changing anything. If the problem occurs again (and I'll try to reproduce it with a reboot), I will try the other method that you suggested.
I'll check back again later or tomorrow hopefully in case there's anything you'd like me to try to help diagnose the issue for others. For me, the workaround is pretty darn helpful for now! Thank you. |
Registered Member
|
I've had this problem on and off for a year. Adding an activity with this command
does not add the Activity context menu item. I do see the dummy actvity in my list of activities from the Activities Panel button.
does work! I'm pretty sure a Debian system upgrade did this. It upgrade to 4:4.11.13-2. Previously it was 4:4.11.9-1. Brian |
|
It seems libkactivities fails to contact the kactivitymanagerd when the client process (kwin) was started "early" - to backup this assumption, you could try to shadow kwin w/ eg. /usr/local/bin/kwin, where the latter is a simple script:
This will delay starting kwin by 5 seconds (what should be enough) If this works, the reason will be sth. along "try to connect kactivitymanagerd. if failed, give up forever" |
Registered users: bartoloni, Bing [Bot], Evergrowing, Google [Bot], ourcraft