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.
For instance, typing 'layout left' in alfred will push the window the left side, topleft for the corner, etc.
Github repo: https://github.com/jgallen23/layouts
I personally find that I don't need anything more than what Spectacle gives me (splitting windows is really it). That said, I love me some Alfred workflows. Alfred is the single best software purchase I've ever made.
My alfred workflow library is incredibly sparse at the moment, so if you have any other good resources you'd like to share, that'd be great.
The one I use the most, by far, is "Plain Text Paste," which I use almost every time I paste anything (I use the hotkey CMD-SHIFT-V). It's here: http://cachefly.alfredapp.com/beta/Plain%20Text%20Paste.alfr...
The only other workflows I use regularly are hotkeys to open websites I visit regularly, like our own website and our WordPress log-in control panel.
I'd too would love to hear which workflows other HN readers use a lot.
I have a similar one to yours that creates a new plain text document from text on the clipboard.
My most often used one is Open current safari tab in chrome. I prefer using safari as I seem to get the best battery life using it. I don't have flash installed so any page that may have a flash component just gets opened in chrome using that Alfred workflow.
> 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
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.
My point was more that I don't think it's a sensible standard for all software. I hear this kind of thing quite regularly, usually by non-technical managers, often in a way that seems to suggest they think bugs are either the result of pure sloppiness, incompetence or downright malice.
10MB is a fairly ridiculous modern standard to limit yourself to, IMO (and I started on the C64 and generally do dislike and try to avoid bloat).
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.
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".
So no, you can't really compare those, I agree, but it was not me who brought in an arbitrary piece of software, but the parent comment.
I'll also mention a feature I adore from FlexiGlass: 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.
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.
With wireless on, while browsing the web, powertop shows around 5.2W. This is with a pretty bright screen. With reasonable usage, you can go well past 5 hours. Note this machine has a tiny battery in comparison to the 13 inch model.
I believe things could be even better (-0.5W) if I used another driver for the Broadcom wireless card (currently using the stock one in the kernel), as it doesn't support power management. Besides, on X11 the keyboard and the trackpad do not sleep properly.
Best hardware I've seen in this regard was a X220, and a Nokia N9. But the Mac is extremely good. If one cherry picks hardware for Linux like Apple does for OS X, the experience can be very good these days.
EDIT: I should add that I've only spent time in 10.9 on this MBA 11 2013 model. I've been told the battery life in 10.9 really is quite a lot better than in 10.8.
In the old (and not so old) times, laptops with horrid Linux power management would be extra warm due to all components being powered up all time. Far from it right now, if you cherry pick hardware. There's still room for improvement, 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.
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:
...or just with the mouse alone:
You do have to configure things and set them up a bit, but it can do SO much more than just window management.
Just throwing another option out there…For me, Keyboard Maestro is one of those must-have programs like Alfred or Hazel—totally changes how you do things.
The choice is absolutely brilliant. I love seeing so many open-source recommendations. I went for Spectacle in the end, but I'll definitely be keeping an eye on Hydra and seeing how it progresses.
But your comment made me realize it's just about ego—I'm definitely benefitting from this discussion and should admit as much!
1. That things work smoothly.
2. That things look pretty.
3. That it's easy to figure out what a program does when you first use it.
4. That it's possible to control the program efficiently, i.e., that you can quickly activate a program's different functions.
5. That a program is powerful, in that it enables you to customize it to work exactly as you need and automate it's use.
I've heard people claim Apple focuses on 1-3, I've never heard people say Apple focuses on 4 and 5. For windows placement in particular, Mac OS (as practically all window managers) has a method that covers 1-3: move and resize with the mouse.
This violates #3 for me.
Another one is minimizing a window and then Alt-Tabbing to it (whatever the Mac equivalent is..) doesn't bring that window back up.. You are just left staring at the same app.
This violates #1 for me.
As to your second point, that probably has the same cause. On OS X, you Cmd-Tab between applications, not between windows. Within an application, you can Cmd-Backtick between windows, but I don't think there's a navigatable collection of all windows across all applications.
I think 4 applies to an extent; MacOS has very good (albeit stolen from Emacs) universal text navigation shortcuts, for instance. Funnily enough, they used to be quite keen on 5, with Services and Applescript. Services are still around, but have faded into obscurity, with surprisingly few users even being aware they exist; to an extent, they may be replaced by action extensions.
Plus for the majority of average users they'll never need side by side windows anyway, that is a "power user" feature (like multiple desktops, or similar).
Is it possible to control the size (width and height) of the chrome debugger panel using the devtools api? I want to build a chrome extension that provides window management like Hydra or spectacle, but for the developer tools window. Building hot keys that could do things like send the console window exactly half screen in any direction or full screen, and also the same controls for the second console window. I spend a lot of time in the developer panel (as I'm sure many people do) and think a window manager could be a huge help. I read the api docs fairly thoroughly and also posted this same question to the google group and the stack overflow group with no response to either. Anyone out there know?
REPL is working for me now :-)
I have a couple of things I'd like:
- A [Divvy](http://mizage.com/divvy/)-style grid. When I used Divvy, this really made a dramatic difference in my window management
- Rich Spaces/Mission Control support. It'd be great to send windows to certain spaces, make spaces for windows, etc.
I'm excited to write a Hydra config for myself, it seems great!
Emphasis is on support for multiple screens, ease of use and snappiness. (which doesn't come across in my video I guess...)
I know my download page sucks, but if anyone wants to try and give me feedback, I'd be happy to read it. Send an email.
basically has most of my needs covered.
Capslock + E = Swap currently selected window to other desktop, make that window fullscreen and center the mouse cursor on it
But I have some issues I can't seem to resolve - I saved the sample config in the specified path (it should be correct since on reload the app says "Hydra sample config loaded"), but I can't open the repl (Hydra Error: "Attempt to call a nil value"). And using the Cmd+Ctrl+Alt+J doesn't make the window shorter, only moves it to the right (going out of the screen).
I am sure this is just a beta release hiccup.
link - https://github.com/sdegutis/dotfiles/blob/osx/home/.hydra/in...
Have you considered adding Lua calls for accessing and modifying window contents, selections, etc? OS X has a rich collection of APIs for doing this via Scripting Bridge and AXAccessibility.
What do you think? No voting system in github :(
To get the dictionary hot key and the other scripting abilities in Windows you would use AutoHotKey.
one thing that kind of bugs me is that when you reload the config file, if there's something wrong with it, it just loads the fallback config. i don't see any error messages, so its hard to figure out what i did wrong in the config.
I love your Zephyros and Phoenix projects. Keep working!
I really miss good tiling wm on MacOS X.
...sorry, just saw Winter Soldier this week.