Bug 271686

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.

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.

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)

@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! :)

> 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)

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)

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...

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?

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.

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?

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.

+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")

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.

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.

*** Bug 411688 has been marked as a duplicate of this bug. ***

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