Accelerator for "cycle to next monitor" #190
Conversation
|
Hi, thanks for your patches, I have no time to review them not but I will try to take a look during the weekend. Just one quick note: the |
|
Those patches look good in general, but I have some issues with it. First I don't agree with the Second, In the first patch it you need to also change the size of the tilda window, look at Third, your code duplicates part of the code in I am planning to release 1.3 soon (probably end of October), so if you want this to end up in 1.3 then please send me a rebased version with the the fixes soon. |
|
Appreciate the review and feedback! Agreed on all counts. I'll work up a revised set of patches and get it back to you. Thanks! |
|
Just a quick heads up, I pushed some commits from the wip/monitornames (but not all of them), so Tilda now makes use of the monitor name instead of the monitor number, please consider that when you rebase your patches |
|
Awesome! Will rework on top of those, hopefully within the next day or two. Thanks. |
Notes / loose ends: * I went from an original approach of setting the relative x and y coordinates to (0, 0) after cycling to the next monitor, to instead preserving the relative x and y against the newly-selected display. In both cases not messing with the size. This might not be the *best* approach -- some other possibilities I can think of would be (1) a "proportional transposition", or (2) just setting the position and/or size to arbitrary, consistent values (like filling the entire workspace on the new monitor). I spend almost all my time in fullscreen mode, however, so I am neither affected by nor the best judge of this use case. * No effort is made to update the wizard UI if we cycle monitors while the wizard is open. (It looks like we aren't supposed to be able to trigger hotkeys while the wizard is open, but I was able to get it to work by changing focus.) This decicison is based on the precedent set by other hotkeys such as "enable fullscreen". * What would an integration with the wip/monitornames branch look like? Or, that branch, done right and completely, probably supersedes us.
Sometimes -- usually if a monitor is hotplugged or the multiple-monitor geometry is changed -- the prevailing (x_pos, y_pos) in the absolute coordinate space do not agree with show_on_monitor_number. We now add some additional logic to trust show_on_monitor_number above all; if the newly- calculated absolute (x, y) that we get from trying to retain relative position on our new monitor places the window outside the workarea of the destination monitor, we drop the hammer and set x and/or y to 0 as needed. This means, for example, if you have a Dell monitor on your left (as monitor 0) and an LG monitor on your right (as monitor 1), and have tilda on monitor 0 (the Dell), but then change your virtual monitor configuration such that the LG is to the left of the Dell, tilda will go from being on monitor 0 to monitor 1, but without updating its configuration values. And your absolute coordinates might be messed up, too. With this patch, next time you cycle the monitors, you'll land tilda on the Dell (where it already is!), but after that, things will operate normally.
I was gazing longingly at https://github.com/lanoxx/tilda/tree/wip/monitornames. That branch is ambitious, and I would love to see it come all the way through at some point, but this is a simple solution that gets me 95% of the way there.
Between home and the office, I have at least three different multi-monitor workstations I plug into on a weekly basis, each with a different monitor type and physical geometry. Sometimes the external monitor is on the left (and thus is monitor #0), and sometimes it's on the right. Sometimes my terminal is front and center, and I want it on my tiny 1366x768 laptop display, and sometimes I want it on the secondary display. Etc.
All this adds up to a lot of diving into the wizard to jam the "Select monitor" combo box. So I wanted a keybinding to just move tilda to the next monitor.
As described in e5805e7, I made a call about how the window should be positioned on the destination monitor in the likely event that the workarea sizes are different. I think all three options (the implemented one, plus the two alternatives listed in that commit msg) are pretty reasonable, and would be happy to modify this patch to implement any of them.