Wingo: A pure Go floating and tiling X window manager with per-monitor workspaces

[Andrew Gallant]

Project url: https://github.com/BurntSushi/wingo

It's go gettable:

go get github.com/BurntSushi/wingo

And an optional command line client to run commands:

go get github.com/BurntSushi/wingo/wingo-cmd

Wingo is intended to be a fully featured window manager. This
includes, but is not limited to: theming, hooks, IPC, per-monitor
workspaces (i.e., sensible multi head support), EWMH/ICCCM compliance
for the most part, key/mouse bindings, and automatic tiling when you
want it. To get the full scoop, see the README at the project URL.

Screenshots: https://github.com/BurntSushi/wingo/wiki/Screenshots

Since this is the Go mailing list, I'll talk a little bit about my
experience using Go to write a window manager.

Firstly, I've been trying to build a window manager in one form or
another for a few years now. I put a lot of work into trying to build
one in Python [1], but I quickly found the project to be unworkable as
the code base grew in size. (It will probably be the last time I
attempt a project of that size without static typing.) I desperately
did not want to write one in C. So in that sense, Go really fit the
bill well here. (And this isn't hard to imagine, given the popular
characterization of Go as "somewhere between C and Python".)

Secondly, Go's build system forced me into *not* being lazy and
building an infrastructure with recursive module imports. It sounds so
simple, but in a project of this size, it really came in handy.
Particularly since I ended up resolving such design problems with
interfaces, which I am *very* pleased with. (See focus, frame, heads,
layout, stack and workspace sub-packages.)

Thirdly, while Wingo itself does not do anything too fancy in the
concurrency area, Go made it dead simple to add the IPC feature where
Wingo commands can be executed over a socket. I think it took me less
than an hour to go from no IPC to a functioning client/server.

Fourthly, every Wingo command is defined via reflection on a struct.
(That is, the command name, its parameter list and types, and its
documentation.) This makes adding new commands an absolute pleasure.
The magic to do this is in a separate package called Gribble [2] that
has no ties to X or window managers.

Comments and criticisms are welcome. (I still have much to do, but
Wingo is in good enough shape for me to be using it on a day-to-day
basis.)

[1] - https://github.com/BurntSushi/pyndow
[2] - https://github.com/BurntSushi/gribble

- Andrew

[Don A. Bailey]

Excellent and congratulations! The screenshots look great. 

How about portability? Has your package been tested on multiple platforms? How easy is it to port to new platforms? 

Thanks,

D

- Andrew

--

--
Don A. Bailey

CEO/Founding Partner

Capitol Hill Consultants LLC

1-303-947-6557

[Andrew Gallant]

> Excellent and congratulations! The screenshots look great.

Thanks!

> How about portability? Has your package been tested on multiple platforms?
> How easy is it to port to new platforms?

It certainly won't work on anything that can't run X.

Off the top of my head, the only platform specific thing I used was a
unix domain socket for IPC stuff. But it isn't necessary for Wingo to
run.

I do know that my xgbutil/xgraphics package, which is used to paint
images to X pixmaps, has portability issues across different X server
configurations. It's currently hard-coded to work with (what I believe
to be) popular configurations. I think some folks who were working on
the Raspberry Pi ran into issues here.

- Andrew

[ajstarks]

sadly, I just tried a to build wingo on the 256MB Raspberry Pi, with the 240/16 RAM split and it failed when building .../wingo/bindata with signal 9.  I suspect it requires too much RAM.  I'll try again when my 512MB Raspberry Pi arrives.

[Job van der Zwan]

On Monday, 22 October 2012 14:21:44 UTC+2, ajstarks wrote:

sadly, I just tried a to build wingo on the 256MB Raspberry Pi, with the 240/16 RAM split and it failed when building .../wingo/bindata with signal 9.  I suspect it requires too much RAM.  I'll try again when my 512MB Raspberry Pi arrives.

It's a known issue:

> WARNING: In order to build Wingo, you'll need at least 2GB of RAM. See: https://github.com/BurntSushi/wingo/issues/8 

[Andrew Gallant]

> sadly, I just tried a to build wingo on the 256MB Raspberry Pi, with the
> 240/16 RAM split and it failed when building .../wingo/bindata with signal
> 9.  I suspect it requires too much RAM.  I'll try again when my 512MB
> Raspberry Pi arrives.

Indeed [1]. I'm working on removing the bindata requirement, which
made relying on resources really convenient. (bindata includes a font
and a few small images.)

Whether that will allow Wingo to build in 256MB or 512MB... I'm not
sure.

[1] - https://github.com/BurntSushi/wingo/issues/8

- Andrew

[Harley Laue]

I love the idea of this project. That said, it didn't like my virtual desktop grid. Maybe I'll give it another go when I have more time to actually play with it. I hope the project matures over time to become usable day-to-day on even my work machine.

[minux]

Thank you for you great project.

Now we can finally say we have a WM written in Go!

On Mon, Oct 22, 2012 at 10:08 PM, Andrew Gallant <jam...@gmail.com> wrote:

> sadly, I just tried a to build wingo on the 256MB Raspberry Pi, with the
> 240/16 RAM split and it failed when building .../wingo/bindata with signal
> 9.  I suspect it requires too much RAM.  I'll try again when my 512MB
> Raspberry Pi arrives.

Indeed [1]. I'm working on removing the bindata requirement, which
made relying on resources really convenient. (bindata includes a font
and a few small images.)

Whether that will allow Wingo to build in 256MB or 512MB... I'm not
sure.

I have proposed a solution for embedding binary data in Go program without

any high gc and ld memory usage.

see:

https://groups.google.com/forum/#!msg/golang-nuts/UOIUyn7uFsY/Uescy-cI7hQJ

you can add a Makefile to bindata directory to maintain these .syso files,

and check these .syso files in git for others users. Also note that it doesn't

master what architecture these .syso files are assembled for (the Go linker

can cross link object files for different architectures together, yeah, it's very

powerful in this regard).

[Andrew Gallant]

>  I love the idea of this project. That said, it didn't like my virtual
> desktop grid. Maybe I'll give it another go when I have more time to
> actually play with it. I hope the project matures over time to become
> usable day-to-day on even my work machine.

Are you using a single head? If so, there is hope for the future.
Wingo doesn't yet support grids specified by the pager, but it is
planned.

If you're on a multi-head setup though, pagers and panels with task
lists will behave a bit funky. (This is a result of a deliberate
design decision to have per-monitor workspaces.)

- Andrew

[Andrew Gallant]

> sadly, I just tried a to build wingo on the 256MB Raspberry Pi, with the
> 240/16 RAM split and it failed when building .../wingo/bindata with signal
> 9.  I suspect it requires too much RAM.  I'll try again when my 512MB
> Raspberry Pi arrives.

Thanks to minux's help, I've removed the insane memory requirement.
I'm using `syso` files to embed resources now.

From what I can tell, memory usage doesn't go above 200MB when
compiling.

However, I'm not sure that all of my X code will work on the Pi yet. I
recall some other folks trying it a few months ago and it failing. (My
xgbutil/xgraphics package isn't portable enough yet.)

- Andrew

[Harley Laue]

Multi-head, so that's unfortunate.

[Rory McGuire]

Love the per-monitor workspace idea, this will work great for when I'm trying to work and my kids want to watch

a movie. (Prevents the "Dad the movie has gone" when ever I change workspace.

[Alex]

Very nice. I installed it and like it very much. I managed to setup full environment in it in 5-10 minutes. Thanks for great work

[Harley Laue]

On 10/22/2012 12:39 PM, Andrew Gallant wrote:

It's indeed multi-head. That's unfortunate, as it screws up my current work flow. I'll give it a shot again at some point, but it's going to take a bit to get used to.