jigish / slate Goto Github PK

Add an option to throw to be able to throw to screen that is right/left/up/down relative to current screen (instead of specifying a hard screen ID).

Just raise the window that was selected. This is especially important for apps like Terminal, where you will have many open but which are interleaved with other windows (like browser and vim).

Ability to specify a set of default locations for new windows per application (also with priority-based locations per monitor configuration i.e. put it on monitor 2 if it exists, otherwise monitor 1, otherwise monitor 0)

Also re-compute layouts on monitor plug-in/unplug?

Add config to be able to specify WHAT the percentage is of (currently it is windowSize, but should be able to be changed to screenSize)

Maintain chain state per window, not globally. Also reset chain state on window resize/move/close.

Config file tokens currently can only be delimited by single space characters. Improve this to allow multiple spaces/tabs between tokens.

For example, this should be valid config file syntax:

bind 1:ctrl       push     down

Also attempt to replace the config with screen/window contants and compute the result to see if it is parsed properly. Throw error if not.

If you have many windows, the hints windows appear onscreen separated by 50ms or so --it doesn't feel instant (my original implementation had this problem, and Caleb noticed it as well).

I'm not sure what is taking the time (probably the accessibility API), but if it's window creation time, you could keep those hint windows around in memory and use them again the next time the hint operation is triggered.

Even though this is a performance hit I think instead of trying to intelligently decide whether to resize first or move first, we should just resize->move->resize. It seems like Lion has issues resizing windows that are offscreen for some reason.

For example:

bind 1:ctrl [push down|push up|push left|push right]

will "push down" the first time ctrl-1 is pressed, then "push up", then "push left", then "push right".

Implement teh hints of teh windowz!

probably should look something like:

bind BLAH hint

and would be good to have a bunch of config options to tweak it

Ability to specify:

1. style - bar (push and resize to a top/bottom/left/right bar)
2. monitor option?

I have two Apple thunderbolt displays daisy chained together. The screens are laid out like this:

Left    Right
   Laptop

OSX unfortunately does not remember the Apple displays layout across disconnects. 50% of the time I plug in to these monitors, I need to swap their layout positions by using the Display Preferences Pane.

After doing this adjustment via Preferences, the Slate screen numbering does not update -- screen 1 could now be on the right, while screen 3 is on the left, for instance.

Do you think this problem is solvable? Mechanically this could be handled by polling for position changes every few seconds, but should Slate dynamically change its screen numbering in response to layout changes?

If user holds keystroke, repeat bindings.

doesnt work for me anymore...

add ability to set position to:

top-left
top-right
bottom-left
bottom-right
center

Add the ability to choose the dimensions for throw resize. Similar to push bar-resize.

Certain functions don't work in expressions because they require commas,

Caleb's slate config repros the issue on his box.

Similar to get config info, add snapshot operation to take a snapshot of the current screen state as well as activate-snapshot operation to go back to a saved snapshot

The worst is when I plug my laptop into a projector and all of my windows get resized because all of my displays are resized to 800x600.

Is it possible to save my window configuration automatically when a new monitor is plugged in but before all the resizing happens?

I suspect if you reference a screen number which is not currently connected, Slate has trouble parsing bindings related to that screen. The third command in this series:

bind 1:ctrl;cmd throw 0 resize
bind 2:ctrl;cmd throw 1 resize
bind 3:ctrl;cmd throw 2 resize

Causes Slate to give this error in a message box upon startup (titled "Unable to Parse Binding"):

Unable to parse '*** -[NSCFArray objectAtIndex:]: index (2) beyond bounds (2)' in 'bind 3:ctrl;cmd throw 2 resize'

Allow expressions

The most common use of snapshots is probably to save and then later restore windows when unplugging a laptop from a monitor setup. For that use case, a menu option would be nice to have, because it requires no slate config setup, and it's not used often enough dedicate a whole hotkey to it (I sat down and tried, but couldn't pick something I would remember).

Adding a very basic UI for this (save/restore current state) will make it a drop-in replacement for Stay.

Add operation to move windows to corners:

bind key:modifiers corner <top-left|top-right|bottom-left|bottom-right> <optional:resize?>

Add the ability to choose which corner to anchor on for the resize operation

i know you can just wait 3 seconds, but I do this sometimes out of habit and it's unsettling that it doesn't work.

It seems that screen size takes into account the OS X menu bar making things like stacking two windows on top of each other not line up properly. Can there be a built in property where the screenSizeY is the height of the available window region excluding the menu bar? Thanks Jigish!

Switch Slate to ARC

If the move operation first moves the window so some of it is off screen, for some reason the resize fails. Maybe move should be smarter to know whether or not it should move first or resize first. Like:

1. Check what the new size should be, and what the new top left should be
2. Check if the new size + new top left causes the window to be off screen
3. if so, either move first or resize first depending on what works better.

This will allow you to show hints for more windows. Today, if the bulk of a window is showing but something is obscuring the upper left corner of the window, you can't select it with window hints.

The caveats to doing this are

1. You may need to visibility test two points in a window instead of just one, which may slow down how quickly you can show hints if that visibility test is expensive.
2. The placement of the hints will not always be in the same place on the window -- sometimes it's the upper left, sometimes its centered.

The README lists these as customizable parameters:

windowHintsFontColor
windowHintsFontName
windowHintsFontSize
windowHintsRoundedCornerSize
windowHintsBackgroundColor

windowHintsTopLeftX
windowHintsTopLeftY

If you provide a nice UI out of the box, none of these will be needed. Having customizable behavior is nice, but having customizable appearance limits what you can do in the future. If you wanted to add a nice visual effect upon selection (e.g. animating the text color from white->yellow), you can't, because you don't control the appearance.

In particular, letting users specify the hint positioning prevents you from doing smart hint placement in the future. A really nice feature would be to show a hint in the upper left corner or the center of the app, depending on which is visible. This happens to me all the time now -- I'll have a terminal which obscures the left side of some window, and I can't select those underlying windows using window hints, because their upper left corner is hidden (but the rest of the window is visible).

It's up to you, but I'd rather you take control of the aesthetic instead of letting the user mess with it so that you can provide a nice one and keep your software and README simpler.

Create CMD+Tab replacement

When using throw with the resize option, the resized window will overlap a static right/left dock but will not overlap a static bottom dock. Maybe add an option to specify whether or not to overlap?

Unless newWindowSize is specified. then resize first, move second.

If you have a maximized browser for instance, and a bunch of random windows underneath it, many random hints will be shown on top of the browser window, which is messy and confusing.

Try to put slate on the app store

This move command moves the window, but does not properly resize it. This is as of version f3f3982.

On screen 1, hit CTRL+CMD+left. This will resize the window to fill the left half of the screen. Next, hit CTRL+CMD+SHIFT+down. This should move and resize the window to fill the bottom left corner of the screen, but the window remains its original size.

bind left:ctrl;cmd push left bar-resize:screenSizeX/2
bind down:ctrl;shift;cmd move screenOriginX;screenOriginY+screenSizeY/2 screenSizeX/2;screenSizeY/2

Note that this move command does properly move and resize the window:

bind up:ctrl;shift;cmd move screenOriginX+screenSizeX/2;screenOriginY screenSizeX/2;screenSizeY/2

Note that this is with a monitor configuration of

1   3
  2

On the screen with the dock it is offset. Fix it.

The screen IDs defined in the .slate file change when Disconnecting/Reconnecting Monitors in the wrong order.

Add functions like min/max to replace dictionary so they can be used in bindings.

Menu option to list open applications, their window locations, etc. This should help ease the process of configuring slate.

fix it!

I have 6 windows which are being hinted and "G" is being used twice.

Probably related is that typing some hints does not raise the corresponding window, and link hints aren't dismissed. It may be because of this exception:

3/13/12 11:27:51.816 AM Slate: *** -[__NSArrayM objectAtIndex:]: index 12 beyond bounds [0 .. 6]

Create configuration helper menu item

For some windows, typing their hints will consistently raise an adjacent window, not the intended window.

Current resize operation doesn't play nice with applications like mvim/terminal/iTerm2 because they have discrete widths/heights. Add the ability to specify an actual anchor corner that will for sure stay in one place on resize/move.

This is the least surprising behavior and implicitly addresses issue #7, where connecting your screens in a different order will re-order your screen numberings. I think it's less work than defining screens based on resolution.

In particular, defining screens based on resolution doesn't help when you have multiple monitors of the same resolution (e.g. two 24" side-by-side).

I haven't tested the latest on master so apologies if it's there already, but I didn't see it in the commit stream.

On my screen, I have 3 windows from left to right, with the first one focused. The hints are A B C.

If I focus the second window, the hints are B A C. The hint letters change depending on which window is focused. I think it will be less disturbing if the hints had a stable ordering from left to right across the screen (i.e. the leftmost window is always A).