Does anyone have a Keyboard Maestro macro to move an app back and forth between the mac and an external monitor via a keyboard shortcut?
Thanks a million!!
I know Keyboard Maestro can do this, but Iāve always used Spectacle for that (although itās no longer developed, so people are recommending switching to Rectangle instead).
1 Like
I would be interested in this as well. I put together a series of macros (a la David S) to move windows around - left side, right side, top, bottom, the four corners. I have the macros do said movement on the screen that the window is currently on. However, I would also like to be able to shift windows from one screen to another, and I have not been able to find a method for doing this.
As far as I have been able to discover thus far, KM provides the facility to find out the number of screen, and to specify a screen to move a window to (either by number or by keyword tokens such as Main, External, Front, etc), but I cannot find a way to find out which screen a window is currently on to thereby determine what screen to move it to.
I can think of kludgy ideas like trying to get the dimensions of the screen the window is on and comparing to the dimensions of very screen to figure out where the window is, but obviously that is not a robust solution and of course fails if you have two screens with the same dimension.
I have found no function or token that returns the screen a given window is on, as of yet.
I am wondering if there is a way to determine this via AppleScript?
1 Like
Hereās how I do it. Iāve got a 13-inch MacBook Pro with a 23-inch monitor connected to it. I use the external monitor as the main display, with the MacBook Pro off to the left. (That explains the negative number in the macro that moves the window to the MBP screen. I think. Itās been a long time since I made these.)
Shift-Control-Up Arrow moves the frontmost window to a fixed spot on the external monitor:
Shift-Control-Option-Down Arrow moves the frontmost window over to the MBP display:
The way I worked this out was to make two km shortcuts, one to move the window to the center of the main screen and one to move the window to the center of the external screen. I used something like cmd-opt-left_arrow and cmd-opt-right_arrow. Then, when I issue the āmove to main screenā combination the window is always moved to the center of the main screen. I know itās not exactly what youāre looking for but I find it quite handy.
Yes, that will work. I am fine with executing two steps, first to move the window to the desired screen and then to move it onto position on that screen.
I just want to find a way to use one macro to move the window through each attached screen in order. If you went to a third screen you would need yet another macro.
I know that you were asking about Keyboard Maestro, however if you use BetterTouchTool a less refined option could be the āMove Window to Next Monitorā. It doesnāt re-size the window, so you might need a second action.
1 Like
I do something similar to tonycraine, but instead use the SCREEN variable to distinguish how to move the windows (ex. Main, Second). Hereās how I move an active window to my second display:
And how I move one back to my laptop:
1 Like
Attached is my first pass KM macro that uses one trigger to move a window from screen to screen. I have only two monitors attached at this time, so it is not tested on >2 monitors but I think it will work.
The idea here is to a) use a single hotkey (or other trigger) to accomplish moving the window from monitor to monitor in a round robin fashion (eg it cycles successively through each monitor in the order the KM assigns them) rather than having a separate trigger for each target monitor, and b) take into consideration various relationships between the monitorsā layout (for example on one setup I have an external monitor stacked above my laptop screen, but on my desktop iMac I have a second monitor off to the right).
Below the image is an analysis of how it works. There may be fence post problem; I need to figure out how to enter greater than or equal signs into calculations so the comparisons have to be updated when I find out the proper keystrokes ( 
).
Note that it is my understanding that in KM, the main screen is always index 0, and then the screens are numbered from left to right from 1 to SCREENCOUNT(). I donāt know how left to right is determined for vertically stacked screens, but seems to relate to the screen with the smaller coordinate for its left border (my external monitor above my laptop is much larger than the laptop screen which is centered below it and so its left border is at -872. Note that the top left corner of the main screen is at (0,0).
The steps are:
-
Get the āframeā of the front window (which is presumably the one I want to move). Saving this as text in a variable allows the elements of the frame (Left, Top, Right, Bottom) to be extracted in calculations. With this, I know where in the coordinate space that includes ALL screens the window is located.
-
The variable Local_screencounter tracks which screen I am looking at in the subsequent loop. It runs from to 1 to SCREENCOUNT(); the value 0 is always the Main screen but I ignore that as the main screen ALSO has an index in the above range.
-
Loop through each screen (SCREENCOUNT() times):
a) Check the listed conditions to see if the window (āframeā) is in the current screen. Note the present code requires that the entire window must be contained on the screen; if a window overlaps two screens this condition will not be met. I think the code is self-explanatory. I decided to do it this way because I wasnāt sure what I wanted to do with moving a window that overlapped two screens between the screensā¦you might want to modify to suit your needs, perhaps by defining the screen a window is in by where the top left corner is.
b) If the window is on this screen:
i) Compute the screen to move the window to. Add 1 to Local_screencounter to get to the next screen (to the right), but if the result is >SCREENCOUNTER() wrap back to screen 1.
ii) Move the window to that screen and put it in the middle of the screen by resizing it.
iii) Done, so quit the loop.
c) If the window is NOT on this screen, increment the Local_screencounter so we can check the next screen on the next loop iteration.
If we donāt find the window on any screen (which should not be possible, butā¦) then just fall off the bottom of the macro and do nothing. You may wish to put a notification alert here.
Note that the use of > and < in the comparisons is not correct, and these should be >= and <=, but I have to review the KM wiki to find out how to type that correctly in an a calculation field and update the macro. You will want to do the same.
Hopefully people will find the useful. My workflow is (I think) going to be to move a window to the desired screen with repeated hotkeys and once on the correct screen then use other hotkey triggers to position it. I think that will be efficient enough for my needs.
1 Like
Thatās essentially what I do. My second display is to the right of my main display, so I have cmd-ctrl-opt-right_arrow to move a window to the right screen and then cmd-ctrl-right_arrow to move the window to the right half of the screen, then another pair using left_arrow (I may have mixed up the modifier keys, sorry about that but Iām Mac-less right now).
Hi Gangā¦thanks a million for all the responses. My plan is to find time this week to work on this. Will report back my successā¦hopefully.
I know you asked for KM but just in case you would have it as well, BetterTouchTool has built-in functionality for this.
Well, Iāve been doing some work on all of this and I am close to a workflow that I am happy with.
I have a group of KM macros now that handle moving the front window to the left or right 1/2 of the screen, centering on screen at the current window size, centering with a pre-set window size, centering in width but full height of the screen, making the window fill the full screen, moving to the left or right 1/3 or 2/3 of the screen or center 1/3 (useful when I have windows on the external 34" monitor I use at times with my MBP), and moving between screens.
Here is a picture of this macro group:
My big problem now is that I a) have not thought of a really good, coherent/consistent set of triggers that really makes sense to me, and b) remembering all of these things. I have tried just popping up a palette using the META key setup with Karabiner Elements, which works well, but is not the most facile approach, so I decided to hook in Alfred as well.
I now have an Alfred workflow (which I can share if anyone is interested) which when triggered queries KM to get all of the macros in this group and builds a selection list. I use the trigger āwcā (for window control) and it is pretty efficient to invoke Alfred, type WC, and either type some letters to narrow down the selection or just action the movement I want and have the window jump to its new location.
I suspect I will wind up creating keyboard shortcuts for the most common things I do after I have used this for a while to see what pops up as most commonly used, and leave the others to be selected only via palette or Alfred.
+1 for Spectacle. It is great for moving windows between monitors as well as resizing within a monitor.
Looks from their website like spectacle is no longer being actively maintained - assuming I found the correct site. Too bad; it would have been interesting to check out.
Spectacle still works fine, Iām using it on Catalina right now, in fact.
However, the developer does seem to be suggesting people look at Rectangle for the future.
@tjluoma: Rectangle looks like it might actually be pretty good.
However, I really like the way I was able to integrate my KM macros into Alfred. I find it much more efficient/convenient for me to either invoke a palette in KM with one keystroke and select from the palette, or even better to fire up Alfred and select or type what I want to do than to try to keep track of a plethora of keystrokes and remember which one moves a window to the left 1/2 or the left 1/3 or the left 2/3ā¦so for now I will stick with what I have set up.
Unfortunately, Rectangle does not support AppleScripting (or at least I could find nothing in the posted source code relative to handling Apple Events. Since it is posted on GitHub, it might be worth contributing to the project to add thatā¦if I can ever find the time!
I am pretty happy with my current system for managing window position. (Donāt know about external monitor though, as I donāt use one).
I use Karabiner to re-map the right ā„ key to ā§āā„ā. Thenā¦
-
ā„ ā(=ā§āā„ā ā) moves the current front window to the right half. -
ā„ ā(=ā§āā„ā ā) moves the current front window to the upper half. -
ā„ ā(=ā§āā„ā ā) moves the current front window to the bottom half. - And so onā¦
Yes indeed BetterTouchTool does, however in my experience over the past week of trying, it isnāt 100% reliable Iām afraid where you need to have multiple actions per trigger.
@nlippman, Hi! Iām the developer behind Rectangle. Thanks for the idea on supporting AppleScripting - itās something I thought about a long time ago, but had forgotten about. I just created an issue for it. Iām also strapped for time, so I donāt think Iāll get to it in the near future (a pull request would definitely be welcome!). I donāt think it would be a difficult task to implement.
In terms of keeping track of a plethora of keyboard shortcuts - I totally get what you mean. To solve this problem, I created another app built on top of Rectangle, called Hookshot, for my personal use and I liked it so much that I polished it up and released it. Note that itās not free nor open source. Iāve got a list of features that Iām looking to implement for it, but am always open to feedback if you give it a try. Iām purposefully keeping Rectangle slim on features, so Hookshot is where Iāve put more of my experiments.
1 Like