Let's Put A Cap On Shoes

Try out xmonad. Under 500 lines of haskell!

I was thinking of a weird solution to keep the code short (maybe?). The idea is to introduce “springs” in elements and between it’s adjacent elements. Based on a tension factor, the size and positioning of each element can be determined. Depending on their strength, they also determine which element or element-space grows/shrinks the most on resize. A tension limit on which spring break can also be added so that less-relevant items disappear in small displays. This is not my idea, but merely an adaptation or Knuth’s work on TeX (or how I think it works to produce that highly readable smooth text).

zimbatm <3

I always wanted that in HTML.

What nornagon said.

why, are there any things you would miss in dwm compared to wmii?

I understand your reasons for putting a cap on Shoes, and agree it’s a good idea. However, I’m worried that it might incline you (and other contributors) to use camping-style tricks to keep the source short. It’s fun for camping, and doesn’t really matter there, but isn’t it important to keep Shoes source readable, to make it easier for people to contribute?

The unabridged version of camping is readable, but it’s still a pain to keep track of the context (I find myself scrolling up and down a lot to remember what one one-letter variable did, while reading a different one-letter method).

Other than that, awesome! Looking forward to using Shoes when I have a use for it.

Can we fit trees and grids under that cap?

Give some breathing room; cap it at 12,345 lines.

zimbatm: Oh, clunk, I hadn’t thought to find inspiration in TeX.

Lucas: Shoes is written in C. That’s already one layer of obfuscation too many!!

jeem: You can emulate trees and grids by piling up stacks and flows. I guess I’m hoping someone will do it as a lib.

silby: And with 6,789 comments, I’m sure.

A cap goes on one end, and shoes goes on the other. I like the symmetry.

However, if you stop writing code when you hit 10k lines we’ll never be ready for the enterprise.

Oh, wait.

The only thing that got me back on wmii from dwm was the lack of a stacking window mode. That’s the feature that got me on wmii from ion, and I really couldn’t work comfortably without it.

One of the things I love about dwm is how well it works with fullscreen virtual machines. It leaves just its little bar across the top, so I can run a bunch of VMs fullscreen on different tags. I used to use stacking mode, too, on wmii-3, but it was really just a luxury. Giving each window its own tag is all I need really.

Well, I’ve become kind of addicted to being able to spawn a terminal with a single keystroke, do stuff in it, and close it again without interfering with any other windows. Or not close it. I ended up spending a lot more time thinking about my window layout, which is exactly what dwm and allies are intended to prevent.

So these days, it’s wmii, ion, or ratpoison. The edge for wmii is actually just because it plays more nicely with Cedega.

Speaking of dwm, though, I did end up writing a status bar controller for it, which is at least tangentially germane to hackety.org.

IronRuby is in alpha now, and the developers showed off a little demo of writing Ruby to make a simple windowed app:

http://weblogs.asp.net/scottgu/archive/2007/07/23/first-look-at-ironruby.aspx

I think it’d be neat to see a direct IronRuby/Shoes comparison, I bet Shoes would come out a lot more compact.

_why, I meant tree and grid controls, not layouts.

Oh my, dwm is amazing. I just installed it on a server at work, and I’m in love. This is going on my own machine asap!

That aside, I really like what you’re doing with Shoes. I remember being terrified of starting GUI programming. The world is in desperate need of a truly intuitive toolkit, and this seems to fit the bill nicely. Great work, as always :)

klondike: The tie-between for the API comes as a bi-product of their shared type system. It seems there are some specific restrictions or allowances, based on language (see the discussions over in python land), but really the GUI stuff has basically no existence on the ruby side, and is plain old .NET stuffs.

_why: Can any of the significant offenders be abstracted further, or maybe code generated?

@klondike: most of the work in that sample is done by the WPF engine. We’re also missing a lot of Ruby features in that version of IronRuby, so we’re limited in what we can do. To do things correctly, we need instance_eval, and we haven’t implemented that yet in our trunk …