For some time now I’ve used openbox as my WM of choice (I worked it out the other day, it’s about a year since I migrated) and apart from needing to add one feature, it meets my needs pretty perfectly.
One thing I did learn during the epic OSX wager though, was that divvy is a cool idea. Having the idea to quickly snap windows to segmented regions of your display can be a boon for people sitting between the floating and tiling models. I did feel that the Divvy implementation was a bit clumsy though, which meant I should…..
This creates a set of bindings rooted off a modifier key (I used Windows+Escape because it’s a natural shape for my hands but far away from something I can hit by accident) and then used the nethack vi bindings because they’re drilled deep into my brain.
You’ll also see the `Warp` action attached to all of them.. if you’re not running my fork (which is still unmerged upstream, my fault) you’ll want to remove them unless you want to hear openbox be /very/ noisy about it.
From this you can do `W-Esc l` to place the current window on the right 50% of your screeen, `W-Esc y` for the top left, etc.
I think implemented modifiers, Shift for 66% and Ctrl for 34% for balanced splits. Tiling window managers (and even tmux, via the `next-layout` and `previous-layout` commands) support these, but I still need floating window support for the most part.
Anyone who’s spoken to me in person knows that I’m really excited about the upcoming release of Raspberry PI.
I’ll keep the speil to a minimum, but a $35 ARM SoC with ethernet, USB and enough hardware onboard to decode 1080p video on 1 watt.. you can see why I’m pretty stoked.
Recently, there was a call for mirrors and psych0tik raised our hands, we’re mirroring any and all content (presently, debian 6 iso’s) needed to get your pi up and running, though unfortunately only for those of you with ipv6 access at this stage.
First of all, this workflow depends entirely on an (rarely un)spoken rule in my repositories- if it’s in the wip/ or trash/ tree, don’t touch it. I’m planning on rebasing with impunity.
I stash a lot at work, especially when I shouldn’t.
Generally, stashing occurs when I’m working on something that’s not ready for production or even feature complete enough to warrant publishing, and I need to rebase or start on something else. Nearly always I stash it and forget about it (even though my prompt yells at me when I have stashes)
The alternative is to check it into a wip/ or trash/ branch (depending on how confident I feel about the change in question being a Good Idea). This is useful for a stack of reasons:
It preserves some history about the idea (what else I was doing at the same time)
It makes tracking what you’re doing a lot simpler (because the stash stack is a pain at the best of times)
Most importantly, you can keep branching
The last one is the most relevant, a stash isn’t rooted to any particular point on the tree which means if you make an invasive change you’re going to struggle (which is a pain when the patch in question alters some core behaviour and was only barely working to start with)
If I know it’s going to be a problem that I take a lot of stabs at I’ll generally make it a branch like wip/ideas/short_description_of_approach for simplicity to begin with; and this will only get better in git 1.7.9 which adds a description attribute for branches.
Stashes are awesome for getting a clean tree so you can rebase or do some non-trivial merging, but for keeping ideas straight it’s a pain; to the point where I’m considering a hook to delete my stashes after a week so that I can just be rid of them.
I have to do this way more often than I’d like, my home directory lives in svn, and my svn config comprises part of my home directory. The upshot is that subversion likes to make blank data if none already exists, and then falls in a heap if the path it’s trying to create is already there.
This gets worse if you already have config you like and goes totally sideways if you actually depend upon some of it to get a clean checkout.
The solutions isn’t complex- but isn’t obvious either. Most solutions I’ve seen involved invoking svn, then trying to throw it in the background after it creates metadata but BEFORE it begins creating files, and then nuke the files. Kludgy at best- I much prefer this approach.
mv .subversion _subversion
svn --config-dir _subversion up
echo "You must now merge _subversion into .subversion"