Rewriting and bug squishing

I started this week by adding all coding tasks I could come up with to the libwm issue tracker in Google Code. I could only come up with a few dozen issues to start with, but I’ve been adding new ones as I come up with them. I found it hard to convert some ideas to issue tickets and trying to select which tasks to complete before the upcoming release. So far, I’ve only marked the critical ones with the “Release 0.1” milestone label.

I had originally scheduled setting up Doxygen and CMake to generate API documentation, but I had already done this last week, so I had nothing but coding time at my hands.

I started out with adding support for keyboard modifiers (shift, alt, ctrl, num lock, etc)  and mouse motion events, I spent monday and tuesday doing that and everything went pretty fluently. When hacking with the event reading routines I realized that they are in need of a clean up. So after I had added the keymods and motion events I spent a day re-organizing and rewriting the event reading code that listens to event messages from the windowing system, interprets the events and passes them on to the libwm event queue.

When I was fixing the event reading parts I found a bug that had gone unnoticed for quite a while. To work around an incompatibility in window initialization-configuration query order between Xlib and Win32, I had used an extra subwindow in the Xlib implementation. When setting up a drawing surface I added a child window that was the X window that actually got drawn into. When clicking the client area of my window, I got X events that informed the mouse cursor leaving the parent window, entering the subwindow, then a click and leave/enter from the child to the parent. I decided to get rid of the subwindow hack altogether and use a dummy window to query the device configuration on Windows. A third alternative would have been to use some kind of creational design pattern to do delayed window initialization in the Xlib implementation.

So I went on and rewrote the window initialization, configuration query, drawing surface and context set up. On Windows I used a dummy window and device context when using DescribePixelFormat or WGL_ARB_pixel_format to query available pixel formats. On Xlib/GLX no hacks are required. The only hard part was trying to arrange the internal communication between the Window and PixelFormat class. I try to keep Xlib separated from GLX (and WGL separated from the Win32 stuff), so that adding support for EGL and OpenGL ES would be easier in the future.

Sometime during the week I realized I had another bug. I had previously used boost::scoped_ptr to handle the cleanup of my pimpl idiom pointers. I figured out that using scoped_ptr in a .dll on Windows was difficult because of __declspec(dllexport) issues so I switched to using plain old pointers and delete in destructors to get a dynamic library built on Win32. I forgot to take care of the destruction of the “pimpl objects” in case of exceptions in constructors. So I wired an std::auto_ptr inside the constructor to take care of the clean up. I release() the auto_ptr in the end of the constructor and let the destructor handle the final clean up.

Next week I’ll get writing some example applications that use libwm. I’ll focus on trying to set up a testing platform that I can use to debug non-blocking event i/o. I’ll also try to improve my build system to generate package files and handle building static libs optionally.