Category Archives: 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.)

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.

Venkman planning for Gecko 1.9, part 3

Thanks to Gijs and Mnyromyr (and not to me; I didn’t write a single line of code), Venkman’s met three of the six bullet points I listed in my initial Venkman planning post. It is now at least minimally useful for Gecko 1.9 code.

I would strongly encourage Firefox developers (and for that matter, most of us who hack on trunk) to launch the JavaScript Debugger at startup (command-line argument is -venkman), and turn on “Stop for Exceptions”. You’ll find a few pain points pretty quickly. My personal favorite looks something like this:

try {
var foo = myObj.property.QueryInterface(Components.interfaces.nsIFoo);
} catch (e) {};

This code is wrong, in my opinion, on three levels:

  1. The empty catch block, which always annoys me. A comment saying “do nothing” would be better than that.
  2. No checking of what e is. In this example, only one line is inside the try block, but you can’t tell if the QI failed, or if myObj is undefined. It could be the QI failure is expected, but if myObj being missing is a Bad Thing, that exception needs to propagate.
  3. A simple instanceof check removes the need to try and catch. If you can avoid generating an exception, then by all means do so. Exceptions like this are just useless (and probably expensive from a JSENG/XPConnect point of view). Exceptions should be thrown for exceptional circumstances.
var foo = (myObj.property instanceof Components.interfaces.nsIFoo) ? myObj.property : null;

I’m not intending to point fingers, but autocomplete in the URL bar is an extremely visible case of this being a problem for Venkman…

Time is running out for any of these changes we want to get into Firefox 3. If we’re fast enough, though, we can clean up a lot of these useless “noise” errors which discourage people from using Venkman – and thus make exceptions it catches more relevant to whatever problem the user is debugging.

Thanks!

Venkman planning for Gecko 1.9, part 1

Over the last couple years, the Mozilla code base has evolved significantly on the trunk. Unfortunately, development on the JavaScript Debugger has not kept pace – the code has “bitrotted” significantly, and introduced significant bugs.

This is a serious problem. It’s equally serious that no one is hacking on it. I’ve found it to be a very useful tool for working on chrome code, and XULRunner apps would benefit from having a debugger handy.

So here’s what I want to do. I want to schedule a weekend meeting for 2 pm PDT Saturday at #venkman on moznet. The goal, as I see it, is to plan fixing Venkman so it is usable on the XULRunner 1.9 platform. (Getting it working on Firefox 3 would be a nice thing, too.) I want to see who’s willing to contribute hours (weeks, more likely) of coding and/or reviewing to this goal. In particular, I’m worried about trying to find out whatever API changes are needed in Venkman itself (not what API Venkman has to call) and getting them in before 1.9 branches.

Watch this space for more details; I’ll write up a draft plan for the meeting, so we have some things to think about.

UPDATE: So, here goes:

First thoughts – Venkman isn’t quite as bad off as I initially thought. I
tried to install a 1.8-based XPI on the 1.9 XULRunner build, and that didn’t
work very well at all. When I finally figured out how to build a Venkman
XPI:

export CONFIGDIR=(...)/mozilla/config/
cd mozilla/extensions/venkman/xpi/
sh makexpi.sh

Everything seemed to be okay. Starting Venkman via
window.open("chrome://venkman/content/", "_blank", "chrome")
works. But it doesn’t take long to notice a few oddities.

  • I don’t have a main toolbar, where the “Play”, “Stop”, “Step” buttons
    used to be. (Though I do get them starting with -venkman in the command
    line.)
  • Switching from Breakpoints to Call stack panel (lower left corner for
    both) doesn’t work. None of the two-tab tabboxes let me switch to the
    second tab.
  • The error reporting still gets the line number wrong by one. (This is
    probably a JavaScript
    Engine
    bug.)
  • It’s still a little crash-happy. I’ve crashed twice in only a few
    minutes.
  • Venkman (as it always has) has a max of five source code tabs open at
    any given time. On Linux, if the file where you hit an error isn’t one of
    them, you don’t even see the source where it fails.
  • Building Venkman in the tree doesn’t produce a working debugger for XR
    apps – you need to drop a XPI into the app’s Addons Manager.

Ultimately, I think these are all fixable. The real problem, as I
mentioned earlier, is a lack of current contributors. Venkman, like
Inspector, has been neglected for quite a while. There are 136 open bugs
against Venkman right now. (Inspector’s been doing much better lately.) Looking at
extensions/venkman/resources/content/ right now, there are a lot
of “2006”, “2005”, “2004” files… meaning that exactly one file has been
touched here in over eight months! 136 bugs + eight months bitrot means an
effectively unowned module – or a super-stable, frozen one. 🙂 Given the
fact this is on trunk, and the above very-obvious bugs, I’d say it isn’t the
latter.

So here’s what I propose: for 1.9.0, we need two or three chrome app
experts to spend a few days fixing the above issues, and reviewing patches.
Next, we need to go through the bug list and triage it, both for priority and
time constraints. If there are any IDL changes needed, those should go first
in the bug list because we’ll have a harder time getting such changes in
1.9.1. (There aren’t likely to be very many.) We should start planning for 1.9.1
– whatever it is – right away. For 1.9.0, I think we’re effectively in
maintenance mode – there’s too little time for big changes.

If we somehow find the time, (i.e. we decide that all the high-priority,
low-risk issues have been fixed, and we don’t want to chance further 1.9.0
changes), we should probably write a miniature XULRunner app with a known set
of bugs and start running Venkman against it. This becomes a “reference”
application for Venkman testing.

Reviews for new patches should emphasize both tests and JavaDoc’d
functions. I’d love to see some xpcshell tests of the jsd code which Venkman
depends on.

We need to start putting out “nightlies” of Venkman, and making them
available for trunk usage. The simplest way to do this might be a bit of
tinderbox adjustments. Fortunately, building a Venkman XPI takes only a few
seconds.

So who’s willing to spend time on this? The good news is that Venkman’s code is mostly XUL + JS, so you don’t need C++ hacking skills to fix many of the bugs against Venkman.

Jules Verne time

(As in, “From the Earth To The Moon”.)

So the Mozpad group has started, even though we don’t have all our goals figured out yet. I think overall the group has gotten a pretty good response, much like SeaMonkey did when they first started out. But we’re not out of the woods yet.

With the creation of moon.mozpad.org, I’m going to need a bit of help creating a RSS feed for them. I’ll be creating a new category on my blog, “XULRunner thoughts”, but unfortunately, I don’t know enough about MovableType to create a feed template for a category. So if anyone out there can lend a hand (or better yet, some markup template with instructions on where to put it), I’d appreciate it. Other MZ-hosted bloggers might like it too.

One of the proposed goals for Mozpad is to figure out some basic requirements for a successful XUL IDE project. (No, we’re not committing to building the IDE yet. That is a Really Hard Problem.) So when we do get a Mozpad newsgroup, I’ll be starting a newsgroup thread to ask what the community thinks they need. (Please don’t post replies to this blog entry; I just want to start people thinking about it.) Even so, we’re going to need a leader to gather the feedback and process it into a coherent requirements specification. No one’s stepped forward to champion that goal yet, and understandably.

I think, realistically, our goals for Mozpad are — and should be — shorter-term ones – somewhere around six months. Longer-term goals we do not want to set for ourselves, as we’re just starting out. We need to crawl before we learn how to walk, as the old saying goes. Everything on the goals list is achievable with a little effort, and would net the community-at-large some tangible, healthy benefits. So if you can spend a couple hours a week on one of these subjects and it interests you, we could use your help as a champion, as a leader.

Finally, I’ll continue to put all my posts through planet.mozilla.org, even though the XULRunner-specific posts will also be on Mozpad. It’s just another step on the way to Florida, with a really BFG, pointed at the moon. Cover your ears, folks, it’s going to be a doozie.