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.