Category Archives: XUL, XBL, JS and DOM

Aluminium, Verbosio, XUL, XBL, JS and DOM

Verbosio is dead… but I have a new code name, Aluminium, with the same ambition

Perhaps the fastest evolution in the world today is knowledge, not software.  This has become painfully clear in the last few years.

The way I see it, Mozilla and I are both going through major turns in our respective life cycles:

  1. I turned 40 this past December.  That has all sorts of implications by itself, good and bad, in the current technology sector…
  2. I am roughly 18-24 months away from finishing a Bachelor of Science degree in Computer Science (with no college debt, thank you very much).
  3. Mozilla has ended support for their (admittedly proprietary) add-ons model, XBL is on the way out, and XUL will follow.  This means that the most specialized professional experience I have is not obsolete, but is dying a hard death, faster than I can keep up.  So the bachelor’s degree is coming around at just the right time.
  4. Rust has definitely arrived in the Mozilla toolchain, and Servo is on the way, as a wholly new layout engine.  (By the way, Lin Clark:  thank you so much for your articles on web engine design.  They’re priceless.)
  5. Emscripten is here, and new libraries to bridge between generated WebAssembly code and DOM/JavaScript API’s are under construction.
  6. Mozilla Firefox WebExtensions replaced the old add-ons model, which means a whole new API to learn – and later, when I work in compiled code on my own projects, customize and extend.  I’m really envious:  these are amazing technologies in their own right, but only Rust, WebExtensions and maybe Emscripten are “mature” at this time from this list…
  7. I’m still working on es-membrane (formerly es7-membrane), which I think is pretty interesting in its own right.  It’s maturing nicely as well, despite a lack of my available time.  (I’m still looking for help on that, by the way.)
  8. I’m a little surprised that the D programming language hasn’t received much traction… although until they become part of GCC and LLVM natively, I suppose I should be.  Supposedly, that’s in progress as well.

All of the above means that Verbosio, as a Mozilla Firefox-based XML editor with specific XML languages as add-ons to the editor, is truly and finally dead, and there’s no point trying to believe otherwise.  Similarly, the need for a XUL IDE is dead as well.  (Daniel Glazman and I need to get together to cry over a beer sometime.)

Enter a new code name, “Aluminium”.

I still want to build a stand-alone (but not too complex) web page editor supporting mathematics students at the high school, community college and university levels.  Amaya remains my inspiration.  I want to build a successor to that project, focusing on HTML5, MathML and SVG, with a conscious bias towards assisting students in doing their homework (but not doing the homework for them).

Of course, naming a future web page editor Aluminium, and basing it on arriving Mozilla technologies, leads to all sorts of bad puns:

  • By inheriting the concepts and some of the non-legacy code from Verbosio, I may be able to call Aluminium “powderware”, not “vaporware”.
  • When you mix powdered Aluminium with Rust, and a small spark of inspiration, you get some solid iron (very useful in repairing metal fatigue, I hear) and lots of heat to feed the fire (fox?)…
  • Apologies to all the Mozilla Firefox theme add-ons with a name of “Aluminum” or “Aluminium”.  Obviously, the name isn’t original.
  • I want to use the spelling and pronunciation common in scientific publishing and outside North America.  (This is again because I wish to place an emphasis on mathematics editing.)
  • Aluminium is the name of a metal, like a certain extremely popular web browser.
  • On the other hand, with all the features I want to implement, especially in-page version control for mathematics formulae, I’m not sure I can make it all that lightweight.  (Mozilla is no simple beast to build, either.)

I know, I know, that’s enough jokes for now.  But about the editor project itself, I’m actually quite serious.

Right now, one of the classes I’m taking at California State University, East Bay is titled “Graphical User Interface Programming Using a Rapid Application Development Tool”.  In short, it’s an introduction to building GUI windows (using Qt as a baseline and toolkit) as opposed to a command line application.  This is a course I am extremely lucky, and extremely happy, to get:  it doesn’t appear in the catalogs for any other CSU campus that I could find, much less go to, and the Computer Science department had told me repeatedly it wasn’t supposed to be in the CSUEB Catalog anymore.  All my programming experience and studies to date have either been for command-line applications, inside a web page, or with Mozilla’s platform code.  None of that taught me how to build GUI applications from scratch, or how to embed a web rendering engine like Servo.  That’s going to change…

Later down the line, I’m not planning on taking easy courses either:  I’m looking forward to classes on “Automata and Computation”, “Analysis of Algorithms”, “Numerical Analysis”, “Compiler Design”, and existing mathematics software.  All of these can only be force-multipliers on my computer programming experience going forward.

So yes, the old, non-standardized technologies of the last twenty years are being eliminated in Darwinian fashion… and a whole new generation of standards-based and safe-to-program-in computer languages are arriving.  The way I see it, I’m earning my Bachelor’s of Science degree at exactly the right time.  I hope future employers see it the same way, to work on some truly ground-breaking software.

Thanks for reading!

Alex

Technobabble, XUL, XBL, JS and DOM, XULRunner thoughts

Compacting XUL interfaces?

For my day job, I work at a startup, basically as an expert in Mozilla technologies.  I love what I do, too.  But whenever I do user-interface work, I frequently run into a simple problem:  screen real estate.

Case in point, my latest work with XML entities and entity references on the Verbosio XML editor project.  (I can’t really talk about details of my work-related code here, but I can talk about the pet project.)  The demo panel for this, which doubles as a laboratory for my experiments, has four major sections.  The upper left corner holds a CodeMirror instance for one DTD document.  The upper right corner holds another CodeMirror instance, for a second DTD.  The middle horizontal section holds a third CodeMirror instance, for the XML document that might load the DTD documents.  Each of these has some ordinary XUL buttons on the right edge and a menulist, to help me control the individual sections.  In the bottom third, I have a XUL deck which can toggle between an iframe and a XUL tree showing the document object model of the XML I’ve parsed.  To the right of this XUL tree, I plan on adding a bit more, for showing the entities defined in the doctype or the entity references on a node.

EntityParsePreview

All of this UI lives inside a tabbox.  As you can see, it’s already a little crowded, though fortunately, it’s almost complete in terms of features I need.

I can’t do a fair comparison against the Mozilla Firefox user-interface; the main windows don’t have textboxes for source code or trees for DOM views. So their controls’ relative sizes don’t come close to mine:  they’re much flatter.

The built-in developer tools, though, do have an elegance to them, and are a fair comparison.  The right side panel, showing variables and events, can collapse away (and the animation’s pretty nice, too).  The left side panel has a listbox (I think) of scripts to choose from, and when you select one (either in call stack or in sources), the equivalent source code appears in the center.  Plus, they have some really tiny icon buttons in the UI, much smaller than the standard XUL buttons I use.  The devtools UI gives you basically what you need and otherwise tries to get out of your way.

Dear lazyweb of Mozilla UI specialists:  Can you point me to a developer.mozilla.org document with some guidelines for efficiently using the screen real estate?  My user-interface works, but I need some tips & tricks for making the most of it.  It could be simple stuff like shrinking buttons, or it could be creating new XBL bindings to masterfully present common ideas together.  I’m not willing to go to HTML5’s Canvas for this.  But my experience has largely been in components and JavaScript, not in crafting UI’s…

Or maybe it’s time for me to re-read Jenifer Tidwell’s excellent book from 2006, “Designing Interfaces”.   (I have the first edition.)

Verbosio, XUL Widgets, XUL, XBL, JS and DOM

FastEventLog.jsm: A quick and dirty event log viewing tool

1 Comment

About this time last year, I introduced a tree views module to my Verbosio XML editing project, which I’m still building infrastructure for.  One piece of that infrastructure uses the TreeViews module, and adapts it for simple sequences of objects in a common format.  Event logs were the use-case for this.

(This is currently independent of Mozilla Firefox’s own Log.jsm support, which is pretty nice itself!)

Let’s say you have a simple array of simple objects.  They all have a certain minimal set of properties.  If you want to visualize these objects laid out in a table, then each row can represent an object, and each column a property of the object.  XUL trees can build this table-like view, but they need some help.  First, they need a tree view that supports objects of the same basic type (TreeViews.jsm).  Second, they need to be built with the columns you want.

FastEventLog.jsm does this.  There’s two methods:  addPropertyColumn() and appendTree().  The first takes a property name, a label, the column width, and a couple other optional details.  The second method takes a box to hold the XUL tree element, a specialized “id prefix”,  a tree height, and the array of objects you want to show to the user.

If you have two separate arrays with the same structure, you can call appendTree twice. (Think expected results versus actual results.)

When working on my asynchronous transaction manager idea (more on that in a future post), I realized I couldn’t easily visualize what had happened.  The Firefox devtools debugger is awesome, especially with Thunderbird’s Remote Developer Tools Server extension.   But the debugger’s JavaScript object tree showed arrays of objects in an ordinary key: value hierarchy.  The data I wanted was buried very deep, and impractical to really analyze.  So I built FastEventLog.jsm and a helper XUL file to turn the tree branches I needed into XUL trees.

fasteventlog

The above is a screenshot with a bug deliberately introduced into the underlying transactions test to show what FastEventLog and TreeObjectModel (from TreeViews.jsm) can produce.  This little table view made diagnosing bugs in the async transaction manager very easy!

As usual, this FastEventLog.jsm is available under MPL / GPL / LGPL tri-license.

Abacus, Editorials, Number Crunching, Verbosio, XUL, XBL, JS and DOM

Verbosio: It’s time to ask for help.

Yesterday afternoon, I spotted a sentence in a Planet Mozilla Projects page which shocked me to no end.  Benoit Jacob was advocating the end of MathML in Mozilla code.  The thread has attracted a lot of responses, and the tone largely opposed to his proposal.

Personally, I’m opposed to it as well.  MathML is one of those frontiers which has immense unexplored potential.  Can you imagine writing e-mails to instructors with inline mathematics formulae, or including equations in an instant messaging chat?  I can and have imagined exactly that for as long as I can remember.  I tried once upon a time to bring MathML into Mozilla Composer with my Abacus project, but determined it was too hard and too hacky to be a true solution.

This is precisely why I’ve been working on my prototype XML editor, Verbosio.  It’s supposed to be a complete rewrite of how we create and edit web pages.  The idea is that a language like MathML is simply a Mozilla add-on to the editor.  Unfortunately I’ve been buried with both full-time work and college to make any real progress on my Verbosio project on my own.

I’ve said for years that I didn’t want to attract a larger audience on an unproven principle.  Maybe that’s the wrong decision in this open-source Mozilla community.  While I still believe in the idea, I’ve become my own bottleneck.  It’s far past time for me to swallow my pride and admit that.

What I need to continue development is some help – and I don’t care how junior that help is, as long as they’re capable of writing JavaScript and willing to learn.  Two to five people who can work with me by e-mail and are patient can achieve far, far more than I can on my own.  I can train other engineers in this technology.  I can teach and explain what I’m trying to do and why at a deep level.

We’ve seen major improvements to browsers over the last five years:  HTML 5 form controls, audio and video, faster JavaScript performance, etc.  All of these areas are attractive.  Editing web pages?  Not so much – except to me.  The ability to write efficiently is still as important as the ability to read efficiently.

So, if you’re a budding JavaScript developer who wants to get into something experimental with someone who won’t quit on the idea, please leave a comment.  I should’ve asked you years ago.

Technobabble, Verbosio, XUL, XBL, JS and DOM

Preserving source formatting: I need samples of real-world markup

Imagine the following:

  1. You have a XML or HTML document from a version control system. (SVN, Hg, git, etc.)
  2. You have an editor which parses that into a DOM document.
  3. You edit the document using a GUI, not looking at the source code – just adding in paragraphs, new widgets, math formulae, vector graphics, etc. with a visual editor of some kind.
  4. You finish your changes and save the document.
  5. You get ready to commit your altered document back to the source code repository, looking over the change set, and wonder what your editor did to your document:  it only looks vaguely like what you started with.

This is a hard problem, I think, and for the most part it comes down to handling white space inside a XML tag of some kind.  For instance, attributes may appear all on the same line as the element they belong to, or on new lines by themselves, with different indentations.

On the one hand, a visual editor like this isn’t required to preserve source code formatting.  As long as two different formats of the same XML document’s white space parse to equal DOM nodes, the editor normally does not care.  On the other hand, version control systems don’t often deal with DOM nodes – only with the source markup that an editor generates.

In trying to build a better XML editor (Verbosio) which supports editing in visual modes, I feel I have to respect both visual editing and existing source formatting.  Now, there may be a solution out there – a set of algorithms and a specification – but I have certainly not heard of it.  On the other hand, many source-controlled versions of XML documents have certain patterns enforced from coding patterns their authors require.  I am much less concerned with formatting a document the way I think it should be than with honoring existing patterns of source formatting.

Given a few samples of real-world markup, I can make some educated guesses – write a few JavaScript objects into a model which tries to respect the original source.  What I’m asking is for diverse samples of human-generated and human-edited markup – not computer-generated 1MB+ size files, but something more reasonable for people to work with.  It’s especially significant if these samples live in (or are derived from) version control repositories.

So, would you please post relevant links as comments to this blog entry?  Either an existing specification for this sort of problem, or diverse XML samples where people have their hands on the code regularly.

Documentation, Technobabble, XUL, XBL, JS and DOM

XPCOM Stream Guide: Help Wanted

I’ve just started putting together a guide on XPCOM streams over at MDN.  We already have wonderful guides on strings, hashtables, and arrays.  Streams are also really important, but there’s not much documentation on them.  So I figured, why not start some?

I’m going to be working with streams a bit over the next few weeks as I convert from SAXXMLReader.parseFromString() to SAXXMLReader.parseAsync().  Apparently, the parseFromString() method is not very nice.  So I’m dusting off some old tools and ideas, and I’ll be writing down what I run into that I think others can use.

The XPCOM Stream Guide is right now little more than an outline.  My own time is very limited; if anyone else wants to fill in some of the blanks, I’d really appreciate it!

 

Verbosio, XUL, XBL, JS and DOM

DOMRelations: A new design for the Document Object Model’s Node objects

For those of you who don’t care how the DOM is implemented, only that it generally works: this is definitely a “tl;dr” blog post.

For those who do care: I’ve been thinking long and hard about how XBL’s shadow content, and how undo and redo operations, work in Gecko.  Ultimately, I find the current implementation just doesn’t support what I need for XML templates.  So I am working on a very different model, one where I base Node objects on “DOM relations” objects.  These latter objects control the relationships between nodes, instead of the nodes themselves doing it.  They also make undo/redo and shadow content much easier to maintain in my opinion (at the cost of additional memory, which in JavaScript land I don’t have to worry about… too much).

I’m not suggesting Gecko DOM implement this (though that would be very nice of them).  I’m going to prototype it for my own needs, and see how well it works.  I hope this explanation is in clear enough language for the average developer to understand.

Technobabble, XUL, XBL, JS and DOM, XULRunner thoughts

Jasmine in XULRunner, part 1: Started, help wanted

I’m working on my Verbosio templates repository, which is where I’m going to try (again) to build my XML templates project. The first thing I’ve been working on is getting Jasmine working with the Gecko SDK.  It’s going really well.  I’ve written some Python scripts to fetch a Gecko SDK build (in my case, Aurora builds), to concatenate JavaScripts together for Jasmine to use as specifications, and to build a XULRunner application to run the Jasmine specs.  I also have code to launch the XULRunner app with the Gecko SDK, so I can see the results. My goal is to offer the baseline as a separate, clean repository for Jasmine testing from XULRunner or XPCShell.

To get where I want to be, though, I need a little help:

  • The Gecko SDK also includes xpcshell, which means it shouldn’t be too hard to add Jasmine testing in XPCShell.  I could then do lightning-quick test runs from the command-line.  Tomas Brambora from Salsita Software’s already done some work along these lines.  I just need his code updated for this project, and MPL tri-licensed for check-in.
  • Only about 5% of the code I’m planning to write needs a XUL environment.  With tools like Firebug, ordinary HTML and “content JavaScript” is much easier to debug.  So I need to integrate downloading a Firebug XPI into my project, and I need a new Jasmine reporter which runs in the HTML and sends message events (postMessage, anyone?) to the privileged XUL Jasmine reporter.  Then I can tie the two together to do most of my work in the very well supported HTML Jasmine debugging environment.
  • (Alternatively, I could modify my project to download a Firefox Aurora build… but where’s the fun in that?  It would be quick, though.  The reason I don’t like this is Mac development becomes more painful:  Mac binaries are in .dmg images.  Installation, maintenance overhead, no thanks.  The Gecko SDK approach feels better for this.)
  • For some reason, the stack trace blocks for test failures are really thin vertically; a little CSS should fix it.
  • I could also use some code and developer usability reviews.

However, I think having a Python build script pull a prebuilt SDK and assemble my JavaScript modules for me is a winner.  It”ll save me valuable hours I’d otherwise spend building Mozilla code.  Once I get a stable development environment, I’m going to clone the repository as-is and maintain it separately for anyone who wants a pure Jasmine+XULRunner+XPCShell environment to start with.

If you can spare a few hours to bring me these last few bits, write me a comment.  I think the Mozilla community at large could really use this.

Check-out and build instructions:

hg clone http://hg.code.sf.net/p/verbosio/templates verbosio-templates
cd verbosio-templates
python project.py --update-sdk
# Wait a few minutes for it to get XULRunner; it's a one-time cost
python project.py --test-xul
# XULRunner will open in another window, but it will block the python script from exiting.
Technobabble, XUL, XBL, JS and DOM

It’s been a really good week.

7 days ago, Jason Orendorff checked in a new feature to the JavaScript engine, the Map constructor.  His timing could not have been better for me, as I was just finishing up a critical part of my DimensionalMap project: getting all tests passing with WeakMaps for object keys.  (DimensionalMap is about a JavaScript-based hashtable in two or more dimensions.)  It didn’t take me long to create a “nativemap” branch and convert my code to work for keys of all types.

That alone would have been cause to celebrate.  I figure Jason’s work here shaved a couple of months off of this project.

However, thanks to Olli Pettay, Jonas Sicking, Ben Bucksch, and Dão Gottwald, among others, my patch for adding timeout support to XMLHttpRequests landed on Thursday.  DOM Workers support for timeouts will have to wait a bit longer, as I’m still a little busy and workers require special JSAPI incantations which I have not yet mastered.  Help wanted!

It feels nice to see both of these happen.  I haven’t been able to contribute much code to Mozilla lately, so anytime I can get something meaningful in, it’s a good week.

Technobabble, Uncategorized, XUL, XBL, JS and DOM

Why I’m attending college: trying to explain my thinking

3 Comments

A couple months ago, I started taking classes at Chabot College.  One reason is to get the degree that shows what I’m talking about.  But there’s another reason, even more fundamental:  filling in the gaps in my own knowledge.

Case in point, I’ve been thinking long and hard about building a JavaScript-based DOM.  The problem I’m facing is that to do everything I want – shadow content, undo/redo transactions, etc. – I need a specialized data structure.  Specifically, I need a data structure much like a multi-dimensional array or hashtable.

(The first dimension would be a set of object keys – the DOM nodes.  Another dimension represents undo history, like a timeline.  A third dimension could be the shadow content.  I could define other dimensions might exist for building an individual transaction until it is completed, or otherwise creating a “workspace” for experimenting.)

About 24 hours ago, I had an idea, related to my multi-part keys for hashtables implementation.  Typically, in designing a data structure class, I think about how to give each piece of data an address first, then I implement ways to store data by that address.  The idea is to flip that approach around:  to define an API that lets the user place an object with an address, and then add new dimensions to the address space as the user needs them.

If I’m not making any sense, that’s fine.  In fact, that’s why I’m writing this blog entry.  I’m having lots of trouble articulating last night’s idea formally.  I can see it crystal-clear, and I can write JavaScript to implement it, but I don’t have the language to describe it yet in English.  I spoke briefly with my Calculus instructor tonight, to figure out what area of mathematics my idea might fall into, and he suggested linear algebra (that my idea relates to vectors in some way).  Which I can’t take a class in until I complete Math 1 and Math 2 (both are Calculus classes; I’m enrolled in Math 1).  The name of the linear algebra class, at Chabot, is Math 6.

This underlines why I’m going to college after at least six years as a professional software developer.  It’s a gap in my knowledge.

Some people, like me, enter this field with a talent built upon years and years of tinkering, of experimenting and of thinking.  The software industry can really take a person like that quite a ways.  Others enter the industry having taken computer programming courses – and that’s really hit or miss for an inexperienced person.  (No offense intended to the software engineers who started through college!)

I wonder if taking up college classes after you’ve been in the industry a while is actually the best approach of all:  continuing the education, helping clarify what you’re working on and expanding the imagination with new possibilities.

I wonder how many current software engineers have decided to go back to college after being in the field a while, to push themselves and their capabilities even further.