OSX 10.11 (El Capitan) split view ? (I haven't succeeded yet)

I like the new split view in El Capitan, but launching it depends on mousery – either some Mission Control dragging and dropping, or pressing and holding on the target window's Full Screen button.

I haven't yet found a way, through KM or script, to mouse down and delay. Any thoughts ?

The attached (click and hold) doesn't work:

Attempting El Capitan split screen (not yet working).kmmacros (3.5 KB)

I've been using Slate for this kind of thing. I especially like the 'chain' macro/command. Press a sequence to move a window to some place, again to do something else, and again, and again, with different results every time. I have a sequence to push a window to the edge of the screen, then 50%, then 1/3. Very handy.

You can do sequences in Keyboard Maestro in a couple ways. The easiest is just have a variable that tracks the next state and a switch statement.

Alternatively, you can detect the current position of the window and base it on that.

Hey Carey,

How about posting a Slate example (or two) or pointing to 1 or more.

(I've seen the default file.)

I have to replace MercuryMover due to lack of updates, so I'm looking for a new window manager.


I thought about how best to do this, so here’s my .slate file. I agree that the default is not all that real world.

I’ll answer any questions related to this file, if needed.

# ~/.slate <---<<< This file
# Default can be obtained here: https://raw.github.com/jigish/slate/master/Slate/default.slate
#                                       ...cb
# The menu bar is 22 pixels deep

config defaultToCurrentScreen false
config orderScreensLeftToRight true
config nudgePercentOf screenSize
config resizePercentOf screenSize

# Personal System Offsets
# Has to be a way to allow for the way OS X puts together different screens
alias xoffset 1920
# The top edge of my small/wing monitor is not aligned with the top edge of the main screen,
# and they're different resolutions.
alias yoffset 65

# Monitor Aliases
alias monitor0 1280x1024
alias monitor1 1920x1080

# Position Aliases
# My Preferred Screen Sections
# NOTE: Screen coordinates override monitor assignments ...cb
alias 1-centre-850 move 535;22 850;1058
alias 0-centre-big move 407;22 1105;1058
#alias 0-centre-bigger move 215;22 1490;1058
alias 0-centre-bigger move 215;22 1517;1058
alias 0-left-strip move 0;22 402;1058
alias 0-right-strip move 1517;22 400;1058
alias 1-centre-big move screenOriginX+screenSizeX*0.1;screenOriginY+0 screenSizeX*0.8;screenSizeY ${monitor0}
alias 1-left-big move screenOriginX;screenOriginY 1090;screenSizeY ${monitor0}
alias centered move screenOriginX+(screenSizeX-windowSizeX)/2;screenOriginY+(screenSizeY-windowSizeY)/2 windowSizeX;windowSizeY
alias 850 move windowTopLeftX;windowTopLeftY 850;950
alias left-third move screenOriginX;screenOriginY+0 screenSizeX/3;screenSizeY ${monitor1}
alias centre-third move screenOriginX+screenSizeX*1/3;screenOriginY+0 screenSizeX/3;screenSizeY ${monitor1}
alias right-third move screenOriginX+screenSizeX*2/3;screenOriginY+0 screenSizeX/3;screenSizeY ${monitor1}

# Application-Specific Locations and Sizes
# alias chat-window move screenOriginX;screenOriginY 190;screenSizeY/2 ${monitor0}
# alias chat-window corner top-right resize:190;screenSizeY/2 ${monitor0}
alias chat-window move windowTopLeftX;windowTopLeftY 190;screenSizeY/2

# Move to other screens
# NOTE: These could either will go back and forth if there are only two screens,
# or goes in sequence according to the 'config orderScreensLeftToRight' directive above.
# These maintain the size of the window, or *reduce* it to the size of the screen.
bind right:ctrl;alt sequence throw next     resize:min({windowSizeX,screenSizeX});min({windowSizeY,screenSizeY}) | ${centered}
bind left:ctrl;alt  sequence throw previous resize:min({windowSizeX,screenSizeX});min({windowSizeY,screenSizeY}) | ${centered}

# Resize Bindings
bind 1:ctrl;alt;cmd ${0-left-strip}
bind 2:ctrl;alt;cmd chain ${0-centre-big} | ${0-centre-bigger} | ${1-centre-850}
bind 3:ctrl;alt;cmd ${0-right-strip}
# bind `:ctrl;alt;cmd ${1-centre-big}
bind `:ctrl;alt;cmd ${1-left-big}
bind 8:ctrl;alt;cmd chain ${850} | ${centered} | push up
bind i:ctrl;alt;cmd chain ${centre-third} | ${right-third} | ${left-third} 

# IM Contact Window
bind i:ctrl;alt;shift ${chat-window}

# Centre current window
bind c:ctrl;alt;cmd ${centered}

# Corner Bindings
bind up:ctrl;alt;shift chain corner top-right | corner top-right resize:screenSizeX/2;screenSizeY/2 | corner top-right resize:400;screenSizeY/2
bind down:ctrl;alt;shift chain corner bottom-left | corner bottom-left resize:screenSizeX/2;screenSizeY/2 | corner bottom-left resize:402;screenSizeY/2
bind right:ctrl;alt;shift chain corner bottom-right | corner bottom-right resize:screenSizeX/2;screenSizeY/2 | corner bottom-right resize:400;screenSizeY/2
bind left:ctrl;alt;shift chain corner top-left | corner top-left resize:screenSizeX/2;screenSizeY/2  | corner top-left resize:402;screenSizeY/2 

# Push Bindings
# Screen Splits with double press
bind right:ctrl;alt;cmd  chain push right | push right bar-resize:screenSizeX/2 | push right bar-resize:screenSizeX/3
bind left:ctrl;alt;cmd   chain push left | push left bar-resize:screenSizeX/2  | push left  bar-resize:screenSizeX/3
bind up:ctrl;alt;cmd     chain push up    | push up bar-resize:screenSizeY/2 | push up bar-resize:screenSizeY/3
bind down:ctrl;alt;cmd   chain push down  | push down bar-resize:screenSizeY/2 | push down bar-resize:screenSizeY/3

# Fill Screen
bind m:ctrl;alt;cmd corner top-left resize:screenSizeX;screenSizeY

# Grid
bind g:ctrl;alt;shift grid padding:5 0:10,8 1:8,8

# Micellaneous
bind r:ctrl;alt;cmd;shift relaunch
bind z:ctrl;alt;cmd undo

1 Like

That looks good.

For tiling generally I’m using a set of my own KM macros which define various (triptych, quadrant etc) grids and cycle active windows around successive positions in them.

The only limitation (and the reason for my interest in the Capitan native variant) is that that resize + move model leaves menu bars visible, whereas 10.11’s split full-view approach hides them. Not a big issue of course, just a preference.

Apparently I’m missing something. I understand the example, and the programming is/should be a trivial exercise, but I can’t find where to insert the calculation into the switch statement. What slipped by me?

Hey Carey,

Yeah, I can see how that would be confusing.

Remember though that you can do calculations in text fields with the calculation token.


Swith Action with Calculation.kmmacros (2.7 KB)

Ok… But I want to do stuff like compare the front window with some fixed sizes, as per Peter’s response originally. I want to…

# create default sizes
 set windowDimA=(800,800)
 set windowDimB =(1024,1024)

 switch windowDimA
 # do something
 switch windowDimB
 # do something else
 # do the default

Must I use the the Calculate token, or can I just use comparison operators?

I don’t even really need it that complex. I want this:

on first press set frontmost window to sizeA
on second press set frontmost window to sizeB

I thought the comparison would make it smarter, and I have to detect that it’s the first, or second press anyway. Peter’s suggestion was to detect the size of the current window, and go from there, which I like.

I think I've got it:

There you go! Direct comparison of the Window Frame array to a text string array.

This particular macro centres the front window on my 24" monitor, and makes it one of two sizes, based on what size it was before. The thing is this: Many Web sites are now wider than is comfortable for extended reading. If that's the case, I can easily make it my preferred size, and then back to the wider window for 'normal' browsing.

The plan is that I will have hotkey triggers for a bunch of these, but they will be smart enough to do certain specific things, depending on the app, and the screen they're on. Slate cannot do this.

Next step is to control which monitor it's on without having to address the absolute coordinates, which would make the script more generic, and enable a 'max' width and height.

1 Like

Got the screen specification solved:

Notice that I don't bother moving down the 23 pixels to miss the menu bar. The system does this for you anyway. You need to be aware the system is doing it, but you don't need to do it manually.

Note that I have now changed from the SCREEN function to the SCREENVISIBLE function. Not because it works better, but because it's more correct. It calculates the area of the screen without the menu bar and dock.

Just for the heck of it, here's a window to the left 50%, and to the right:

Hey Carey,

Good job. :smile:



Congratulations! Looks cool, but I'm not sure how to use it.

So is this a general split screen function that will work also on Yosemite?
If you're now finished with it, what do you think about posting it as a finished macro in the macro section?


Those two examples demonstrate the ‘math’ to make a window occupy the left, and right half, respectively, of the screen they’re on. Just put each one separately in a macro, and assign them separate keystrokes. That’s what I do. It’s more flexible, and more generic.

It wouldn’t take much to use those macros to load the current window, and the previous window, sending each to opposite sides of the screen.

It wouldn’t take much to load an app, open two windows, and send them to opposite halves of the screen. I will get to this at some point, but it requires decision making as to which app you’re talking about, whether or not there’s already a window open, and some other stuff I probably haven’t looked at yet.

The first thing macro shows the use of a case/switch construct, which, when finding a window that’s a specific size, sets that window to another specific size. If it finds a window that’s not the size you want, it sets it to a specific, default size. Other cases could be added which examined window size, which app is running, which screen your on, or any other detectable condition in KM. My original process, which used the ‘chain’ directive in Slate, used three different size windows in a cycle, so if you find a window of size 1 you make it 2, or if it’s 2, you make it 3. This construct in KM is more flexible because it can detect more stuff.

I will post this when I add some other example conditions. I have a use case for two specific windows (iMessage and Skype). Both of those have windows which cannot be made smaller than a certain size, so tiling them on my second screen requires a non-symmetrical layout (upper and lower right corners, actually), which can’t be dealt with using just 50%. There are specific sizes required for a sensible tiling, and that will be added to the ‘corner’ macros, but will consider which app they’re acting on.