Wingo: floating and tiling window manager with per-monitor workspaces

Question

More screenshots.
Wingo has two features which, when combined, set it apart from other window managers (maybe):
1) Support for both floating and tiling placement policies. Wingo can be used as a regular floating (stacking) window manager, complete with decorations, maximization, sticky windows, and most other things you might find in a window manager. Wingo can also be switched into a tiling mode where window decorations disappear, and windows are automatically managed via tiling.
2) Workspaces per monitor. In a multi-head setup, each monitor can display its own workspace---independent of the other monitors. This makes changing your view of windows in multi-head setups much easier than in most other window managers, which will only allow you to see one workspace stretched across all of your monitors. Also, since placement policies like floating and tiling affect workspaces, this makes it possible for one monitor to be tiling while another is floating!
Inspiration
Wingo is heavily inspired by Openbox and Xmonad (and of course, pytyle). Basically, Openbox's floating semantics (although most window managers are the same in this regard) and Xmonad's automatic tiling style plus its workspace model (workspaces per monitor). I've also adopted Xmonad's "greedy" workspace switching and embedded the concepts from the "DynamicWorkspaces" contrib library into the Gribble command system.
Configuration
Wingo is extremely configurable. This includes binding any of a vast number of commands to key or mouse presses, theming your window decorations and setting up hooks that will fire depending upon a set of match conditions.
All configuration is done using an INI like file format with support for simple variable substitution (which makes theming a bit simpler). No XML. No recompiling. No scripting.
Configuring key/mouse bindings and hooks uses a central command system called Gribble. For example, one can add a workspace named "cromulent" with this command while Wingo is running:
AddWorkspace "cromulent"
But that's not very flexible, right? It'd be nice if you could specify the name of workspace on the fly... For this, simply use the "Input" command as an argument to AddWorkspace, which shows a graphical prompt and allows you to type in a name:
AddWorkspace (Input "Enter your workspace name:")
The text entered into the input box will be passed to the AddWorkspace command.
Please see the HOWTO-COMMANDS file for more info. We've barely scratched the surface.
Scripting Wingo
So I lied earlier. You can kind of script Wingo by using its IPC mechanism. While Wingo is running, you can send any command you like:
wingo-cmd 'AddWorkspace "embiggen"'
Or perhaps you can't remember how to use the AddWorkspace command:
wingo-cmd --usage AddWorkspace
Which will print the parameters, their types and a description of the command.
Want to pipe some information to another program? No problem, since commands can return stuff!
wingo-cmd GetWorkspace
And you can even make commands repeat themselves every X milliseconds, which is ideal for use with something like dzen to show the name of the currently active window:
wingo-cmd --poll 500 'GetClientName (GetActive)' | dzen2
Finally, you can see a list of all commands, their parameters and their usage: (even if Wingo isn't running)
wingo-cmd --list-usage
(Wingo actually can provide enough information (or will soon) for ambitious hackers to script their own layouts in whatever programming language they like without ever having to deal with X at all. Assuming it has support for connecting to unix domain sockets. Or you could just use a shell with 'wingo-cmd' if you're into that kind of tomfoolery.)
Dynamic Workspaces
Having some set number of workspaces labeled 1, 2, 3, 4, ... is a thing of the past. While Wingo won't stop you from using such a simplistic model, it will egg you on to try something else: dynamic workspaces.
Dynamic workspaces takes advantage of two things: workspace names and adding/removing workspaces as you need them.
This is something that I find useful since I'm typically working on multiple projects, and my needs change as I work on them. For example, when working on Wingo, I might add the "wingo" workspace, along with the "xephyr" workspace and the "gribble" workspace. When I'm done, I can remove those and add other workspaces for my next project. Or I can leave those workspaces intact for when I come back to them later.
With Wingo, such a workflow is natural because you're no longer confined to "removing only the last workspace" or some other such nonsense. Plus, adding a workspace requires that you name it---so workspaces always carry some semantic meaning.
(N.B. I don't mean to imply that this model is new, just uncommon; particularly among floating window managers. I've personally taken the model from xmonad-contrib's DynamicWorkspaces module.)
Tiling layouts
Right now, only simple tiling layouts are available. (Vertical and Horizontal.) Mostly because those are the layouts that I primarily use. I'll be adding more as they are demanded.
Dependencies
Wingo is written in pure Go (including all of its dependencies). As such, Go (and git) is the only package necessary to build and install Wingo. Once Wingo is installed, Go can be removed. (No Xlib/xcb, no cairo, no gui toolkits.)
Installation
Wingo is in the AUR. Alternatively, if you have a Go environment set up, you can download, build and install Wingo and all of its necessary dependencies with:
go get github.com/BurntSushi/wingo
go get github.com/BurntSushi/wingo/wingo-cmd
(Yes, Go's build system is really that awesome.)
There's a lot more at Wingo's github.
Please note that Wingo should be considered in a very alpha state. I've been using it for a little bit myself, but beyond that, Wingo is untested.
Last edited by BurntSushi (2012-10-22 06:02:16)

Answer 1

netfun81 wrote:wow, nice wm.  Install was a breeze, love having floating layout on one screen and tiling on another.   In the past, for certain apps that wouldn't play well with a tiling wm, I would have to kill X, change my .xinitrc to start openbox and startx again.   This seems like the perfect solution.
Thanks :-)
netfun81 wrote:Does "go get github.com/BurntSushi/wingo"  always pull the latest from git?   Can i just delete the wingo executable from go/bin and run command to upgrade to latest or do I need to delete config files each time to remain compatible?
Yes, `go get ...` always pulls from the latest git. I make sure that Wingo builds before pushing to `master`. I'll use a different branch for any longer term experiments.
You could use `wingo-git` in the AUR, but `go get` is just as good. (Indeed, the PKGBUILD uses `go get`!)
One note those, use this to update to instead:
go get -u github.com/BurntSushi/wingo
go get -u github.com/BurntSushi/wingo/wingo-cmd
You shouldn't have to delete any executables.
As far as configuration files go... I'm not sure. I haven't figured out how I'm going to handle them yet. I don't think any well-formed configuration file will break Wingo, but it's certainly possible that old configuration files will miss out on new features/options. (For example, I just added some new focus follows mouse options.) Wingo will always maintain an in-memory default configuration, so missing configuration options will also never break Wingo.
You can always check out the new configuration files by running `wingo --write-config`. You'll have to move `~/.config/wingo` to a temporary location first though.
If you're installing from the AUR, I'll try to add post installation messages for any big changes.
FYI, I should say that installation is so easy because of Go. :-) /plug
Last edited by BurntSushi (2012-10-26 21:07:44)