I’m in a dilemma. Enough Mozilla community members have asked me, “why don’t you switch to GitHub? There’s a larger JS community over there.” I can’t exactly ignore that, considering that I really do need help. And yet… I like SourceForge. But not enough to be alone in the desert.
What do you think, Mozillians? I know you’re busy, but how strongly do you prefer GitHub or SourceForge over the other?
UPDATE: I just discovered comments were broken… fixed.
(tl;dr) I’ve started a XUL editing miniproject, and I’m looking for volunteers to help build it out.
Which came first, the chicken or the egg? It’s an old question: conceptually, one had to exist to create the other.
My prototype XML editor project, Verbosio, is XUL-based. XUL is an XML language. So to edit XUL, I need a XML editor. To build my XML editor, I need to edit XUL. So which comes first?
Chicken, meet egg. I’ve started work on a “MicroXUL” editing tool to help rapidly experiment with XUL user interfaces and XBL bindings. It’s extremely primitive, but this is a proof-of-concept.
I’ve been using (and continue to use) the excellent Komodo Edit environment to develop pieces of Verbosio, including MicroXUL. The screenshot above represents one wizard page where the user can type XUL markup into one panel, and see the rendered XUL in another, on-the-fly. From this one wizard page and Komodo Edit, I hope to build out the rest of MicroXUL (and Verbosio) with a number of useful features:
This project uses XULRunner (27+ required, currently in Aurora), Python 2.7 for building & launching, Jasmine 1.3 for automated testing, and CodeMirror 3.19 for syntax highlighting.
I started this because I realized I needed new XUL controls and XBL bindings to support new capabilities, such as a XUL user interface for the new Log.jsm architecture in Firefox 27. I couldn’t use Verbosio yet, nor its templates system, since those haven’t been built out yet. But I had just enough pieces from previous work, including my virtual:// protocol handler concepts from seven years ago, to put together a quick & dirty XUL editing interface.
Checkout and build instructions:
Obviously, there’s a lot of work to be done on MicroXUL before it’s usable. But the project is open under MPL / LGPL / GPL. If you have a pain point with authoring XUL, this is a good playground to try fixing those pain points! Your help and experimentation are both welcome.
Project page: https://sourceforge.net/p/verbosio/microxul . If you need help and the SourceForge project pages don’t provide what you need, please leave a comment here and I’ll try to fix it.
Since my last progress update, I’ve slowly moved forward. Some new goodies:
I’m using CodeMirror (current version is 3.18) to act as my source code editor. The scripted DOM is still there, this time showing attributes as children before a XUL tree separator. On the right side, we start with relevant SAX events to capture details of the DOM I’m building. Then there are logging events for the “Node Positioning Service”, which tries to align source code to DOM nodes. The lower right box captures change events from CodeMirror.
Over the last couple weeks, I’ve compared what I’m working on with my project’s immediate goal of building a XML templates editor, and realized that I was starting to get distracted. So I filed a few tracking tickets, checked my roadmap, and discovered I’d essentially finished the second milestone: the DOM implementation in JavaScript.
The next major phase will be about handling XML entities (&button.label; for example). This will require a first introduction of a “shadow DOM”, where some DOM nodes will hide others from direct access. (Indirectly these other nodes will still be accessible.) This also means I’m starting to catch up with progress I made five years ago… that’s what happens when you do a rewrite.
I’m still looking for help! In particular, I would like JavaScript developers to help out with:
By the way, I enjoyed the Mozilla Summit, and thank you for letting me present Verbosio at the Innovation Fair in Santa Clara.
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.
With college and a full-time job, I’ve been rather busy. But I still find time to make small improvements. I’m continuing to work on my experimental XML editor, Verbosio, from the ground level. I realized a couple months ago that I really needed some pictures to show where I was at.
This is work from my Verbosio Templates subproject, which currently requires Mozilla Firefox 22 (currently in Aurora).
The first image looks like a very cheap copy of DOM Inspector – and it is.
The second image is little better, until you realize that the entire DOM implementation is entirely in JavaScript.
There are a couple more differences – for instance, this latter view includes a XML declaration. In the DOM specification, it shouldn’t be there, because the XML declaration is not recognized as a node at all. But if you’re going to edit a document that already exists and already has that declaration, as a set of DOM nodes, you should preserve that declaration. So my non-standard DOM implementation makes it a processing instruction.
Both trees, by the way, are also using my TreeViews.jsm module. I hope this module can be helpful in building XUL trees from object models like the DOM.
I’m also starting work on a WebGL-based view of the same trees, where nodes and their descendants are laid out in two dimensions as cubes, in a tree hierarchy like this. WebGL is a three-dimensional context, though, so you may be wondering what the third dimension is for. Initially, I’ll draw attributes as cubes above the elements they belong to. That part shouldn’t be hard – and it should be very doable by anyone proficient with WebGL, inside an ordinary web page. I’d love it if someone beat me to it.
I have other things to show through that third dimension, so stay tuned. I’ll get back to preserving source formatting soon enough.
Imagine the following:
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.
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!
I thought I was being clever with my DimensionalMap subproject: bootstrapping on top of the Map object to build a multi-dimensional hashtable. Then I started using it heavily in my Verbosio Templates subproject to implement a very customized Document Object Model in JavaScript. With over 900 Jasmine tests passing, execution time was averaging about 4 seconds.
However, I suspected my use of DimensionalMap was unnecessary – particularly since I was working with only one dimension at the time. So in a quick experiment, I replaced the code that used it with code using WeakMap. Total execution time with the same tests: about 1.5 seconds.
Ouch. I still think the API is a good one, but clearly the implementation has issues.
Hey, kids! Wanna build your JavaScript profiling skills? Help me find the spots that are causing unnecessary slowness! I’ll be happy to write a letter of appreciation for anyone who wants to take it on. As always, the code is available under Mozilla Public License 2.0, GPL 3 and LGPL 3. (Childhood not required for participation.)
Both the web technologies space and myself are undergoing a fair bit of change right now. I’m in college learning C++’s fundamentals which I missed, and picking up on concepts in computer science I never really worried about before (order N^2, order n log n, etc.). People who are familiar with my blogging are also aware I like to understand best practices that are language agnostic (i.e. “each function should do only one core thing, and leave the rest to other functions”). I can say I’ve learned a lot of what’s from talented Mozilla contributors, but not necessarily a lot of why’s (at a level higher than specific languages).
On the web technologies side, new capabilities are arriving in Mozilla code very rapidly (WebIDL, “DOM Bindings”, the new C++11 standard, Opus audio, direct proxies and hashtables in JavaScript) – so fast that I definitely haven’t been able to keep up. There’s some very interesting stuff going on under the hood, and I’m beginning to think I won’t recognize a lot of that code in a couple years.
So I’m writing to ask the Web and the programming community at large (yes, bigger than just Mozilla) where we talk amongst each other about computer science as a practice – not about specific languages, but about why we do what we do. Keep in mind I’m not referring to one-way conversations, where someone writes a blog entry (CodingHorror) or a Wikipedia article or a book (thanks, Code Simplicity, seriously), but more of a freeform discussion among professionals. Sort of like an IRC channel (with politeness), or a newsgroup, or even a meal at the local bar.
I’m experienced enough as a developer now to mentor others, but I recognize that I am not yet the Wise Bearded One. (Nor will I be in December, thank you very much.) I’d really love to find a place to hang out with other professionals in a free-form exchange of ideas. Somewhere to step into the abstract without getting too technical.
Ideas welcome!
My prototype XML editor reboot continues! In putting together my templates editing subproject, I’ve finished building out the basic infrastructure for a partial Document Object Model implementation in JavaScript. I have a roadmap, and a decent development environment… life is good. If you’re going to check out the code, you might want to wait until Tuesday… as that’s when Firefox 13 and built-in JavaScript Map() objects become available to the general public.
I wish I’d had a chance to attend the recent Fluent 2012 conference in San Francisco. I just found out about it too late. I’m rather curious to see where some of my infrastructure work could be improved with ECMAScript Harmony, or whether I’ve had an idea that Harmony might find useful. There’s a lot going on in JavaScript these days, and it’s exciting.