27 Dec 2004 joolean   » (Journeyer)

Okay, I've refactored the rendering code so that it's all "libruin" inside and out. I also managed to fix a couple of color and size problems. It's really a thing to behold -- tab tab tab tab tab. Unfortunately, fast it is not. It takes 2-3 seconds to size and render even a marginally complex interface.

So now I have to choose between Savannah and SourceForge for hosting it as a project. I don't know that much about Savannah's policies, but it kind of seems like they want you to know way in advance whether you want your thing to be part of the GNU project, and if you do, it had better have Texinfo documentation. Well I just started this thing a month ago! So maybe I'm leaning towards SourceForge at the moment, because they just don't give a...

Here's something that I'm having trouble working out -- if anyone reads this diary, maybe you can comment or e-mail me your opinion. So the XML dialects that I want to render (XUL, XHTML, etc.) all make the implicit choice of ECMA/JavaScript as their scripting languages. I'm not a huge fan of those languages, especially because they sort of presume a particular type of viewing apparatus (i.e., web browsers) so I've chosen Guile Scheme as an alternative -- maybe this is stupid, let me know what you all think -- but this means, I think, that I need to separate out these little scriptlets on an attribute level, so as not to break compatibility with the original XML specs for these languages. For example, a lot of XUL elements let you set an event handler for the "command" event by specifying ECMAscript code in the oncommand attribute. E.g.,

<button label="hello" oncommand="document.foo();"/>

So I figure I should put my Scheme-flavored oncommand in a different XML namespace, like so:

<button label="hello" xul-scheme:oncommand="(document-foo)"/>

That way, traditional XUL parsers can still interpret the XML without freaking out -- they can just ignore the "xul-scheme" namespace.

But it feels kind of... needlessly fragmented to me. And furthermore, in order to be able to do useful things in these little scriptlets, I need to implement a kind of DOM for Scheme. However, at the moment, my DOM functions are all built straight into libruin, which only renders stuff for ncurses. The ultimate goal in my doing all this was to create rendering support for my client-agnostic online gaming system, gzochi. So I'm also going to want, probably, a GTK+ version of this library. If that's the case, it seems a bit silly to build the Scheme DOM implementation into each of the libraries. I think it would make more sense to make something like SXML but for DOM -- that is, a fully-Scheme implementation of the W3C DOM. (The SXML people seem to think this is not terribly brilliant.)

What do all you people out there in computer-land think? I'm literally crying out for feedback here.

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!