Bug 271686 - Keyboard shortcut to move windows to activities
Summary: Keyboard shortcut to move windows to activities
Status: CONFIRMED
Alias: None
Product: kwin
Classification: Plasma
Component: activities (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 411688 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-04-25 13:44 UTC by Christian (Fuchs)
Modified: 2023-09-03 04:31 UTC (History)
12 users (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 Christian (Fuchs) 2011-04-25 13:44:17 UTC
Version:           unspecified (using KDE 4.6.2) 
OS:                Linux

Similar to the shortcuts to move windows to virtual desktops  (move to specific desktop, move to next / previous, move to all (sticky)) it would be good to have a keyboard shortcut to move windows to specific activities. Currently the only way to move them is via the window title context menu, which is not really good for keyboard based working. 

Reproducible: Always

Steps to Reproduce:
Look for a keyboard shortcut to move windows to activities

Actual Results:  
There is none

Expected Results:  
There is one for next, one for previous, one for "all" and, if technically possible, one for specific activities.
Comment 1 sparhawk 2013-04-30 06:50:10 UTC
There are already definable shortcuts to *switch* to a specific activity, so IMO, analogous to virtual desktops, there also should be shortcuts to *send* to a specific activity.
Comment 2 Stabledog 2014-01-29 16:34:53 UTC
Agree that this feature would make a significant difference in the usability of activities.   As it stands, there are so many clicks required to move a window to a different activity that it discourages me from using activities extensively in my daily work.
Comment 3 Thomas Lübking 2014-01-29 17:51:25 UTC
Dev note:
This needs coordination, ie. the plasma shortcut and the kwin shortcut need to have the same idea about "next" and "prev" activity, ie. this information must be cetrally provided by the kactivity lib/daemon.

Moving to a specific activity is *very* problematic, since activities are not counted by identified by a Uuid, ie. eg.  "abcd24bc-aa4d-4c7e-bb11-ae8c3ffb2dce"
This can cause unresolvable front name clashes ("Main Activity" or the other "Main Activity") and by the way global shortcuts work, we'll "leak" shortcuts when activities get new Uuid (recreated)
Comment 4 Stabledog 2014-01-29 18:52:50 UTC
@Thomas: thanks for responding... not sure I understand enough about either KDE or its internals to appreciate the problem -- but even if we couldn't have shortcuts, a related problem is that there seems to be just no way at all to do this with the keyboard, shortcuts or not:   I can Alt+F3 to get the window menu, choose 't' for activities, and now I'm stuck.   Even an "Alt-{1...9}" to choose from the displayed activities would be a big improvement over having to reach for the mouse (vim user here, sorry!)    

It's like the keyboard road got paved all the way to the last mile, then one has to hire a donkey! :)
Comment 5 Martin Flöser 2014-01-29 19:04:01 UTC
> a related problem is that there seems to be just no way at
> all to do this with the keyboard, shortcuts or not:   I can Alt+F3 to get
> the window menu, choose 't' for activities, and now I'm stuck.   Even an
> "Alt-{1...9}" to choose from the displayed activities would be a big
> improvement over having to reach for the mouse (vim user here, sorry!)
You can navigate the menu using the cursor keys. Activate through I think 
space (didn't test)
Comment 6 Thomas Lübking 2014-01-29 19:59:19 UTC
The automnemonic system of QMenu does not work because it's a fake QMenu in order to allow you to un/select multiple activities w/o closing the menu (the fixed bug was that changing activity assignment in general was too clumsy)

Suggested keyboard navigation should still work, though (and for 3-5 activities not be too much overhead either)
Comment 7 Stabledog 2014-01-29 20:53:12 UTC
Thanks... I've tried using space+tab and arrow keys, and I can indeed get the checkboxes for alternate activities to light up.   However, it has no functional effect -- switching to that activity, I still won't find the window of interest, and when I go back to the menu, the checkbox is unchecked again.   It seems that you can check the box with the keyboard, but the stage change is only committed in response to mouse clicks (or perhaps some key I haven't discovered yet -- it isn't "Enter")

I'm starting to lean toward waiting for this relatively new facility to mature before leaning on it so hard...
Comment 8 Thomas Lübking 2014-01-29 22:06:08 UTC
Nope, the code reacts on QAction::triggered - how it's caused is irrelevant.

Enter would implicitly close the menu, space would only toggle the activity.

If QAction::triggered was broken on your side, hardly anything could be used by keyboard.

What GUI style do you use?
Comment 9 Vadim Belmesov 2021-04-15 10:54:21 UTC
I will add a little from myself about this, I hope I correctly understood the subject of discussion.

Now it is possible to move the window to a specific room via the window menu (ALT+F3). But when setting up button combinations, there is no way to assign a combination for this action.

It seems to me that this should not be too difficult, probably this functionality just did not fall into the possible actions for which button combinations can be assigned.
Comment 10 phrxmd 2021-04-19 14:08:24 UTC
Yesterday and today I spent a lot of time looking for such a keyboard shortcut. Now on the one hand I'm relieved that it wasn't my fault for not finding one, and disappointed that there is none for such a basic operation, since 2014 :(

Is there a workaround, maybe with a DBus command that could be scripted?
Comment 11 Joe 2022-01-17 03:07:06 UTC
I would also use this feature and I would really like a command line tool such as kstart to be able to specify which activity to open a new window in.

Use cases:
- Setting up a multi-activity working environment at login

- I have a script (daemon) that closes an application when certain conditions occur and restarts it when the conditions end. If I am in another activity when the application is restarted, it is opened in the this activity instead of the one where it belongs.

Possible workaround:

Since no one seems likely to fix this, it should be possible to configure a hotkey to do it by using AutoKey to run a script that performs the required keyboard and mouse events to move a window to a desired activity. If the script also calls xdotool, it might even be able to search for the window that needs to be "moved". The downside of this approach (besides requiring an additional application) is that as such a script "fixes things up", each action it takes (with possible delays to let things settle) is visible to the user and can look pretty strange.
Comment 12 g111 2022-04-26 17:38:33 UTC
+1

I am looking for a hotkey to move the current window to the next/previous activity, too. Would be cool if this could be implemented. (The same behaviour as for desktops: e.g. "Window One Desktop Up")
Comment 13 ailaG 2022-12-12 14:27:20 UTC
Adding a usecase.

At the moment I have 12 activities, 5 of which I use semi daily. Both for separation of windows (e.g. "project a", "project b", "fun" only show their own respective stuff) and to manage my browser tabs' memory consumption per activity.

If my browser crashes, when I fire it back up all my tabs load in one window and I need to sort them again.

I'm not sure if that's a common case, but with the nature of KDE Activities - it should be.

Having an easy way to change Activities would both help us, KDE users, and welcome new users to Linux in a smooth way. That means a keyboard shortcut, drag & drop or both.

ATM I do alt+f3, activities, activity, alt+f3, activities, deselect current. But hotkey -> select activity would make for a better UX.
Comment 14 Joe 2022-12-12 15:38:30 UTC
While adding functionality here would be the best idea - in whatever way works, as a workaround, you can build scripts in AutoKey which perform sequences of keyboard and mouse actions to configure your activities the same way you would manually. There is even the ability to do image searches on the screen, e.g. to find and select buttons or other widgets.

If the required actions are complicated, they can get a bit fragile when the underlying applications change and can make the screen content change as it would when done manually, but it works and should be able to do almost anything you could do manually. AutoKey doesn't work on Wayland yet, but that's being explored.
Comment 15 joelsonejr 2023-08-21 19:17:59 UTC
*** Bug 411688 has been marked as a duplicate of this bug. ***
Comment 16 joelsonejr 2023-08-21 19:19:38 UTC
I was able to confirm the reported behavior. 
The following machine was used for testing:

OS: Manjaro Linux x86_64
Kernel: 6.1.41-1-MANJARO
Shell: zsh 5.9
Resolution: 2560x1440, 1920x1080
DE: Plasma 5.27.6
WM: KWin
WM Theme: Oxygen
Theme: [Plasma], Adwaita-dark [GTK2/3]
Icons: ePapirus-Dark [Plasma], ePapirus-Dark [GTK2/3] 
Terminal: yakuake
CPU: Intel i7 4790H
GPU: AMD ATI Radeon 6600
Memory: 32043MiB