If you're looking for a window manager for OSX without having to actually configure anything, you can try using Spectacle: http://spectacleapp.com/
For instance on my imac 27'' I have Option+Command+Left|Right keys mapped to side (similar to windows 7.
And I can also have 4 windows open at once using Shift+Option+Command+Up|Down|Left|Right to move them to the different corners. Works really well with less than 2 minutes of setting the hotkey on a simple GUI configuration window.
I'm a -big- huge fan of Spectacle, I've been using it for a long time now and couldn't imagine life on a Mac without it. There's worth noting that there's a plethora of similar apps out there:
If you are already using Alfred, I'd suggest having a look at the new workflows available, in particular layout, which covers a lot of the features of spectacle.
For instance, typing 'layout left' in alfred will push the window the left side, topleft for the corner, etc.
Might be a good idea sdegutis, to have sample configuration that replicates the setup from Spectacle, Moom, etc., similar to what you did with Zephyros (I think?).
This looks great, but my favourite thing might be the Principles section:
> Hydra must be stable. It should never crash
> Hydra must be lightweight... never use more than 10 MB of memory
> API should be completely transparent
> API must not be bloated
I think these principles should be the standard to which we all hold our software. Looking forward to testing this out!
Edit to say: it would be really great to see some more complete code samples but I'm sure that'll come in time.
It's clearly better to have an app that never crashes than an equivalent one that crashes all the time.
However, making sure that your app is 100% crash-free isn't a zero cost thing. It takes time and effort to (often, a lot of both) to get to a completely crash-free app, meaning that the app either costs more, takes longer, or has to compromise on features - or possibly all three. In some case, that trade off is clearly going to be worth it - I'd rather a self-driving car took 10 years longer to develop than have one that rebooted itself twice a day, but in others I'm fine living with the occasional crash if it means cheaper or more feature-rich applications.
Can you give an example of the kinds of samples you would like to see, and where you would look for them? (I presume under the Examples section on the README page?) That will help me know what to put there.
You have a link to your own config and some screenshots of it in action, maybe it would be good to pull out the relevant sections of your config so people can replicate what they see in the screenshots?
I do not like the "API should be completely transparent" and "API must not be bloated".
I personally think APIs exist to hide complexity. They should make sense, they should be usable, but they need not be transparent.
Let's have a rather contrived example. In SDL, you can call SDL_Init(). That does a lot of things, and what it does differs on windows, linux, and OSX. I absolutely don't want the more transparent API of SDL_Init_Windows_Video(), SDL_Init_Windows_Audio(), SDL_Init_Linux_Video() .... And so on. Realistically, for absolute transparency, you'd just do away with the API and write every line of code SDL currently hides (Reductio ad absurdum I know)
The entire point of having that one SDL_Init() call that's identical on all platforms, even though it does many opaque things underneath (and different things per platforms) is that it's easier to understand and use. The goal of an API is to be usable and useful, nothing else. Transparency can often get in the way of usability.
As for the "bloated" bit. Well, I'd rather be able to do too many things than too few. It's a great goal to have a purely orthogonal (no method may be accomplished with another combination of methods) API, but it should not be done at the expense of usability.
> Nothing should be put into it except what's impossible or impractical to do in pure Lua, and what's extremely common and likely to be used in everyone's configs.
The entire quote makes it seem even more damning to me. Why would you cater to what's "likely to be used in everyone's configs"? That's another way of saying "Let's support only the least common denominator" which to me seems like a bad philosophy.
This philosophy would lead to twitter not having a friendship API because the only thing practically every api user does is login and (arguably) tweet, only a few deal with friendships or account settings. It would lead to linux not having a configuration option for running more than one physical CPU or hotswapping ram because the wide majority of people will never use these options.
I'm happy that the author of this software decided to make it simple and it seems to be working here, but in the majority of cases of API design, I'd much rather the API be usable, not transparent, and large, not minimalistic. I'd rather be able to call a method that does some common activity for me which I could technically do myself in a 1000 lines of code than not have such a method because it's "bloat".
I tried a ton of window managers (Divvy [1], Spectacle [2], Alfred worflows, scripts) over the years, but the most advanced, most easy to use and fastest solution is Moom [3].
It's extremely flexible, configurable, have nice design and clever tricks. It has far more features that all of the above. I'm not searching the perfect window manager anymore.
I'll second the motion for Moom. Great app, but I'm really glad to see some viable OSS solutions in this space. Environment hacking FTW.
I'll also mention a feature I adore from FlexiGlass[1]: the ability to map <modifier>-<1/2/3 finger move> to move the window under the mouse. For example, I use <option>-<2 finger move> for this mapping. No mouse click & hold required, and the entire window is the "hit zone". FlexiGlass can also resize similarly, but I tend to just use my Moom bindings to snap windows where I want them.
I find this to be incredibly pleasant to use for window moves because it's a very immediate experience, more like arranging paper on your desk. Even better, the window being moved doesn't have to be in the frontmost application. This makes it even faster to move background windows. The usual window movement via titlebar or window snapping app requires the moved window be frontmost/focused, so there's a switching back and forth required. Between the giant, whole window, hit area and less focus switching, FlexiGlass' approach is a huge win IMO. I still feel a bit self-conscious about having this app installed for one feature, but it's really that good.
I started with the moom trial, but when it came time for me to make a purchase, I ended up going with BetterSnapTool. It might not be quite as flexible as Moom, but a) it fit my personal needs and b) it was less than half the price.
I miss my days on Ubuntu with i3 tiling window manager. I currently use an app called Amethyst[1] but find it to be a bit buggy at times and just doesn't live up to i3 or awesome. I wonder if hydra can be used as a launch point to create a better tiling window manager for OSX. I'm not familiar with the APIs that OSX exposes, if any, to do things like window management but it would be awesome to see some more control over workspaces and not just the windows within a workspace.
Amethyst is the first tiling window manager I've used for any substantial length of time. I made my desktop transition from NetBSD -> OSX before tiling window managers were really much used. Amethyst gets props from me in being the first that has worked intuitively and stabily such that I've actually stuck with it for any length of time.
As for Linux, I realize that I'm personally in a place where leaving OSX would cause me no grief whatsoever. I catalogued everything I run on my Mac these days, and was pleasantly surprised to find I have zero local commercial software that I depend on, or indeed any Mac-only software. Generally, when I've used recent Linux desktops, I've discovered that the experience is at least on par with my Mac, with the added bonus that Emacs doesn't have so many quirks.
Battery life on my MacBook Air is really the only thing keeping me from moving back. I have to wonder if there is any movement to achieve power management parity with OSX in Linux.
I was in the same position and switched to Arch long ago. Power management in my MacBook Air 11 2013 is as good as in OS X, if not better. This sounds like a bold statement, but mind that it's almost 100% Intel hardware. Intel funded powertop, which is a utility that allows you to track and optimize software and hardware power usage.
Even Linus himself used this machine for quite long. He then moved on to a Chromebook Pixel. These days he seems to be using a Vaio.
Having emacs-like keybindings by default in all native text fields and text boxes (including this one) is a huge plus for OS X. In Linux, I had to write everything in emacs and copy/paste it into the field in question. Fine for emails, not so great for address bars, impossible for dmenu, etc.
Been using Slate as well but it's not maintained anymore. I wanted to switch to Phoenix - https://github.com/sdegutis/Phoenix/ which is from the same guy that this Hydra. I think the idea of Hydra was the rewrite it in Lua but I can't speak for him. Will definitely try it out asap!
Hydra is indeed my successor to Phoenix. Phoenix and Zephyros (and AppGrid if you can find it) are deprecated in favor of Hydra. But I can't just delete those projects, as existing users may not want to port their configs to Lua. Oh how I wish I could though.
No config, all shortcuts bound to Ctrl + Option + Command + arrows and a few others. They have an unlimited free trial, but pay for it if you really use it.
Project Author here: Thanks everyone for making Hydra bypass Zephyros as my most starred project! (Especially considering Zephyros is deprecated in favor of Hydra, and I can't really delete Zephyros since people might still be using it.)
For the "closed-source-but-non-programming-power-user" alternative to this, I'm a huge advocate of BetterTouchTool (http://www.boastr.net/). You can easily bind window snaps to everything from keypresses, to four-finger-sweeps on the trackpad, to dragging window titlebars to the screen corners. Also it's so much fun to infuriate friends when they try to use my trackpad and it moves windows all over the place.
I Quickly had a look on all the window manager alternatives mentioned here. Currently I use flexiglass, but I use it for one reason only. It allows me to move windows like in linux.
When holding Mouse button 1 + alt anywhere in the window I can move it. I really like this feature, I never use the titlebar to move windows.
Do any of the alternatives (or hydra it self) allow me to do this? I'd like to try them out. See if it has advantages over flexiglass.
The 1.1 milestone has plans for "mouse-moved" and "modifiers-changed" events that you can register for, which would let you create a feature very similar to this, where if you hold down option and move the mouse, it will move the window under the mouse with it. I'll file an issue to investigate if it's possible to register for "mouse-clicked" events and override them to be no-ops (so that you don't actually click into the window). That sounds like a fun feature :)
For me, the bigger idea to tiling wm, or these psuedo tiling wm is that I never have to use mouse to move/resize/shuffle windows. I too initially missed that feature when I first started using a tiling wm, but that quickly went away as soon as I had the keyboard shortcuts memorized.
Readit News
For instance on my imac 27'' I have Option+Command+Left|Right keys mapped to side (similar to windows 7.
And I can also have 4 windows open at once using Shift+Option+Command+Up|Down|Left|Right to move them to the different corners. Works really well with less than 2 minutes of setting the hotkey on a simple GUI configuration window.
http://alternativeto.net/software/spectacle/?platform=mac
For instance, typing 'layout left' in alfred will push the window the left side, topleft for the corner, etc.
https://github.com/fikovnik/ShiftIt
http://www.macupdate.com/app/mac/41147/spectacle
Edit to say: it would be really great to see some more complete code samples but I'm sure that'll come in time.
> Hydra must be stable. It should never crash
It's clearly better to have an app that never crashes than an equivalent one that crashes all the time.
However, making sure that your app is 100% crash-free isn't a zero cost thing. It takes time and effort to (often, a lot of both) to get to a completely crash-free app, meaning that the app either costs more, takes longer, or has to compromise on features - or possibly all three. In some case, that trade off is clearly going to be worth it - I'd rather a self-driving car took 10 years longer to develop than have one that rebooted itself twice a day, but in others I'm fine living with the occasional crash if it means cheaper or more feature-rich applications.
> Hydra must gracefully and rapidly restart should it crash w/o losing any user data.
And then maybe it could do this be serializing state into a sqlite or redis instance. We always to be careful of muddling the goal and the mechanism.
I personally think APIs exist to hide complexity. They should make sense, they should be usable, but they need not be transparent.
Let's have a rather contrived example. In SDL, you can call SDL_Init(). That does a lot of things, and what it does differs on windows, linux, and OSX. I absolutely don't want the more transparent API of SDL_Init_Windows_Video(), SDL_Init_Windows_Audio(), SDL_Init_Linux_Video() .... And so on. Realistically, for absolute transparency, you'd just do away with the API and write every line of code SDL currently hides (Reductio ad absurdum I know)
The entire point of having that one SDL_Init() call that's identical on all platforms, even though it does many opaque things underneath (and different things per platforms) is that it's easier to understand and use. The goal of an API is to be usable and useful, nothing else. Transparency can often get in the way of usability.
As for the "bloated" bit. Well, I'd rather be able to do too many things than too few. It's a great goal to have a purely orthogonal (no method may be accomplished with another combination of methods) API, but it should not be done at the expense of usability.
The entire quote makes it seem even more damning to me. Why would you cater to what's "likely to be used in everyone's configs"? That's another way of saying "Let's support only the least common denominator" which to me seems like a bad philosophy.This philosophy would lead to twitter not having a friendship API because the only thing practically every api user does is login and (arguably) tweet, only a few deal with friendships or account settings. It would lead to linux not having a configuration option for running more than one physical CPU or hotswapping ram because the wide majority of people will never use these options.
I'm happy that the author of this software decided to make it simple and it seems to be working here, but in the majority of cases of API design, I'd much rather the API be usable, not transparent, and large, not minimalistic. I'd rather be able to call a method that does some common activity for me which I could technically do myself in a 1000 lines of code than not have such a method because it's "bloat".
[1]: https://mizage.com/divvy/
[2]: http://spectacleapp.com/
[3]: http://manytricks.com/moom/
I'll also mention a feature I adore from FlexiGlass[1]: the ability to map <modifier>-<1/2/3 finger move> to move the window under the mouse. For example, I use <option>-<2 finger move> for this mapping. No mouse click & hold required, and the entire window is the "hit zone". FlexiGlass can also resize similarly, but I tend to just use my Moom bindings to snap windows where I want them.
I find this to be incredibly pleasant to use for window moves because it's a very immediate experience, more like arranging paper on your desk. Even better, the window being moved doesn't have to be in the frontmost application. This makes it even faster to move background windows. The usual window movement via titlebar or window snapping app requires the moved window be frontmost/focused, so there's a switching back and forth required. Between the giant, whole window, hit area and less focus switching, FlexiGlass' approach is a huge win IMO. I still feel a bit self-conscious about having this app installed for one feature, but it's really that good.
[1] http://nulana.com/flexiglass/
[1] https://github.com/ianyh/Amethyst
As for Linux, I realize that I'm personally in a place where leaving OSX would cause me no grief whatsoever. I catalogued everything I run on my Mac these days, and was pleasantly surprised to find I have zero local commercial software that I depend on, or indeed any Mac-only software. Generally, when I've used recent Linux desktops, I've discovered that the experience is at least on par with my Mac, with the added bonus that Emacs doesn't have so many quirks.
Battery life on my MacBook Air is really the only thing keeping me from moving back. I have to wonder if there is any movement to achieve power management parity with OSX in Linux.
Even Linus himself used this machine for quite long. He then moved on to a Chromebook Pixel. These days he seems to be using a Vaio.
[0] https://github.com/jigish/slate
No config, all shortcuts bound to Ctrl + Option + Command + arrows and a few others. They have an unlimited free trial, but pay for it if you really use it.
When holding Mouse button 1 + alt anywhere in the window I can move it. I really like this feature, I never use the titlebar to move windows.
Do any of the alternatives (or hydra it self) allow me to do this? I'd like to try them out. See if it has advantages over flexiglass.
You can use keypress + mouse movement:
http://imgur.com/ZeV8grb
...or just with the mouse alone:
http://imgur.com/JNXYf1q