13 Nov 2001 nicholasl   » (Journeyer)

There's a lot of work for me to do. I've had to deal with my major corporate clients having colliding hard deadlines, school projects galore and my Project Advisor wants me to stop coding 100% and start writing English. I'd understand if he wanted me to start documenting stuff, but he doesn't. He seems to want me to do something in the project management side of things, as in the people part, not the computer part. Naturally, I only half-understand what he means. :-)

Stefan semi-liked my half-baked Console restructuring patch. I accidentally added a dependency from GGIConsole to MESAGGI which I didn't intend and I've fixed that. Stefan's idea is to allow the Console and the DK to use any API that they want when communicating with one another, where the DK has the smarts to handle different Consoles, which is great. It means creating a consistent ConsoleBase interface for libBerlin to use.

I still don't know what belongs in there. For example, my patch removes all dependency on Drawables from libBerlin. But things like width, height and resolution were offered on a per-drawable basis. The purpose of multiple drawables remains a mystery to me, though Stefan says that it exists to allow for multi-buffering. But if that's the case, shouldn't the width and height still be global? Now suppose they are and the Console hides the existence of a Drawable from libBerlin -- if the Console even has a Drawable at all.

What we've done is imply that on any display Berlin will run has a finite height and width. Which is true so far, but is it a safe assumption forever? What about other properties like resolution or pixelformats? Does a display-postscript display have a resolution?

We had to pull drawables out of the public Console API in order to implement hardware accelerated GL. Will we have to pull something else in order to support another display? I wish I knew.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!