+1
Implement virtual_desktop_order_fix for reconnected Remote Desktop sessions
I run 7TT on my work computer (latest Win 10), which I use via Remote Desktop (RD). I love 7TT for the ability to reorder ungrouped taskbar buttons. But when I disconnect from my RD session, and reconnect, the custom ordering is lost. Reproduction steps:
- Connect to RD session, where 7TT is installed
- Order taskbar buttons in a custom order
- Disconnect RD session (not log off)
- Reconnect RD session
- Custom order is lost
I've found a workaround, but it's not ideal:
- Connect to RD session
- Enable the virtual_desktop_order_fix advanced option
- Create a second virtual desktop
- Switch back to first desktop
- Order taskbar buttons in custom order
- Disconnect RD session
- Reconnect RD session
- Custom order is lost
- Go to second virtual desktop
- Go back to first virtual desktop
- Custom order is restored
This works, but the problem is that I do not want to keep a second virtual desktop on the remote machine, as it interferes with other customizations I use.
So, my suggestion is this: When a RD session is re-connected to, restore the custom taskbar order, using the same routine used by virtual_desktop_order_fix.
Thanks for your consideration.
Служба підтримки клієнтів працює на UserEcho
The virtual_desktop_order_fix option is implemented as following:
Internally, the taskbar items are kept in an ordered list in the taskbar code. Items are appended to the end of the list as they're added to the taskbar, but they're not re-ordered in the list when they're re-ordered on the taskbar. So, for example, if I open:
Notepad, Chrome, Firefox.
I can re-order them as much as I want, but if I switch to a different virtual desktop, and then switch back, I'll get them back as Notepad, Chrome, Firefox, since they're re-created from that list.
The virtual_desktop_order_fix option monitor for reorder events, and re-orders the list accordingly. As a result, when switching back to a virtual desktop, the taskbar buttons are re-created in the desired order.
Now, I'm not sure what exactly happens in the RDP scenario, but it looks like it requires a different, additional fix/workaround.
I'm not sure why a second virtual desktop interferes with your workflow, but I think that you don't need to actually keep it, all you need to do is to create a new one, switch to it, and destroy it right away. Or, in hotkeys: Win+Ctrl+D, Win+Ctrl+F4.
The conflict had to do with AutoHotKey scripts I'm running which manipulate the remote virtual desktop, focus of the full-screen RDP session, as well as the local virtual desktops. I've since reorganized my virtual desktops such that it's not a big deal. I could probably come up with an AutoHotKey script to perform the Ctrl+Win+D and Ctrl+Win+F4 workaround with a single keypress. I didn't know about those two shortcuts, so thanks for that.
I didn't really expect this suggestion to get implemented given the niche use case. But I thought it was worth a shot, and it gave me a platform on which to share my workaround with anyone googling the same problem.
Thanks for the response.