Ok, so I'm trying to make my setup super simple by creating a script that I can run in the morning that will launch all the applications that I use in the day and lay them out across my 'spaces' how I like them.
This was going ok and I was easily able to have a bash script launch the apps and then call to an AppleScript to move and resize their windows.
However, I like to use the new El Capitan feature and have some of my spaces as 'split view' spaces. E.g. Full screen Xcode/Terminal split. I can't seem to find a way to control this via a script.
Tl;dr Does anyone know how to get a bash script/AppleScript to put two applications into 'split view' on OS X El Capitan?
Looks like that first bit about launching and full-screening apps can be done with a fairly simple script, though it requires enabling Accessibility permissions first. It, however, won't do the split-screen bit.
I kept looking though and Better Touch Tool (pay what you want, $4.49 minimum) seems to get the closest of anything I could find, allowing you to trigger Full Screen mode and bring up the split screen Expose selector in the same action. It seems to be doing this by emulating a long mouse down on the full screen window control button (the green one in the top left). What you get is this:
I've been playing around with this and it seems there might be a (so far seemingly very un-intgelligeble, though reliable) way to control the order of full screen apps and trigger an app into split screen mode in a situation where that previously full-screened app is the only option available for splitting the screen.
For example, given the following, accomplished by launching iA Writer into full screen (space 2) via ⌘+^+F:
Focusing Safari and using Better Touch Tool to trigger split screen mode results in:
... Only one split screen app, even though there's several apps still running.
From this position you could use the "move to position" action in BTT and trigger a click on the only available app— I would think this could theoretically accomplish what you want, although it's convoluted and a bit suspect.
All that being said, it seems like the only way to get two apps launched into split screen mode without touching the mouse, since this could all be a BTT workflow you trigger from an Automator script. Digging further, you might be able to learn how BTT accomplishes their actions and write a program that does this for you, but we're already way beyond bash or simple cli scripting.
I personally just use Spectacle and tmux to zoom my windows around, though I admit, automated split screen would be somewhere close to live changing.
Related
I know there is a function called browser.window.move_to(0, 0) to move the browser into different position, but the OSX 10.9 is completely new for it.
Are there any methods can be used to move the browser to another desktop? E.g. Console to trigger command in "Desktop 2", but I want the browser appear in "Desktop 1".
Many thanks!
Ha, I was about to say this probably isn't possible before I tried this:
browser.window.move_to(-1200,0)
My second monitor is oriented to the left of my main screen. It worked. Nice question.
You'll need to fool around with it to get it right but watir appears to be able to use the entire canvas of monitors. If your monitor was above your main screen for example you'd move it there using something like
browser.window.move_to(0,-1000)
is in shell (Mac OS X Lion) a way how run program on specify position on screen?
I want to run two programs and specify their position on screen so one window will be next to another and they will be centered on screen.
You could try to hack something together using AppleScript. This link shows you how to set the window geometry of a certain application. The problem might be in actually talking to the processes that you just started. This SO question deals a bit with using the process id to talk to an app using AppleScript.
I'm using 20 identical simulators (text base GUI like vi, refreshed quickly), and I need to control them in very similar way. e.g. input some command string to start/stop/config the simulator. The display is important, and I need them to flow on the terminal. Currently I can automatically start each one in a separate terminal.
But after that, I have no idea how to control them automatically. If I spawn the simulator using expect without a terminal, I will not be able to watch the output. Any suggestion on how could I proceed, or what tool could help?
This is tricky. You might be able to send the exact escape sequences which are generated by your keystrokes to your curses based program and then drive it. I don't know how reliable or easy that will be.
Would it not be possible to create an alternate front end which is scriptable for your simulator and use that for automated tasks like this rather than the CUI interface which is meant for human interaction?
I have a few different things open in the terminal whenever I'm developing -- log tailing, Ruby console, plain shell in a certain directory, and so on.
How do I:
start all those things at once, hopefully in the right position on the screen?
make them distinct so I can switch to them with Quicksilver / Alt-Tab?
Fluid solved this problem with all of my web apps, so now I want to do it with my terminals.
And while we're on the topic, has anyone found a working solution for getting OS X to remember window positions on an external monitor? If I unplug it and plug it back in, I have to drag everything back to the same position (although at least Mercury Mover makes it possible to do it with the keyboard.)
Open Terminal, and go into Preferences, then go into the settings tab, and create a new setting for each of your windows that you want. Either give them all different colour schemes, or duplicate a colour scheme multiple times for them all to have the same settings. Under the shell sub-tab, add "Run command" to be run at shell startup. (This is the command that will cd to the directory you want, or tail a log).
Then initialise the windows as you want. Then click Window in the main menu and select Save Windows as Group...
In OSX Yosemite you can use (in Terminal) Window -> Save group. It will do all the work for you.
In a fairly graphics intsensive application the requirements state that it should default to full screen mode even though the application is running under Windows. I know many games do this but I find it annoying. The default IMO should be to open in a window rather than full screen mode. I am proposing the first time the user runs the application they should select the default behavior. Am I wrong?
I think the annoyance-factor depends a lot on what the application tries to do.
If it is some utility that I might start while working in 5 different applications and it forces its fullscreen-ness on my, then I'd get highly annoyed.
If it is a specialized application that helps me with the entire workflow of a given task (so that I never or rarely need any other apps open at the same time), then fullscreen might actually be a valid default.
Whatever you do, just make sure that toggling the startup behaviour is very discoverable. Because no matter which way you'll go, some of your users will disagree with your decision. And for them it should be very easy to change to their prefered way.
I would follow the requirement the first time the application is launched. I would also provide a simple way to switch from full screen to windowed, for instance by pressing ESC (and another way to go back to full screen). Then I would store the mode when quitting the application and restore this mode at next launch.
Before doing the opposite of what your requirements say, I'd have the requirements changed.
However, what about giving the user the choice at install time?
The window at first-start-up should default to the optimal size for the largest proportion of users. For a graphics-intensive full-featured app, that may very well be full screen.
As for individual user preferences for window size, it seems to me most users won’t know if they want full screen or not until after they’ve started to use the app and see how much screen space they need and how much they use the window in conjunction with other windows. Asking them which size they want at install or first-start-up could thus be annoying and even confusing. It’s better to put such a setting under Options/Preferences.
Perhaps the best thing to do is save the window status on exit. Users who like it non-maximized thus only have to non-maximize it (and size it) once and then forget about it. The only consideration is to have some way to reset the window to the default (e.g., Window > Standard Size menu item) for novice users who accidentally resize or reposition the window to something bizarre and don’t know how to get it back. Alternatively, you could have a Window > Keep Sizes and Positions menu item for users to explicitly save the window status across sessions.
Go back to the requirements writers and ask them if they have considered non-traditional monitor setups, such as:
30" or larger monitor. Do you really want your app hogging up all the screen real-estate?
Multiple monitors. Which monitor will you run on? Can the user move your app from one monitor to another? Can your app span more than one monitor?
Virtual desktops. Can the user move your app from one desktop to another? Can they switch desktops while your app is running? Can your app span more than one desktop?
Such setups are increasingly common, especially large monitors. IMO, full-screen mode (the default for many older Windows apps) is becoming less and less useful.
The problem with presenting the user with the option of initially selecting fullscreen / vs windows is that they haven't used the software yet. How can they make a decision on which is better for them, without experience?
I would run the app in whichever mode provided the best user experience and then offer an option to change it both in the Preferences and though a hint while starting up the application for the 2nd time.