Another fellow just popped his head up with a patch that
fixes Unifont in the GLDK. The Unifont Project is a bitmap
font that implements the entire Unicode character map.
Berlin uses it as a fallback when no other fonts can be
found. (Or in the case of GLDK, freetype support just plain
isn't implemented yet.) This is great because it means that
I don't have to fix it myself. I was planning to do that as
soon as possible after landing the SDL/GL rewrite by
rewriting the GLUnifont code using display lists and
texfonts. It's a lot of work saved.

As for the SDL/GL rewrite, it's finally coming along. I've
decided to move the Pointer out of the DrawingKit and into
the Console. Also, the GLDrawingKit will never use any
Drawable. Instead, it'll ask the Console to activate its the
GL context mode, so that the GLDK can make whatever GL calls
it wants. This is by far the cleanest solution, except that
it means that the server would be running without any
Drawable at all and the server tries talking to the Drawable
in several places. Interestingly, most of them have to do
with the mouse pointer and that's now in the Console too.
The other calls to Drawables have been diked in my latest
patch too. I'm no longer releasing hwaccel revisions because
my latest patch doesn't actually support hwaccel yet. In
fact, it even breaks SDL completely, but at least everything
will work perfectly when I'm done.

I now understand why I couldn't create a SDLDrawableGL. The
console tries to keep them in a STL vector of type
DrawableTie<SDLDrawable>. I'm still looking for a good
source of documentation on the Standard Template Library,
but I now know what a vector is: an array of similarly typed
objects, type-enforced at compile time. I should consider
doing the same thing with my new Pointer/PointerTie setup
because every time you call Console::pointer() you get a new
object instead of a reference to the pointer you want. How
should we handle multiple pointers? Or should we?