XBLinJS 0.4 Released
Apr 28, 2005

XBLinJS 0.4 is released now.

The promised "interesting widget" turned out to be a conversion of a Javascript Shell from elsewhere on the net; see the demo page, at the bottom.

The main point of this release, aside from the aforementioned Javascript Console, is the big internal changes in the release. Be sure to read the CHANGELOG.

One of the side effects of this big change is that XBLinJS can now actually be used as a replacement for XBL; see the Advanced Uses page.

This is probably the last release for a while, unless I get some kind of feedback, because I am going to turn my attentions back to my Iron Lute project, and start a new job in the near future. How much this library changes will depend on feedback or if I quickly start using the new library in my new job.

The next major feature, aside from continuing to port interesting widgets and libraries from the net, will likely be support for better graceful degradation. At the moment, XBLinJS assumes you know the user will have Javascript, that they will turn it on, and that it can construct entirely new widgets from scratch. The next major feature is to add the ability for Widgets to bind to already-existing HTML nodes, and proceed to add event handlers or even add more DOM nodes, which will enable you to create XBLinJS-based widgets that still gracefully degrade if Javascript is off; for instance, you could create a map display widget that enables client-side scrolling or something as Google does, but still works like old-style maps by clicking on the image to re-load the page if the user doesn't have Javascript available. This will make XBLinJS more attractive for use with sites available to the general public.

If anyone wants this feature sooner rather than later, or would like to work on implementing it, contact me and I'm sure we can work something out.

Television Not So Dumb As Television Tells Us To Think It Is
Apr 25, 2005

This article explores a trend I had noticed lately, but had not noticed how pervasive it is. Much prime time television has become phenomenally complicated, to its great benefit. My wife and I both enjoy Alias and CSI (only the original, not the spinoffs), and we are frequently asking each other what something means, because if you so much as get up to get a drink, you'll miss something, something that might change the course of the entire episode.

I can also say this is not confined to television; I don't read enough books in general to know whether this is happening across all genres, but a Hugo winning science fiction story of today is likely to be significantly more complicated structurally than a Hugo winner of the 1960s. The excellent A Deepness in the Sky, the 2000 Hugo Award winner by Vernor Vinge, tracks, off the top of my head, at least 8 characters consistently through the book, with frequent visits to minor characters as needed. (For reference for those who may wish to check that, I'm counting: Thomas, Qiwi, Pham Nuwen, Ezra, Sherkaner Underhill, Victory Underhill, their children (considered as one), and Hrunkner.) The Gripping Hand, by Larry Niven and Jerry Pournell, ships with a Dramatis Personae consisting of about 40 characters; the POV tracks at least 4 or 5 people. Compare this with, say, the classic Foundation series (before Foundation's Edge), where each story has one main character, and a supporting cast of perhaps five people overall.

Is this a good thing? Probably. Especially in the book format I don't think this necessarily contributes to scatterbrain-edness, which isn't a word but will have to do. But it would be interesting to see how modern people do with concentration vs. the people of fifty years ago, and I will be intrigued to see how it plays out in my profession over the next few years.

The article at the end also touches one of my Pet Educational Theories: Learning how to deal with this sort of cognitive complexity is something very valuable and we ought to consider it as we choose our entertainment sources. There are worse things to do with school time than introduce the children to a protracted game of Civilization, vying only with SimCity for the title of Ultimate Resource Management Game. (There are many other empire-building games, but most of them focus on the fighting, not the building. A good Civ player can literally defeat his opponents by out-building them, just like in the real world.)

Apr 23, 2005
Iron Lute, XBLinJS

I finally have a job, a real job, though I don't start until May 9th. For a while after that I will have an overlap between my real job and my last contract job, but after that, I hope to finally have some time to spend with a clear conscience on my open source projects that I want to work on, especially Iron Lute which has been seriously neglected (though not quite ignored).

In Iron Lute news, in the intervening years since I last analysed the graphical toolkits for whether I can build an outliner with them, GTK has become possible to use without too much hassle. Since this is about the fifth time I've switched major ways of doing business on the GUI front, I've got the independent stuff pretty well factored out, and it's going well. I got TK to a point that was almost satisfactory, but the graphical performance was poor; the node indicators (the thing you see to the left of each node) were getting painted in a seperate pass from the text, so while scrolling or doing other things, it looked horrible. GTK doesn't have that problem, and at this point I don't anticipate any other major problems.

XBLinJS is about ready for a 0.5 release pending me getting off my duff and testing and fixing it up on IE 6, which should happen soonish, but no promises.

Here's hoping the job lasts a while.

Apr 16, 2005

There is a very nice Javascript Console available at http://www.squarefree.com/shell/shell.html; I've ported it into XBLinJS to replace the hacky little one I had written. I've tweaked it up a bit and also removed a little bit of functionality; in particular you can't start up the Console from a bookmarklet in the context of the original page, and it is easier to create subclasses with customized shell commands and keyboard shortcuts.

This is in CVS, though I have not tested it in IE, which typically means it won't work there yet.

This is an example of XBLinJS's capability to unify the many disparate little chunks of Javascript functionality out there in the wild into one coherent library format; now it's all nicely wrapped up and easily added to anything. I haven't talked about this much because I've had nothing to point at, but I've got a couple of other widgets like this lined up, ported from other sources but wrapped up so anyone can use them just like any other XBLinJS widget, not on a per-library basis. (This widget did not gain much from the conversion, mostly getting off of using global variables, but one of the other widgets I've preparing, a Rich Text Editor, is benefitting greatly from XBLinJS, both simplifying some of the code and actually gaining customizability at the same time.)

Apr 12, 2005

During a bit of development downtime here, I've been working on making XBLinJS work on any ol' DOM nodes, not just HTML ones. Which, most notably today, means that you can in theory use XBLinJS as a drop-in replacement for the actual, factual XBL. It also means it can be used with other document structures that use DOM and the same basic event structure, like perhaps SVG someday. If we're extra good developers, we may someday see widgets that successfully integrate both XUL and SVG at the same time. Maybe even cross-browser...? Please?

Mostly it involves turning some document.createElement calls into document.createElementNS calls, and a little (very little!) bit of bookkeeping to decide which to use. (createElementNS is DOM2, which not all browsers support, so I can't require it, but you can't use DOM reasonably in a modern XML document without it.)

Which means, hooray!, another set of quirks to deal with. Because if you think that XUL might be implemented as a kind of super-HTML, almost identically implemented but with extra widgets, boy would you ever be wrong! Functionally, it's much more like an extra wimpy HTML, only with extra widgets that are extra likely to crash the browser or randomly and untracably fail. The theoretical power is greater, and you can certainly realize much of it, but what ought to be unmitigated benefits (especially as you can embed arbitrary XHTML in XUL) is severely weakened by its spotty implementation.

I had some real trouble with the getting the events to register correctly, but fortunately, while XUL doesn't like node.onclick for a node that isn't yet on the screen (more "it has to be rendered for it to be real" crapola that I remember from my XBL days), you can use addEventListener.

If these target-specific hacks start piling up, I'll factor them out into a support "Flavor" object so they don't clutter up the code and you can just load the one you want, but so far they are limited and can't add more than a couple hundred bytes to the compressed code. We'll see if they stay that way. (I'm currently guessing 50/50 there will be something like this in 0.4.)

In other news, I stumbled across this Javascript shell which is much nicer than the one I had before. It is compatibly licensed, so I am also currently sucking it into XBLinJS and 0.4 should have a much nicer HTML JS console. An interesting experiment, if I get bored, will be to try to get that working in XUL by labeling all of the nodes with the XHTML namespace and see what happens. It ought to work, in theory, except the event processing may be borked.

The XUL-support stuff is in CVS, but poorly tested. (My plan is to get to the point where a person who cares about XUL can do something real, but not necessarily perfectly, which is a pre-requisite for anyone to care.) The extra JS console, not for the moment.

<- Future Posts Past Posts ->


Site Links


All Posts