[aklug] i3 and simplicity

From: Shane Spencer <shane@bogomip.com>
Date: Sat Mar 10 2012 - 13:17:30 AKST

Lately I find I've been falling deeply, madly, head over heals in love
with the i3 window manager.

Recently I've started installing base installs (no standard packages..
no anything) of Debian and immediately following a short document I
made that I should put online called "The Mad Mans Guide to Debian
Installation". Infact I should probably start throwing all of my
guides up on GitHub and get some public perspective. The short and
sweet of it is.. I disable installing recommended packages..
installing suggested packages.. and completely remove all unneeded
packages from my system by using debfoster to maintain a list of
packages I actually care about having installed.. which is a very very
short list right now. In the end this keeps me in the know on what
the prerequisites are for projects I'm working on so that I'm up to
date with what prerequisites developments I'm working on require.. the
gotchas behind them.. etc..

i3 fit into this mentality very easily. It supports Xorg RandR 1.2
which helps me easily add monitors dynamically as well as manage which
workspaces are on which monitors.

The way i3 handles multiple Xinerama or shared buffer displays differs
greatly from how the more popular window and workspace managers
operate. Previously in KDE, Gnome/Metacity, XFCE/XFWM and IceWM if
you had a shared buffer.. two physical screens for one logical display
where you can move windows between them.. you were unable to isolate a
set of workspaces to an individual monitor. You could add panels that
exist on a single monitor in a specific location but any windows you
have on any monitor are associated with a single workspace. Once you
switch from workspace 1 to workspace 2 your window set on every single
display is changed.

i3 solves this by managing monitors as individual workspace providers.
 When you initially load up i3 with multiple monitors you see that
workspace 1 exists on your primary and workspace 2 exists on your
secondary. If you open a new workspace on your primary nothing
happens on your secondary.. there is complete isolation.

In order to create a similar solution in other window managers you had
to turn off TwinView and Xinerama features and address each monitor as
an addressable video card in your xorg.conf. This completely disabled
the ability to move windows between screens however it allowed you to
say.. read documentation on your secondary monitor while writing code
on your primary.

Workspaces in i3 are named. By default they are string
representations of integers. I have a 'Pidgin' workspace that tries
to prioritize itself to the second monitor by adding a few very simple
lines in my i3 configuration file. Any process that matches the
window type associated with Pidgin ends up on that workspace no matter
what. Talk about appropriate isolation!

Workspaces are dynamically allocated. By default you start with one
per monitor. You open new workspaces by using your operator key (Meta
in my world) and a number between 1-9 and 0 for 10. i3 can be told
that workspaces 1-5 exist on DVI1 and workspaces 6-9,0 exist on VGA1.
If VGA1 isn't configured then all of them exist on DVI1. This allows
me to use xrandr to dynamically add a monitor to my laptop where any
workspace matching my configuration for VGA1 is immediately moved
over. This is amazingly useful for mobile computing as well as
storing a configuration you like to use for presentations.

i3 is a maximizing window manager. There are lots of hot keys. They
are easy to remember however and incredibly useful.

Take this scenario.. watching Hulu on my secondary display after
initializing the window on my primary. Open hulu.com on the primary
monitor and click on a video I want to watch .. but in popout mode.
The new window splits the screen in half for me and the video starts
up. It has focus. If I am on workspace 1 and I want that video to be
on workspace 10 I simply have to press Meta-Shift-0. Bam.. it's now
on the large monitor I have next to my laptop. No dragging.. no
futzing.. it's just there.

I3 also allows modal style windows that stay on top of maximized
content but don't retain a specific order on top of other modal
windows. This is good for temporary terminals so you can run qalc
real quick or test something, like I always do, in the Python command
line. I've mapped Ctrl-Grave to open up an RXVT-Unicode terminal.

Now keep in mind that I use RXVT-Unicode for all my terminals.. so how
did I tell i3 that this specific terminal was different and should by
default be treated like a modal window? I changed the logical X
client name for urxvt using it's supported command line parameter
called 'name'. Then in i3s config you can simply match a new window
to a preference for a specific styling, workspace, etc...

i3 also supports an IPC solution that allows you to execute i3
commands from your command line and scripts. This allows you to run
something like the following when you don't have a configuration set
up yet for an application you're testing.

  i3 workspace TheApplicationIAmTesting; ./applicationiamtesting;

This changes the workspace before running the application.

Anyways.. if anybody wants to try i3 out and finds they need a little
local support.. let me know!

- Shane
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Sat Mar 10 13:17:39 2012

This archive was generated by hypermail 2.1.8 : Sat Mar 10 2012 - 13:17:39 AKST