ruby-wmii updated for use with wmii 3.6
It's been so long that many will not know what this is about. wmii is a lightweight, dynamic window manager for X11 that can be scripted with any language. It's not for everybody, but a few of us consider it way superior to the mainstream tools (I include all OSX has to offer here) in terms of workflow --- more on this below.
ruby-wmii is a wmii configuration and scripting system that controls the wmii WM. I had been procrastinating the long-needed update of ruby-wmii to make it work with recent versions of wmii under the excuse that wmii was a moving target and there hadn't been a stable release (not a development snapshot) for a long time. wmii 3.6 got finally released a couple weeks ago, which means that I was beginning to consider updating ruby-wmii some day, when Nathan Weizenbaum went ahead and ported it to 3.6. Big kudos go to him; who knows how long it would have taken me otherwise :)
I've migrated a few of my X sessions to 3.6 (dog-feeding means quicker bug correction), and the latest code can be found in the darcs repositories (that integrate Nathan's patches) at http://eigenclass.org/repos/ruby-wmii/head/ and http://eigenclass.org/repos/ruby-wmii/branch-ruby-ixp/
(The repositories with the 3.1 branches can be found here.)
Why you might like wmii
wmii supports very dynamic work patterns thanks to a few fundamental features that aren't AFAIK combined in any other WM (apart from dwm, modulo the lack of scriptability):
- wmii is a tiling WM; you don't have to worry about overlapping windows and their positions/sizes
- you rarely (if ever) need a mouse. All but a few actions can be bound to arbitrary keys, and you don't have to take your hands away from the keyboard.
- the column layout with split, maximized and stacked modes is close to ideal. The stacked mode (a sort of vertical tabbing) is superior to plain old tabs.
- a client can be in different workspaces (with different geometries) at a time
- arbitrarily complex behavior can be scripted in any language and associated to any keybinding or a number of events
- in general, wmii's tagging system allows you to manage the applications very dynamically.
The last point is hard to get across without a screencast (I'll try to prepare one... someday). The best way is probably to point at the problems faced with other tools and explain how they are addressed in wmii.
Multiple desktops/workspaces are by no means new; any respectable window manager has had them for years, and they're becoming more common now with Leopard's Spaces. They are typically used in a fairly static way: you have a "web" workspace, a "IM/IRC" one, another for consoles, etc. Within each workspace, non-tiling WMs force you to place the windows carefully.
Note: you might want to skip this: it's way too long. I'm sorry, I had no time to make it shorter today.
This screencast shows how Ara Howard manages one such workspace. It's not a bad setup, that's how I did things a few years ago when I used KDE; I just find my current approach better.
He's got an iTerm console with many tabs, each of them holding a number of virtual terminals multiplexed in a screen session. Note how a IM window (I assume, the screencast doesn't make it clear) is placed on the top right hand corner so that it doesn't overlap with the iTerm. Also note the Mail.app (?) window behind the iTerm. What's wrong in that image? A few possible problems (note that this is based on my understanding of how he works, by analogy with the way I used to operate with KDE):
- in a non-tiling WM, the WM and the iTerm have to be resized and positioned manually (non-overlapping IM and iTerm windows)
- you only see one tab (and within a tab, one terminal) at once. What if I want to see 2 at a time (and get rid of the IM window)? Do I have to detach the tabs and place+resize the resulting 2 windows manually so that they don't overlap? What about N=3..5 simultaneous terminals? Can I reattach them easily when I'm done and recover all the client geometries (so the IM is where it used to be, etc.)?
- What about things besides terminals? What if I want to see both a firefox window holding API documentation and the current tab at once (again, non-overlap is a requirement)?
- say you want to pair some terms with some apps while keeping the ability to switch amongst terms easily. For instance, you want a firefox window with the API for some lib shown when you're editing a given file and only then, so it doesn't steal valuable screen space when you go to the next tab. Imagine the latter holds a related file (from the same project) that does not use that lib and for which you hence don't require the API documentation. You still want to be able to switch from one terminal to another, but you only want to see firefox when you're looking at one of them.
How would I manage something like that with wmii? Basically, there's one tag per project (each tag defines a dynamic workspace), and a few semi-permanent tags (mail, web, irc), plus a number of dynamic tags that come and go.
Now comes the important part, each client can have several tags simultaneously, so a firefox window can be both in web (in maximized form) and in myproject (where it takes e.g. the right hand column) at once. In fact, I could have several tags associated to the same project, say myproject:N. For instance, myproject:1 could hold all the terms for the project in stacked form (so I can see each one in maximized form; it takes but one key-press to create a new column and move a terminal there so I can see two simultaneously). A subset of those terminals would be in myproject:2 (maybe in "split" mode, maybe in multiple columns; it takes one keypress to change the layout), along with a firefox window which is also tagged as "web" (so all firefox instances can be found in "web", but a few can be found in other tags as well), and maybe a IM that is also in the irc tag.
Imagine I'm reading my mail and find a bug report. I want to have that email visible at the same time as a number of terminals I was using to work on the affected project. In Ara's setup, Mail.app and iTerm overlap; you'd have to resize and move them so that they don't (and hide the IM window that isn't needed at that moment). With wmii, I'll just retag the mutt terminal as +myproject and have it appear in the associated workspace, along with the (stacked) terminals I was using.
I then get more urgent news via IRC --- a critical bug is to be fixed now --- and want to leave that workspace as is and have some other terminals from "myproject" visible at the same time as the IRC window. ruby-wmii has got key bindings that allow me to create a new associated tag (myproject:tmp) with a subset of the currently visible clients and move along tags easily. When I'm finished with the critical bug, a single key press makes myproject:tmp vanish and I'm back to myproject. All the clients have the geometries they did before I got sidetracked.
When I'm finished, I just retag the mutt window as -myproject; it's now in "mail", where it's been available all the time.
About the Ruby-IXP branch
branch-ruby-ixp uses Ruby-IXP to communicate with wmii instead of the wmiir command-line tool. It feels more reactive than head; unfortunately, there's a memleak in Ruby-IXP. This means that you have to reload wmiirc every 48H or so. It's not as bad as it sounds, though, as it can be done with a single keypress and it won't affect anything: the tags, the window geometries, etc. are preserved. In fact, it's so unobtrusive I'll probably automate it.
Does it work with native OSX apps? - Michael (2007-11-30 (Fri) 20:02:42)
Can wmii control native OS X apps such as Mail.app and the IM client used by Ara? Or does it only work for X11 apps such as xterm and xeyes?
mfp 2007-12-03 (Mon) 16:01:52
wmii is a WM for the X Window System, so it doesn't look like it'll be able to manage anything outside X11.app...
No Title - technomancy (2007-12-01 (Sat) 13:50:28)
Excellent! How's the multi-head support?
mfp 2007-12-03 (Mon) 16:07:33
I don't really know, as I don't need/use it myself. There were some talks about adding xinerama support last year, but AFAIK there's nothing of that in 3.6.
You might want to take a look at xmonad, ion or ratpoison.
woot - polypus (2007-12-02 (Sun) 06:49:02)
thanks for that!! been waiting for it.
mfp 2007-12-03 (Mon) 16:09:28
Thank Nathan Weizenbaum, I'm not lying when I say it could have taken months hadn't he done the port himself :)
Thanks - dgfitch (2007-12-04 (Tue) 09:12:17)
You two rock. I had gone minimal with dwm for a few months, but I think it's about time for some wmii scripting madness again.
memleak in Ruby-IXP - snk (suraj) (2007-12-04 (Tue) 23:49:02)
Is there really a memleak in Ruby-IXP (if so, which revision of SVN trunk) with wmii-3.6? Or are you thinking of the libixp overload bug[1] back in wmii-3.1?
[1] http://www.suckless.org/pipermail/wmii/2006-September/002706.html
dgfitch 2007-12-18 (Tue) 11:58:37
FWIW, I'm running Ruby-IXP with no leak. I've stripped quite a bit of the standard plugin functionality out in my setup, though, so my experience may not be universal.
mfp 2007-12-18 (Tue) 12:33:50
The Ruby-IXP included in ruby-wmii is old (rev 70). I'll try a recent version and see if I still get the memleak (it's not the overload bug, the last few times I attached gdb to wmiirc I found >10^5 empty arrays when mem usage was over 80-90MB).
Brilliant Work - Brad (2007-12-26 (Mit) 15:47:30)
I find it really hard to go back to a traditional WM after using WMII for about 1 year. I have been a bit worried that the Ruby-WMII would end up unsupported and die eventually. Thanks for the update!!
Every time I have to take control of my colleague's desktop which is littered with 15 to 20 overlapping windows I nearly go nuts. How did I ever work before? However for those that miss the gnome menus I created a plugin Ruby-WMII script to expose them through the wmenu interface.
http://xtargets.com/snippets/posts/show/67
mfp 2007-12-28 (Fri) 16:51:05
Good getaway drug ;-) When I started using wmii (in the first ~2 weeks or so), I wanted to keep KDE's kicker, but soon grew over it.
I feel that pain (15-20 overlapping windows) whenever I use OSX. All that eye candy and yet so little in the way of usability. I can easily manage ~40-50 windows distributed in 10 tags with wmii; exposé works pretty bad with a couple dozen...
Small bug - Micket (2007-12-26 (Wed) 19:11:44)
Hi, might i suggest you change grep in the cpuinfo in the standard plugin? changing from grep(/MHz/) to grep(/cpu MHz/) should do the trick. The problem is that some include the clockfrequency (at least mine do) model name : Intel(R) Pentium(R) M processor 1600MHz
mfp 2007-12-28 (Fri) 16:28:52
Thanks, committed.
How to install - phabulosa (2007-12-27 (Thr) 16:32:27)
I installed wmii3.6 on my Archlinux PC (Arch 64bits)
It feels great. I also was amazed by ruby-wmii and I went ahead to try by
darcs get http://eigenclass.org/repos/ruby-wmii/branch-ruby-ixp/ cd branch-ruby-ixp ruby install.rb
However, I was not able to open "xterm", neither launch any program by dmenu (Alt+p), BUT the built-in "actions" (alt+a) worked.
I checked the ~/.wmii-3.5/wmiirc.log. It gave me the following (BTW, I have not put ALSA on my system yet)
D, [2007-12-25T15:36:39.801699 #9261] DEBUG -- : Got "Key Mod1-Return\n"
sh: x-terminal-emulator: command not found
sh: amixer: command not found
D, [2007-12-25T15:36:42.329407 #9261] DEBUG -- : Got "Key Mod1-p\n"
D, [2007-12-25T15:36:44.265700 #9763] DEBUG -- : dmenu("firefox") finished
I, [2007-12-25T15:36:44.265976 #9261] INFO -- : Executing firefox
sh: ssid: command not found
D, [2007-12-25T15:36:44.327179 #9261] DEBUG -- : plugin/programs: history "firefox"
sh: amixer: command not found
sh: amixer: command not found
D, [2007-12-25T15:36:49.152900 #9261] DEBUG -- : Got "Key Mod1-p\n"
D, [2007-12-25T15:36: 50.801237 #9786] DEBUG -- : dmenu("xterm") finished
I, [2007-12-25T15:36:50.801497 #9261] INFO -- : Executing xterm
sh: ssid: command not found
D, [2007-12-25T15:36:50.864584 #9261] DEBUG -- : plugin/programs: history "xterm"
sh: amixer: command not found
D, [2007-12-25T15:36:53.880597 #9261] DEBUG -- : Got "Key Mod1-a\n"
sh: amixer: command not found
D, [2007-12-25T15:36:54.640965 #9804] DEBUG -- : dmenu("quit") finished
D, [2007-12-25T15:36:54.641275 #9261] DEBUG -- : plugin/actions: history ["quit"]
D, [2007-12-25T15:36:54.643053 #9261] DEBUG -- : Got "Bye\n"
Can someone explain to me what I have done wrong? Many thanks!
mfp 2007-12-28 (Fri) 16:39:46
First of all, you'll need ssid, which can be found at http://www.suckless.org/wiki/tools/other .
You can specify the terminal to use with something like
plugin_config["standard"]["x-terminal-emulator"] = "urxvt"
in ~/.wmii-3.5/wmiirc-config.rb.
As for the problems with amixer... well, the volume applet depends on it. It shouldn't be hard to adapt to another command-line mixer, though.
HTH
bug in WMII_IXP_Client breaks rename-view action - brettbender (2008-01-03 (Thr) 13:22:11)
At current tip of branch-ruby-ixp, the read() method of WMII_IXP_Client defined in wmiirc is simply:
def read(file); @connection.open(file){|f| f.read } end
which then breaks the "rename-view" internal action. "rename-view" assumes a read() method that will return a directory list, separated by newlines (if path is a directory) and file contents (otherwise).
ruby-ixp-svn/lib/wmii.rb has the method definition that works:
def read(file)
@cl.open(file) do |f|
if f.respond_to? :next
str = ''
while i = f.next
str << i.name << "\n"
end
str
else
f.read
end
end
rescue IXP::IXPException => e
puts "#{e.backtrace.first}: #{e}"
end
which can almost be pasted intact (you must rename @cl to @connection) into the definition of WMII_IXP_Client
mfp 2008-01-09 (Wed) 01:27:44
Thank you, I've committed it.
No Title - Anonymous (2008-01-10 (Thr) 07:00:55)
Thank you. I've been aching for this for a while. I use wmii-ruby extensively. I've been meaning to take a crack at upgrading it to 3.6 but haven't found the energy. Again ,thanks a lot. I'll try it out today.
solutions - rcorsaro (2008-01-16 (Wed) 10:51:06)
I had a couple problems that were easy to solve. I tried this on Slackware 12.0 with everything installed. I used wmii+ixp-20070516(i know it's old, but it was already installed. First problem I got was that x-terminal-emulator doesn't exist on Slackware. just add
plugin_config["standard"]["x-terminal-emulator"] = "rxvt"
to your ~/.wmii-3.5/wmii-config.rb(or whatever terminal you use). I think perhaps the script should check for x-terminal-emulator, and use xterm if it doesn't exist. It would be nice if it worked out of the box on all systems.
Second, I didn't have dmenu installed, so I went to suckless and get it. Now everythings working great. There are some bugs, but until I get the latest version of wmii, I'm not complaining :)
Also, for the dual monitor situation. I'm using two computers and synergy. I added this to my synergy.conf:
section: options keystroke(alt+shift+>) = switchInDirection(right) keystroke(alt+shift+<) = switchInDirection(left) end
now I don't need a mouse any more!! I think this would work with two x sessions on the same box, attached to different monitors, but I haven't tried it.
alt+N - dpc (2008-02-11 (Mon) 09:27:35)
In plain wmii I could press alt+N , where N was a number that was not yet created and N tag view was created instantly. I like that behaviour and wish to have in in ruby-wmii too.
Any advices? (Please send me CC: dawid.ciezarkiewicz@jabster.pl). Thanks in advance.
dpc 2008-02-11 (Mon) 10:58:15
Got it for myself. Donno if this behaviour isn't too tricky for standard use, but it's OK for me so I have best of both behaviours.
- {{{ Either move to the given numeric tag, if it exists, or to the-
# (N-last_numeric_tag)th non-numeric tag.
# e.g. views 1 3 4 mail web
# ALT-1 => 1
# ALT-3 => 3
# ALT-5 => mail
# ALT-6 => web
(0..9).each do |key|
binding("numeric-jump-#{key}", "MODKEY-#{key}") do |wmii,|
all_views = wmii.views
num_tags = all_views.grep(/^\d+$/)
nkey = (key - 1) % 10
if num_tags.include?(key.to_s)
wmii.view(key)
elsif nkey >= (prev_index = (num_tags.last || 0).to_i) and nkey < all_views.size
non_num_tags = all_views - num_tags
wmii.view non_num_tags[nkey - prev_index]
else
wmii.view(key)
end
end
end
{{comment}}Hiki::PluginException (not plugin method): inline plugin
alt-a and alt-d stopped working - Brad (2008-04-10 (Thr) 01:40:35)
Suddenly I think after logging out and logging back into my Ubuntu 7.10 box wmii started doing things a bit funny. First of all alt-a and alt-d no longer do anything. The other shortcuts for moving windows around still seem to work. ie alt-m still works but I can't then go back to default or stacked mode.
Second all my windows tags seem to be prepended with a colon.
":1 :web :dev :debug"
instead of
"1 web dev debug"
When retagging a window from :1 to :web instead it retags the window to ::web, that is with two colon characters prepended.
I have tried the latest head and IXP branches from darcs but the problem does not go away.
Regards
Brad
Extra info on problem - Brad (2008-04-10 (Thr) 01:47:46)
Have verified that
wmiir xwrite /tag/sel/ctl "colmode sel default"
and
wmiir xwrite /tag/sel/ctl "colmode sel stack"
works from the bash shell correctly so the wmii-3.6 core is still working. It must be my keybinding are getting swallowed or redefined somewhere. Any advice on where to look.
Also shift-alt-c to close a window does not work either and when I mentioned alt-a in my previous post I meant alt-s for stacked mode.
keyboard errors - brad (2008-04-10 (Thr) 02:28:07)
ok all, ignore my previous posts. Turned out to be a keyboard mapping error through Ubuntu and nothing to do with wmii.
Keyword(s):[blog] [ruby] [frontpage] [wmii] [ruby-wmii] [3.6]
References:[ruby-wmii FAQ] [ruby-wmii: Ruby configuration/scripting for the wmii window manager] [ruby-wmii community: plugins and configurations]