Older blog entries for nicholasl (starting at number 2)

So my Grad Project Advisor is no longer Dr. Rice (prof of mathematics) but Mr. Combeer (director of information technology). Neither of them are much for programming, but at least the IT director can hire technology people (read: programmers) who might understand Berlin. I just have to make sure he asks the interviewees the right questions.

I'm getting positive feedback from the Berlin crew. Or at least from the ones who have 3d cards. They're giving me the warm fuzzies! There's a lot of chatter on berlin-design, finally. I thought of using save unders (or backing store, not sure which these days) to implement the mouse pointer and allow the same API for clients. X does this for transient windows like popups, if I'm not mistaken. Another idea came out, to avoid the work-associated-with-the-scene-graph for windows that are obscured. Unfortunately, there's nobody in Berlin who can convert 2d pixel coordinates into a scene graph node, short of doing all the associated-work. The proposal is to add such intelligence into the drawing kit, the only place allowed to talk in terms of pixels.

Complicated. I'd rather get some basic hardware acceleration into Berlin now and think about such things later.

I originally thought that I would need to split the SDLConsole into two modes, dependant on the DrawingKit, but as it turns out, the SDLConsole object is fine, my changes only apply to the SDLDrawable object. What I really, really want is an SDLGLDrawable object. Whether it should live in the GL DK or the SDL Console is a matter I'd rather leave up to the policy makers, but I'll do something if no one tells me what to do. I already made one attempt to update the code w.r.t. choosing multiple Drawables, but failed miserably. Perhaps a knowledge of C++ would help, as there seem to be some tricks involved in guaranteeing (at compile time) than an object is of the right type, and my SDLDrawableGL != SDLDrawable. Oh well.

Or maybe not like that. In the interest of getting the GL support landed, I'm going to go the minimal-impact route. I still want to have a Drawable implemented in GL calls (meaning that draw_line uses glVertex instead of Brezenham and put_pixel). But today, I've got schoolwork. It's not like last week with two math tests, but more like next week with two math assignments.

I'm keeping this diary so I can show my Grad Project advisor that the work I'll be presenting is my own. They're concerned about me presenting 'something' without being able to seperate my own work from anyone elses. Hopefully this diary will help.

I'm working on the Berlin project ATM. I've already released a patch that makes it run in OpenGL on top of SDL. Of course, with the patch applied, GGIMesa mode no longer works. I'm taking this as an opporunity to redesign the way that the Berlin Console and DrawingKits are defined.

The deal is that we've got lots of bits and pieces and no good organization. I'm sifting the code into categories to allow a better matching of optimized implentations. See, the LibArtDrawingKit implements the DrawingKit interface on top of basic Drawable operations. There's a slow impl of Drawable operations on top of a generic Framedevice, but if the fd is actually a GGIFramedevice, then we can use the GGIDrawable that runs faster. Like that.

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!