<retroj> i just find it appalling that most software has this built in assumption that people will operate it by fishing
around on the screen for “virtual buttons”
…
<retroj> when there are 101 real buttons on virtually every computer that are easier to “fish around for”
….
<retroj> the mouse is not a bad input device. it’s only bad to use it as the *only* input device

So, how can we make more effecive use of these real buttons? The process is fairly simple.

Keyboard-Driven Text Editing

If you’re a programmer, you probably spend most of your day writing code. Since writing code is just editing text, it makes sense that the first place to start making better use of the keyboard is in the applications you spend most of your day in. The two most well known text editors of this type are vim and Emacs. I use Emacs, but use whatever you prefer. I recommend you give Emacs a try, though, as it’s very customizable. (You could run everything you need inside of Emacs and, in fact, you can run it directly on top of the Linux kernel. I don’t but there you are.)

Keyboard-Driven Web Browsing

The next major step is to find a keyboard-driven web browser that you like. You can, of course, use Emacs for this, but the browsers inside of Emacs itself offer no support for media like Flash. The two major alternatives are Vimperator and Conkeror. Vimperator is, obviously, written to be similar to vim and Conkeror is quite similar to Emacs. I’ve never used Vimperator so I can’t say how well it works, but many vimmers seem to like it. Conkeror is a Mozilla-based browser written in JavaScript. It’s fairly straight forward to customize and the community (in #conkeror on freenode), while small, is active and helpful and (dare I say it) fun!

Keyboard-Driven Window Management

This is a pretty major step. So far we’ve only changed two apps, but a keyboard-driven window manager will affect every app. The most popular window managers of this type appear to be tiling window managers, though they are not by any means the only ones, nor are all tiling window mangers keyboard-driven. I’ve been using StumpWM for a few weeks and have been very happy with the results. It’s written in Common Lisp which it uses for configuration. It’s pretty cool to be able to hack on your wm, re-eval, and go. It works very well with Emacs and Conkeror. By default it uses C-t as a prefix for management controls. Here are a couple of cool screenshots. There is also a great screencast (also on YouTube for the .ogg challenged).

Nearly?

Ok, so why did I say “nearly” mouse-less? Well, there are some things you still need to grab a mouse for. Some apps, like GIMP, aren’t really usable without a mouse. But that’s ok. The mouse is great. It’s just not the only input device.

First thing we need is the Air SDK. Go get it here.
Next we need to make a couple of directories.

# mkdir /opt/AIR-SDK
# mkdir /opt/AIR-APPS

Next unpack the SDK into /opt/AIR-SDK

# cd /opt/AIR-SDK
# tar jxf /path/to/AirSDK.tbz2

Now we need to get an app. I used TweetDeck. Download the .air file and unpack it in /opt/AIR-APPS/

# mkdir /opt/AIR-APPS/TweetDeck
# cd /opt/AIR-APPS/TweetDeck
# unzip /path/to/TweetDeck.air

Now the real fun begins.
You may want to read up on Gentoo Overlays if you’re not familiar with them. You’ll need to emerge layman and add the multilib overlay.

# emerge layman
# echo "source /usr/local/portage/layman/make.conf" >> /etc/make.conf
# layman -a multilib
# emerge --sync

There are several ways to proceed from here. You can add the 32bit libs you need to /etc/portage/package.use one by one adding the lib32 flag. You can find a list of them here.
As far as I can tell, you’ll need at least

sys-libs/ncurses
media-libs/alsa-lib
sys-libs/glibc
sys-libs/zlib
dev-libs/nss
dev-libs/openssl
dev-libs/nspr

This isn’t what I did so this list may be incomplete. If you find something I missed, please let me know and I’ll add it.
I found it simpler to add lib32 to my USE flags in /etc/make.conf and rebuild world. I also removed lib32 from
www-client/mozilla-firefox and net-libs/xulrunner to save a little time. You will also probably need to add

SETARCH_ARCH_x86=“i686”

to your make.conf

# emerge -avuDN world

This can take a long time depending on what you have installed. You also need to make sure that you have either kwallet or gnome-keyring running. At this point you should have a working Air Install. To run your new app

$ /opt/AIR-SDK/bin/adl -nodebug /opt/AIR-APPS/TweetDeck/META-INF/AIR/application.xml /opt/AIR-APPS/TweetDeck/

Replace TweetDeck with the name of your app. If you get a complaint about the Encrypted Storage, try removing ~/.appdata

$ rm -rf ~/.appdata

Hurray! You’ve got a working AIR installation!
If you’re not running Gnome or KDE you may have an error.

Unknown desktop manager, only Gnome and KDE are supported.

If you’re running XFCE you can try this

export GNOME_DESKTOP_SESSION_ID=”xfce”.

I hope this helps!

EDIT: I’ve sort of switched to StumpWM from KDE4. To use kwallet instead of gnomekeyring use the following.


export KDE_FULL_SESSION=1
export KDE_SESSION_VERSION=4


So what is so cool about Pylons? Well first off, it’s modular. If you are a Rails user, you’ll probably know that Rails 3 is going to become modular as well. This is very cool. It allows you to select the best project for a given task. In Pylons, this means you can use Mako, Jinja, or whatever else you want for a template engine. You can use SQLAlchemy, SQLObject, CouchDB, or nothing for your ORM. This is great and, in my humble opinion, the most logical way to work. Why bother reinventing the wheel, which you will end up making square, by the way, when you’ve already got a Ferrari? Granted, the Ferrari probably also has slightly square wheels but at least you didn’t have to make it. Pylons also suggests reasonable defaults (Mako and SQLAlchemy) if you’re overwhelmed by the options.

Pylons also has a feature that I haven’t really seen anywhere else, an Interactive Web Based Debugger. This means when your app blows up in development mode, you can instantly see the state of the objects in question, as well as examine the call stack at any point during program execution. Way cool!

I’ve not used Pylons for anything other than the toy apps in the tutorial examples, but I’m looking forward to learning more. I’m fully expecting run into crufty edges. Every framework has them. Pylons (and soon Rails 3) allows you to pick (hopefully) the least crufty thing for the job. I’ll be posting my impressions as I learn more about Pylons.

Charlene Li talks about this better than I have.