I had exactly the same issues and questions with "Activities" as you. I found the video Wicky posted to be instrumental in filling in gaps in my understanding of how Activities are suppose to improve upon traditional virtual desktops. The most important thing I took away from watching the video was that activities are just another type of virtual desktop that allow for more fine tuned control over your experience. Interesting examples of one or more features that could potentially be enabled in any activity are as follows:
- Changing your power settings - say a presentation mode actvity - such that your screen never times out
- Changing your default language / default keyboard to a different locale
- Changing your default permissions; all apps launced run as root root - or - contrarily all apps have read-only access (sort of a super "incognito" mode I can't wait for this)!!
- Changing your default printers
- Changing you default email and calendar (from personal to work etc)
- Restoring the most commonly used apps for that activity. Moreover, apps are not launched, and thus memory not allocated until you actually use that virtual desktop, and could all be stopped when you decided to press the stop button for that activity. Yes, currently the document you had open last isn't necessary launched, but that is a likely future feature.
- Changing the default folders / widgets displayed on the desktop
- Changing the way that scrolling and different button mouse clicks work
Aside from power-settings, mouse clicks, and basic application restoration, I'm not sure any of these other features have yet been implemented. Indeed, my desire to figure this out came from someone else’s ask Ubuntu question where they were trying to write the app for language switching upon virtual desktop changes.
Overall I think the thing most holding back progress is a nice GUI tool to configure activities to execute commands or apps, and seems a likely next step.
Move all windows into the visible area
As proposed/requested in a comment, the script below will move all "normal" windows to the visible area on the current workspace.
The solution is a workaround; the screen info is updated correctly, given the difference in the output of xrandr
, before and and after disconnecting. The reason why the windows do not move by themselves is (currently) unknown, unless another answer solves the issue.
The script
#!/usr/bin/env python3
import subprocess
# get the resolution of the screen (+0+0)
res = [
int(n) for n in [
s.split("+")[0].split("x")\
for s in subprocess.check_output(["xrandr"]).decode("utf-8").split()\
if "+0+0" in s][0]
]
# create list of windows
w_list = [w.split() for w in subprocess.check_output(["wmctrl", "-lG"]).decode("utf-8").splitlines()]
# filter only "normal" ones
valid = [
w for w in w_list if "_NET_WM_WINDOW_TYPE_NORMAL" in\
subprocess.check_output(["xprop", "-id", w[0]]).decode("utf-8")
]
# get the number of valid windows and calculate a targeted position
# the targeted position is a hunch, it will be exact if the window fits completely inside the resolution
# it will work anyway
parts = len(valid)+2
positions = [(int(n*res[0]/parts), int(n*res[1]/parts)) for n in list(range(parts))[1:-1]]
# unmaximaize, move the windows to the visible area (current workspace)
for i, w in enumerate(valid):
subprocess.Popen(["wmctrl", "-ir", w[0], "-b", "remove,maximized_vert,remove,maximized_horz"])
# weird, but sometimes wmctrl refuses to move a window if it is not resized first (?)
subprocess.Popen(["wmctrl", "-ir", w[0], "-e", "0,200,200,200,200"])
subprocess.Popen(["wmctrl", "-ir", w[0], "-e", (",").join(["0", str(positions[i][0]), str(positions[i][1]),w[4],w[5]])])
How to use
The script needs wmctrl
:
sudo apt-get install wmctrl
Copy the script into an empty file, safe it as move_windows.py
Test- run it: open a number of windows, place them on different workspaces etc., or try disconnecting the second monitor. Then run the command:
python3 /path/to/move_windows.py
All "normal" windows should move to the visible area of the current workspace.
If all works fine, add it to a shortcut key: choose: System Settings > "Keyboard" > "Shortcuts" > "Custom Shortcuts". Click the "+" and add the command:
python3 /path/to/move_windows.py
Now you should be able to move all windows into the visible area on the current workspace, with your shortcut key.
Best Answer
I'm actually running KDE 4.9.4 atop ArchLinux, but it shouldn't matter. Since KDE treats the screen as one (mostly), switching Virtual Desktops will switch them on all screens. However, there's a handy "On all Desktops" button in every window titlebar (near the app logo, you enable/disable that in SystemSettings->WindowDecorations->ConfigureButtons). Click that, and your application will remain there even if you switch the desktops. It's a workaround, but it works.