XBLinJS 0.4.1 is released.
In the unlikely event your browser has SVG support built in, see the SVG Widget demo. Simple, but real.
One of the promises of XBLinJS was that you'd be able to use it for more than just HTML. I have to admit that at the time, I was only about 80% certain that I could do that. But I saw this article, and combined with the recent market successes of Firefox and some personal projects of interest that could be used there, I took a few hours tonight and tried to create an SVG Widget. (Note that the real story with FireFox is they plan to "turn on" the SVG support for everybody in 1.1; it has existed for a while, but in a highly experimental form.)
I succeeded; it turns out my DOM2 support (via DOM2Flavor) had several serious shortcomings, so probably I was the only one who could get it to work, but by and large I created an SVG widget today. It is a blue rectangle that, when clicked, grows vertically by 10 pixels. It may not be exciting but it does provide a proof of concept, and it is directly part of an XHTML page, not an embedded object. (I am not certain if XBLinJS can be used on SVG images embedded via object tags.)
That said, it seems likely to me that my next major conversion job is to convert a drag-and-drop library into XBLinJS, and experiment with some SVG stuff for 0.5, hopefully with the same drag-and-drop libraries working both for HTML and for SVG. (Theoretically it can be done, but we'll see.)
A 0.4.1 release will likely be made over the next couple of days to include the at-least-partially-functional DOM2 support, and some other minor bug fixes I encountered along the way. The demo will also be updated, even though it is likely the SVG support will only work in a very small number of Mozilla installations.
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.
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.
|Past Posts ->|