Repeatedly pressing meta+tab switches activities in a strange order. Sometimes it is erratic. Sometimes it flips between the current activity and the activity used directly prior to the current one. Pressing and holding meta and pressing tab implements the desired behavior, which is to cycle through all activities one at a time. This was working in Plasma 5.6. Reproducible: Always Steps to Reproduce: 1. Press meta+tab a few times.
Hi, Can you specify the version of Plasma you are using, not the version of KF5 - is it 5.7? When you open the switcher, is the 'erratic' next activity the second on the list, or is the switching actually skipping on to some random activity in the list? Or is the order in the switcher unexpected?
Hello - I'm on KDE Neon, so as of today Plasma 5.7.2. It does seem erratic but I think I figured out the pattern. If I press Meta+Q to pull up the activities list, the activities move around the list. The top activity is the current one. "Next Activity" always moves to the second item on the list. "Previous Activity" moves to the last item on the list. So with three activities it's like a shell game, the activities switch around erratically as the list is flipped around with the activity itself changing simultaneously.
> Hello - I'm on KDE Neon, so as of today Plasma 5.7.2. That is great news, it will be easy for me to test in a VM. I'll download the new iso and report back.
I'm unable to replicate this on a live neon (updated to 5.7.2) If I only press meta+tab, meta+tab, meta+tab it alternates between the two last used activities - pressing meta+tab switches to the previous one (like with alt+tab for windows). If I press meta+tab,tab,tab, it goes through the list from the most recently used one to the least recently used one. When meta is depressed, the current one goes to the top of the list since it is now the most recently used one.
(In reply to Ivan Čukić from comment #4) > I'm unable to replicate this on a live neon (updated to 5.7.2) > > If I only press meta+tab, meta+tab, meta+tab it alternates between the two > last used activities - pressing meta+tab switches to the previous one (like > with alt+tab for windows). You're right, 'previous activity' alone does not have erratic behavior. The behavior of 'next activity' is erratic. I think the keybindings introduce a bit of a delay, I'll describe how I trigger the race condition. I bind "next activity" and "previous activity" to the forward/back buttons on my mouse. I send dbus commands with xbindkeys. Pressing meta+tab and meta+shift+tab introduces a bit of a delay so the race condition is less obvious. #Previous Activity - forward button "qdbus org.kde.kglobalaccel /component/plasmashell invokeShortcut 'previous activity'" b:9 #Next Activity - back button "qdbus org.kde.kglobalaccel /component/plasmashell invokeShortcut 'next activity'" b:8 > If I press meta+tab,tab,tab, it goes through the list from the most recently > used one to the least recently used one. So perhaps it will make sense why I preferred the behavior in Plasma 5.5: there's no way to bind meta+tab+tab+tab to mouse buttons, and no dbus interface I can use to replicate this. I don't think mimicking behavior similar to alt+tab is a good justification for the change. For one, the activity bar widget does not change around activity order, so there's no longer any useful visual indicator to explain where you're going to go when you press meta+tab or meta+shift+tab. I usually don't care to remember in advance which activity I came from last, I just want to cycle through the activity bar. Next, I expect people using more than 3-4 activities to be extremely small. When there are only 3 activities running there is not really any benefit to changing the order of activities around. Previously, with two shortcuts, there was always one button to map to each alternate activity. With four activities running, only one activity would require more than two presses. Pulling up a large activities sidebar to remind you of all the choices is not as useful. In the alt+tab task switcher case, it makes sense to observe the pop-up if you have 10 or 15 windows open. And finally, activating "previous activity" then "next activity" does not necessarily return you to where you started if you send the commands quickly enough. The commands are non-invertible. On top of those personal workflow preferences there is still the race condition with "next activity." if "previous activity" returns you to the activity you were using previously, what is a sensible behavior for "next activity" if you haven't pressed "previous activity?" There is no next, you're at the end of the line. I think at a minimum sending the 'next activity' command repeatedly shouldn't make the Activity Switcher widget flip around unpredictably.
> So perhaps it will make sense why I preferred the behavior in Plasma 5.5 Now I understand. Yes, the shortcuts are now meant only as the alt-tab analogue for activities. Previously, meta+tab was confusing to the users, and this change was requested and then vetted by the plasma team. Binding this to mouse buttons is an evil thing to do, but I do understand your point of view. Mind that this way you will have a problem if you cycle through activities like that since plasma will think all activities have been used recently. My suggestion is to bind one of the mouse buttons to toggling the activity switcher, and then choosing the exact activity you want to switch to. If you do not want this, keep reading :) > On top of those personal workflow preferences there is still the race condition with > "next activity." if "previous activity" returns you to the activity you were using previously The shortcuts have been renamed to "Walk through activities" like it is for alt+tab and "Walk through windows". The old names should not be visible in the UI anywhere. -- Now, while this behaviour is not going to be reverted to the old one, the old behaviour can be /easily/ replicated. You can get the files next-activity.sh and prev-activity.sh from [1] and bind them to your mouse buttons. These scripts will become a part of kactivities-cli command-line utility so that people do not need to do hacks like the manual keyboard shortcut invocation like you have done. [1] https://quickgit.kde.org/?p=kactivities.git&a=tree&f=contrib%2Fbash
I realized I never said thanks. The scripts are just what I was looking for, I appreciate it!
No problem. BTW, from the next KDE Frameworks release, you'll also be able just to use kactivities-cli --next-activity kactivities-cli --previous-activity