Planet awesome

That's just something I hear from time to time, and I love it so much.

Fluxbox: 65010 SLOC

Metacity: 62923 SLOC

Openbox: 36336 SLOC

awesome: 19207 SLOC

I've started to develop awesome more than 18 months ago, and somehow I feel it's time to stop a bit and think where we come from and where we are going to.

The motivation

I never though I'd be written a window manager one day. That seems kinda stupid when you see how many window manager there's around.

As many people, I've tested and have been using tons of window manager: Window Maker, Fluxbox, etc.

In August 2007, I was using fvwm since 2004 and was quite happy with it. I used the famous fvwm crystal as a configuration starter and then rewrote lots of stuff. Digging into fvwm configuration files was boring, and since I'm lazy, I never really configured it to fit entirely my needs.

The thing is that, in July 2007, my workstation died. I bought a new one based on the amd64 architecture. Too bad, with this new box, fvwm decided that it will not longer runs and was segfaulting almost every time I logged in.

I was really upset. Another failure in the window manager world. So I decided to get the yearly ride of testing many window managers. I went on the no more developed stuff like the *boxes, ion3, etc… but well, I did not like them, there were not powerful enough, too bugged or upstream was insane.

Then I found xmonad. The Haskell configuration file format made my cry. I did not want to learn Haskell, it seemed too obfuscated to me. At that time it was even not packaged for Debian, so I gave up. But I found dwm in the meantime, and I loved it. It was simple, and the source code was almost understandable and easy to hack.

I subscribed to the dwm mailing-list, in order to participate to its development, etc… But I got really disappointed. No patch were welcome and the development seemed to be almost finish in this sight. People patches were lying around, but no one really care. Each user was managing its own set of patches.

That's not what I learnt and what I love in free software. So, as many users, I began to maintain my patches in my corner. But I began to have more ideas…

The jdwm

I just added a 'j' in front of dwm and started to hack it days and nights to add many feature I missed, like multi-head, etc… On 5th September 2007, I created a git repository to host my code.

That's gonna be… awesome.

Five days later, on 10th September, I finally found a name for my new pet: awesome, borrowed from Barney Stinson who heavily uses and abuses this word.

The 1.x branch

The first releases until December were noted 1.x. It was just a better dwm with a simple flat configuration file.. The configuration file used libconfig, but it was a very poor choice. And I was not able to put in into Debian because of name clash.

The 2.x branch

The 2.x branch came in January 2008 with a brand new configuration file format based on libconfuse, which was a bit more powerful. Many concepts and features that have been added in this branch are still used in the current 3.x branch.

At this time, between December 2007 and April 2008, the community was growing smoothly.

But as I said, awesome 2 was based on a flat configuration file. That raised a problem very soon: users expectation were growing and the development team (me and a couple of regular contributors) was unable to cope with them.

One of the event that started to change my mind was the support for titlebars.

When I've added titlebar support, it was minimal. It was on top of a window, with the window title. Dot. Then I've started to add a lot of options, like the application icon drawing, the position (left, right, bottom) etc.

And then users started to ask for more, like: "add titlebar on windows only when the window is floating".

That's ok, but that's complicated: that's again another option to do some stuff conditionally. And then, why don't add titlebar on windows when <insert random events here>?

The 3.x branch

Why

At that time, around April 2008, I'd totally stopped development. I was trying to find a solution which was simple and powerful. But after 2 weeks of thinking, I was not able to find anything else than: use a real language for configuration.

So, I've started prototyping awesome 3 using Lua. The choice was not obvious, and despite the problem Lua might suffer, it's one of the easiest language to integrate into an existing application. There's still a video of a first version here.

But, let's go a little back: in January 2008, Arnaud Fontaine contacted me because he was interested to use awesome as one of its school project. He decided to port awesome from Xlib to XCB, a modern asynchronous X library.

His work took some time, but in May 2008, Arnaud did finished to port git master version of awesome to use XCB.

Consequently, I decided to start a new major branch, using XCB instead of Xlib (no change for users in this regard) and Lua instead of our previous flat configuration file format.

Development

It took me a while to get from here to there, but in September 2008, it was ready. We had a simple Lua API, and the XCB port was working perfectly.

It took us some time to release and have something totally working, because we had to work on XCB and contribute back to the project. It was really not ready to use by an application, but we did great work in this area and it's now really fine.

We're still here

Releases continue to happens, 3.1 around December 2008, and 3.2 around March 2009. 3.3 should be here in June.

One of the drawback we had, is that we moved many stuff from C to Lua. Why? Because writing things in Lua is quicker and easier to maintain than C, and makes thing more configurable for the user.

For example, the layout algorithm used to organize window were written in C until 3.2 came out. At that time, users had no choice than using a set of predefined layout to organize their windows.

Starting with 3.2, if they have minimal knowledge about geometry, they can start writing a layout function organising windows on the screen.

But this kind of API changes was a bit rough for users, since they had to port some part of their configuration file to the new API. The thing is that the project was still a teenager at that time, not really knowing were it will go. But I'm happy to announce that API breakage are more and more rare (so far only one minor between 3.2 and 3.3), and anyway always for the Good.

But I admit that it built a bad reputation around awesome 3.x during its first month of existence.

Future direction

I am currently working on 3.3 development. We have still many things to do. Time passing, we get more idea, and more users. And more users bring more ideas. We also have many more contributors, and some guys are even taking maintainer-ship of some code area.

Conclusion

My post title is "Taking the other direction" because I feel this way.

I've got that feeling that some approaches in projects like GNOME are sometimes bad. Please don't misread me, I know we are not playing in the same yard.

When adding a key shortcut for starting an application makes you dig into gconf, I wonder how this is a win for the user.

Well, it's probably a win for the end-user, but I surely am not one of them. And I don't intend to target them with my software, anyway.

And now, when I hear things like GNOME 3.0 and the "desktop shell" approach, that makes me smile. Guys, it was time, but have luck. What I see from here, is that any desktop control interface is wrong somehow, and that there's no approach that can fulfill all users wishes.

I think that we, the awesome development team (no pun intended) took the direction of building a frame-work window manager rather than a solution written in marble.

We (partially) solved the issue of UI ergonomic by not writing one and allowing the user to write his own. I don't say that's easy to do for most of users, but it's doable.

And I think it's worth it: I use window managers since I use Linux, around 1998. If something like awesome came 5 years ago, I'd be using it so far, because you can write Fluxbox or WindowMaker using awesome in a hundred of Lua code. And you can write your own version of it. And it starts in less than 3 seconds, supporting almost all standard desktop specification (ICCCM, EWMH, XDG, system tray, message notification, D-Bus, etc), whereas many of the window mangers do not.

You can even write and play space invaders.

Finally, I'm happy about the the road we took so far, and hope we will continue into that direction. The rants I read about our project are not that big, compared to the kudos we received.

Well, I'm not dead buddies. I was overbooked.

Last weeks have been a bit busy for me. I've also been on holidays, so I gave up on computers stuff a bit.

awesome

Big news: awesome 3.2 has been released some weeks ago, and seems to be a success so far. We're working on the new 3.3 release, which will have some new sexy feature you'll love. More on that later.

Debian

I've uploaded a new awesome-extra package with third party modules such as shifty or wicked.

startup-notification

I just managed to be added in the startup-notification group at Freedesktop. I moved the CVS repository to git and merged my set of XCB patches.

I've just released sysrqd 10. I've rewritten big chunks of code, mostly because my C skills have quite improved between now and 4 years ago, and because I've blindly merged contributors patches which were crap.

Since several month, awesome users have reported a bug with OpenOffice.org. When using OOo and clicking on a menu, or using the mouse wheel to read a document, the currently selected tag (desktop) will change automagically to another one.

I've digged into awesome and found that awesome received a _NET_CURRENT_DESKTOP request. As defined by EWMH, this kind of request are sent by a pager to change the active desktop.

That was weird. Nobody is using a pager here. So, I just kicked my gdb out, attached it to OOo, breaking on XSendEvent call. And I got it:

Breakpoint 1, XSendEvent (dpy=0x1a00080, w=483, propagate=0, event_mask=1572864, event=0x7fff1fd70d70)
   at ../../src/SendEvent.c:46
(gdb) bt
#0  XSendEvent (dpy=0x1a00080, w=483, propagate=0, event_mask=1572864, event=0x7fff1fd70d70)
   at ../../src/SendEvent.c:46
#1  0x00007f8c0ab4193f in vcl_sal::WMAdaptor::switchToWorkArea ()
  from /usr/lib/openoffice/basis3.0/program/libvclplug_genlx.so
#2  0x00007f8c0aafdbd8 in X11SalFrame::Show ()
  from /usr/lib/openoffice/basis3.0/program/libvclplug_genlx.so
#3  0x00007f8c1378623c in Window::Show ()
  from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#4  0x00007f8c13785f40 in Window::Show ()
  from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#5  0x00007f8c1372cb54 in FloatingWindow::StartPopupMode ()
  from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#6  0x00007f8c1373c877 in ?? () from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#7  0x00007f8c1373ccf2 in ?? () from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#8  0x00007f8c1373ce84 in ?? () from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#9  0x00007f8c13795e7f in ?? () from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#10 0x00007f8c13797e74 in ?? () from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#11 0x00007f8c13796748 in ?? () from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#12 0x00007f8c0aafe6f8 in X11SalFrame::HandleMouseEvent ()
  from /usr/lib/openoffice/basis3.0/program/libvclplug_genlx.so
#13 0x00007f8c0ab040c2 in X11SalFrame::Dispatch ()
  from /usr/lib/openoffice/basis3.0/program/libvclplug_genlx.so
#14 0x00007f8c0ab31625 in SalX11Display::Yield ()
  from /usr/lib/openoffice/basis3.0/program/libvclplug_genlx.so
#15 0x00007f8c0ab356f3 in ?? () from /usr/lib/openoffice/basis3.0/program/libvclplug_genlx.so
#16 0x00007f8c0ab2df1f in SalXLib::Yield () from /usr/lib/openoffice/basis3.0/program/libvclplug_genlx.so
#17 0x00007f8c135b050e in Application::Yield ()
  from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#18 0x00007f8c135b0587 in Application::Execute ()
  from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#19 0x00007f8c17517e80 in ?? () from /usr/lib/openoffice/program/../basis-link/program/libsofficeapp.so
#20 0x00007f8c135b4b24 in ?? () from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#21 0x00007f8c135b4bc5 in SVMain () from /usr/lib/openoffice/program/../basis-link/program/libvcllx.so
#22 0x00007f8c1754ca6c in soffice_main ()
  from /usr/lib/openoffice/program/../basis-link/program/libsofficeapp.so
#23 0x000000000040105b in main ()

I started digging more into the code, and this is what I finally found in salframe.cxx:

       // #i45160# switch to desktop where a dialog with parent will appear 
       if( mpParent && mpParent->m_nWorkArea != m_nWorkArea ) 
           GetDisplay()->getWMAdaptor()->switchToWorkArea( mpParent->m_nWorkArea );

Beautiful! It even has a comment with a IssueZilla bug number. Let's go and see where it comes from.

After 10 minutes of research to find that fucking IZ, I finally found the link to the issue #45160. The bug is IMHO not related to OOo but to a window manager doing poor job.

I've found that an awesome user already reported an bug… err, wait, I mean an issue as issue #96684 (remember there's no bug in OOo, only issues) and I commented about it.

UPDATE: It seems OOo developers have agreed to fix that bug eventually.

We're working since several month on awesome 3.2, and here is what you'll get soon:

• By wibox X cursor;
• New mousegrabber infrastructure;
• Client move with mouse is now in Lua;
• New D-Bus hooks; you can also watch D-Bus events to get information like the song played in Audacious, or things like that;
• naughty (notification library) now supports notification via D-Bus, following standard notification protocol;
• Layout code moved to Lua;
• Client gets a new mouse_leave hook;
• Floating state is now handled on Lua side;
• Windows groups are handled and exported to Lua API;
• Various awesome markups have been removed in favor of widgets properties (simpler);
• Shadow support has been removed (too buggy);
• Add new telak module (draw image from the Web on your root window);
• Add mouse move code for wiboxes;
• Add functions to move clients with mouse to tags via the taglist;
• Add support for key release events in keybindings;
• Add support for input faking into client via XTest extension;
• Add support for X selection retrieval (clipboard);
• Add support for real transparency attribute on wiboxes;
• Replace tile layout by a new layout (originally called 'vile') which supports resizing of slaves clients.

We've done a nice job. Thanks to all contributors! See you soon for the first release candidate version…

Since Tuesday, I've begun to work on XCB portage of the startup-notification library.

I've just completed the job, and send a bunch of patches to the XDG mailing list. My work is available in my startup-notification git repository.

If the patches are merged, which I don't doubt, I'll be able to use this lib into awesome, which would be nice step to the Freedesktop standard compliance I like to make.

You feel old?

You are not.

You may just be one aged enough geek that have a good overview of the IT world. So you see that this are only trends and fashion tech.

Technologies qualified by some as "old" are in fact still the more robust and efficient ones for people mastering them.

Why do you think there still many people not using things like KDE or GNOME, using Emacs or vi instead of Eclipse?

You're the one who knows how to make a quick'n dirty tunnel with ssh and ppp. They're the ones lost with the latest release of Checkpoint.

This is one of the most stupid test I ever encountered. It seems this sort of things happens when you have no clue about the technology you are talking about.

Just imagine the famous Road Runner. This benchmark is about measuring how fast is the animal below:

Yeah, indeed, this is not a Road Runner.

I've started using Lua some months ago, while looking for a more powerful way to configure awesome. At this time, around March 2008, Lua seemed to be the best language to integrate inside the core system of awesome.

I still think that Lua was a good choice, but after 8 months, it shows some important drawbacks.

I'll try to keep my explanation simple and to make you understand everything, even if you do not know Lua.

I refer here to Lua 5.1

Design flaws

Length operator

Lua has a length operator on its objects, known as #. It can be used to get the size of various objects.

return #"lol" 3

This operator works for table, string, etc… It's possible to define this operator by setting a __len meta-method on a userdata value.

The problem is that you cannot redefine it on string or table objects, see:

> a = { "hello", "world" }
> return #a
2
> setmetatable(a, { __len = function () return 18 end })
> return #a
2

Indeed, looking at the Lua core code:

     case OP_LEN: { 
       const TValue *rb = RB(i); 
       switch (ttype(rb)) { 
         case LUA_TTABLE: { 
           setnvalue(ra, cast_num(luaH_getn(hvalue(rb)))); 
           break; 
         }   
         case LUA_TSTRING: { 
           setnvalue(ra, cast_num(tsvalue(rb)->len)); 
           break; 
         }   
         default: {  /* try metamethod */ 
           Protect( 
             if (!call_binTM(L, rb, luaO_nilobject, ra, TM_LEN)) 
               luaG_typeerror(L, rb, "get length of"); 
           )   
         }   
       }   
       continue; 
     }

You clearly see that tables and strings always use the internal length operator, never the __len meta-method.

That's for me a design problem, which will cause more trouble. We'll see later.

__index and __newindex metamethods

Lua defines two useful metamethods, which are __index and __newindex. Both can be set on a table or any other object. __index will be called upon each read access to an undefined key on an object, and __newindex upon each write access.

Example

> a = {}
> setmetatable(a, { __index = myindexfunction, __newindex = mynewindexfunction }) -- function are not defined, this is just an example
> a[1] = "hello" -- This will call __newindex metamethod
> return a[2] -- This will call __index metamethods
> return a[1] -- This will NOT call __index

The last line does not call __index meta-method because a[1] does exists. This is a problem when you want to use table as object, because sometimes you want to monitor access to the table elements.

This can be easily worked around using a proxy system: you don't store things in the table you manipulate, but in another table.

> a = {}
> realtable = {}
> setmetatable(a, { __index = myindexfunction, __newindex = mynewindexfunction }) -- function are not defined, this is just an example

Where meta-methods are something like:

function myindexfunction(table, key)
   return realtable[key]
end

function mynewindexfunction(table, key, value)
   realtable[key] = value
end

This way, our a table will always be empty, and realtable will have the data. At every read or write access to a, the meta-methods will be called. This is very convenient and widely used hack.

But this has serious drawbacks: as we saw before, the length operator (#) cannot be redefined on a table. That means #a will always be 0, and you cannot get the table length anymore, except by defining another method or a special attribute.

Also, Lua has several functions in the table library that are used to manipulate table in a easy way. The problem is that standard functions like table.insert or table.remove do raw accesses to the table. Meaning that if you do table.insert(a, 1, 1) it will insert the value 1 at the key 1 into a, without calling the __newindex meta-methods, breaking all your beautiful object-oriented model.

Another solution is to use a userdata object, like done in the Lua newproxy function (which is under-documented).

The problem is that it breaks all the other functions that are waiting for a table as argument, because they see a userdata, not a table. So this time table.insert is now more usable, which somehow fixes the problem, but not in the right way IMHO. However, this allows to use the __len meta-method.

Development model

The development model of Lua is, from my point of view, non-existent.

There is no public version control system repository available, so there's no chance to really contribute to Lua. It seems only a defined set of people work on it and therefore, the development system is very closed to my eyes, in comparison of usual projects.

Conclusion

I still think Lua is a good choice, because it is very easy to integrate into any C program, and to expand to fulfill your needs. However, some bad design choices were made, and the poor and closed development model chosen does not allow to have a good overview of the future of Lua.

This has been well stated by the authors themselves.

… is a no.

It just does not work. I mean, it does work if you want to listen to music using mplayer in 8 KHz quality, but don't even think to use it to phone using SIP.

I've first tested with bluez 3 which is part of Debian. It roughly work, but sometimes it stops working and you have to restart hcid, or to clean its cache. Not very stable.

I've then tried using bluez 4, compiled from scratch. It works much better, i.e. I can run mplayer a thousand of times without having it stopping to work, but I'm totally unable to use it with twinkle or ekiga.

And I don't even talk about ekiga still unable to set a custom ALSA output. I even try to hack it via gconf-editor!

That's really a shame.

Some years ago I wrote a little tool called telak in order to display remote images on my wallpaper and have them updated regularly.

Yesterday, as a challenge, I rewrote this as an awesome module, in Lua using wget. I simply used a wibox and a widget from awesome API to display the images.

It's called telak, as the original, and is in the awesome next git branch, which will be the 3.2 version of my favorite window manager.

Now you need to register to install addons from addons.mozilla.org. For god's sake, what's the point of such a thing, except annoying people.

Mozilla you suck: your softwares suck, your ideas suck. You'll really gonna get out of my computer ASAP.

Yeah, I'm the proud discover of CVE-2008-5187.

It's my first time, it does mean something to me.

Since version 3.1, awesome is bundled with naughty, a notification library which allow to raise pop-up in front of the screen to display information you chose. A sort of notification-daemon, but not plugged into D-Bus.

Last days I've began to work on awesome 3.2 (aka the 'next' branch in awesome repository). I've started to chat with Leon Winter on IRC about the possibility to implement notification specifications into awesome.

awesome had since version 3.0 a very light D-Bus support, since it only allowed to evaluate Lua remotely, without getting an answer anyway.

I've hacked it so now there's a D-Bus hook, which is called upon a D-Bus message received. This, plus the possibility to return various data type (not all are implemented as of this day) allowed Leon to enhance the naughty library and to add support for a primary notification support.

I just have to add more D-Bus data type support, and we may be able to support all the specs, with icons support, etc.

is out.

I've received my new poster.

I've just turned up a quarter of century.

I want cookies.

A lazy morning again, so you'll enjoy another short list of changes in the upcoming awesome 3.1 (first one is still here):

• Text can now be spread across multiple lines, using pango ability to wrap text;
• New full screen layout;
• awful.clients.swap.bydirection function;
• Images get crop_and_scale() method;
• New module: invaders, a space invader game;
• New module: naughty, notification module (like GNOME's notification-daemon);
• More hooks: "clients" for client list changes, "tags" for tag list changes and "tagged" for client's tag list changes;
• Wiboxes's widgets can now be composed of arrays of arrays, specifying a DAG structure, unless of a simple array. A reference is kept to it so it can be retrieved later. Any array can be modified with awesome being notified using a proxy table system.
• Taglist and tasklist widgets are gone from core and are now written in Lua, using the above system.

Not too much changes, I've spent something like a week thinking and writing the 2 last points. I've now a bunch of things to finish and I think we'll go for a RC release in something like a couple of weeks.