Older blog entries for nicholasl (starting at number 3)

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?

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!