Currently, it is possible to set up shortcuts to navigate activities (direct and reverse orders). In my setup, I chose meta+tab and meta+shift+tab, to mimic the famous alt+tab and alt+shift+tab window navigating shortcuts. Alas, the analogy stops here, as the activity order is static, whereas alt+tab will always switch to previously active window (and alt+tab+tab will switch to the window that was active before that). In other words, for alt+tab, windows are sorted in last apparition order, and this order is updated every time the focus changes. A similar behaviour for activities would play very nicely for my workflow (where I typically switch between 2 or at most 3 active tasks, and I don't want less relevant activities to pop up unless I specifically look for them). Would it be possible to implement the "most recent order switching" behaviour for activities?
Meta+Tab and Meta+Shift+Tab are a part of the default activities shortcuts ("Walk through activities" and "Walk through activities (Reverse)") and they switch activities in most-recently-used order by default. If you keep the Meta key pressed, you'll get the activity switcher on the left side of the screen similar to the default task switcher you get when you switch tasks with Alt+Tab. Now, I'm curious what exactly you set up. Which shortcuts exactly did you change?
I have the same problem, the order of activities remains fixed so switching between two activities at opposite ends of the list is somewhat arduous
@Adam By default, Meta+Shift+Tab switches to the least recently used activity (activity at the oposite end).
Fair point, that was a bad example. If I have several activities open and I'm switching between two, because the list doesn't seem to update or merely switching past an activity is enough to activate it it becomes necessary to cycle through several activities each time.
I believe Adam got it right: the order is updated when merely "switching over". This is different from what happens when you alt-tab from one window to another one: in this case, the order is updated only when the alt key is released, and definitely not every time you hit tab (while alt is still pressed).
Created attachment 130311 [details] Default behaviour
I've added an attachment that shows the default behaviour. What happens in your case?
It works as you show it but after selecting an activity if I then try to select another activity the activities remain in the same order. I was just trying to replicate it but I have several bugs with the switcher, some times it switches activities without popping up the overlay, sometimes the overlay isn't dismissed once I release the keys and this bug.
After switching from A to B activity, you are in activity B, and the order in the switcher when you open it again is the same as before you switched to B?
https://youtu.be/Do-hW0-LkzU This video shows all of my problems with the activity switcher. First the "Default" activity remains at the top of the list as I switch between "Gaming" and "Coding", second I have to use Win+Q to shut the overlay after switching and third the overlay didn't show up at all (I think this happens if I switch, close the overlay and then quickly try to switch again) (I hope youtube is okay, the video was too big to upload but I can try to compress more or host it elsewhere if it's a problem.)
I think I have the same issue as reported, but the behavior I see now - with Plasma 5.20.80 from Neon unstable is as follows: Setup: 3 available activities, lets call them A, B and C. Behaviors: 1. When on any activity, hitting the "Walk through activities" key once (and releasing all keys) will switch to the previously used activity. Hitting it again will switch back. 2. When holding the modifier keys after releasing the TAB (my setup is custom and I'm using multiple modifiers), the activities bar remains open and shows the activity list in their iteration order (like with the window switcher) so hitting the TAB key again will switch to the next activity in the list and then the next until the modifiers are released. All this is fine. The issue I have is that the order the activities are shown in the activity bar and iterated over, when not releasing the modifier keys between switching, is a bit weird: Lets say we are starting in activity A. Activating the shortcut and holding the modifiers - the desktop switches to B, and shows the activity bar with B selected with the following order: B, A, C. So activating the shortcut again - without releasing modifiers - would bring you back to activity A, and only then to C. Compare that to the window switcher: I have 3 windows, I'm on A with the previous B and I want to get to C - hold ALT, press TAB once (get to B) and again (get to C). But with the activity switcher - hold modifiers, press TAB once (get to B) press TAB again (get back to A) pres TAB a third time (get to C). I think what happens here is that the activity manager - on invoking "Walk through activities" - first switches to the last previously used activity and only then shows the activity bar with all activities sorted by (the post switch) LRU order, while the "walk through windows" shortcut first lists the LRU windows and only then switches, so that when the window switcher UI appears, the current window is always the second on the list. The problem becomes very apparent when you combine it with the reverse action: - Window switcher, with A,B,C as LRU order: hold ALT, press TAB, hold ALT and SHIFT, press TAB, release modifiers - you are now at A. - Activity switcher, with A,B,C as LRU order: hold modifiers, press TAB, hold modifiers and SHIFT, press TAB, release modifiers - you are now at C.
The current behavior also has an annoying side effect: 1. Assuming activity LRU order is A,B,C. 2. If I want to get C, I have to hold modifiers than tap TAB 3 times (not two, as I discussed previously). 3. Now I want to go back to A. You'd think it was the previously used activity so it will take a single "walk through activities" action - activate the action once and you are now at B. The problem appears to be that when walking through activities without releasing the modifier, the activity manager updates the "last used" time for the first activity you switch to - even if its only on the way to another activity - but not to any other activity. So in step (2) above, going from A to C, what happens is this: activate action -> switch to B -> update B last used time -> continue action -> switch back to A (no timestamp update) -> switch to C. If you now open the activity bar you can see that the activities are ordered (by LRU order) as C, B, A.
I think activities should be deprecated in favor of fine tuned session management of applications. E.g. running and closing upon upon demand with specific files opened. But this would heavily depend upon apps' implementation of the session API.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1546
(In reply to Oded Arbel from comment #11) > I think what happens here is that the activity manager - on invoking "Walk > through activities" - first switches to the last previously used activity > and only then shows the activity bar with all activities sorted by (the post > switch) LRU order, while the "walk through windows" shortcut first lists the > LRU windows and only then switches, so that when the window switcher UI > appears, the current window is always the second on the list. Hi Oded, it looks like your theory was correct and my MR (auto-linked by the Bug Janitor Service) should fix the issue at least for Plasma 6. Assuming the review goes smoothly.