XBLinJS 0.4 is released now.
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.
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.
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.)
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.
This is in CVS, though I have not tested it in IE, which typically means it won't work there yet.
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.)
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 ->|