Category Archives: Verbosio

Verbosio first milestone: what would you expect?

Theoretically, I could put out an initial milestone of Verbosio, my prototype XML editor, for general consumption if I spent a week or two finishing up the bare minimum functionality. But that would leave a lot of potential users (particularly the Mozilla development community) very disappointed in Verbosio. It would have rudimentary editing capability, and that’s it.

Besides, I keep having ideas that just can’t be ignored. Yesterday, I chatted on #developers about syntax checking for JavaScript source and possibly CSS stylesheets as well. (XML’s equivalent is well-formedness.) Properly designed components could tell you if your document is unusable. This evening, I realized that the buttons for selecting nodes from a toolbar would be better done with images and tooltips than wordy labels, so I started designing a set of simple (I hope!) button images in SVG. I’ll convert those to PNG images later. The new idea stream just goes on and on.

Then there’s the dreaded Verbosio Manual, which I absolutely have to write. In creating the Verbosio architecture, I’ve diverged a little ways from traditional XUL application development. No one will write extensions for Verbosio if they can’t understand how. The model I’ve built for extension development is a little more rigorous than I suspect most extension developers are used to, and it may not fly.

Plus, glazou has finally indicated his prototype XML editor, ETNA, is starting to come together. I really wouldn’t mind being a beta-tester for that, or maybe even an alpha-tester.

I’ve talked about Verbosio for months now on my blog. I want your opinion: where in its evolution would you expect a XML editor project to be, before you wanted to touch it and work with or on it? I’m not talking to end-users here, I’m talking to the development community. I want to do an initial release at the right moment, but I don’t know when that is from a technical standpoint.

Stand-alone editing vs repository editing, part 2

In a repository mode of editing (where you can edit several documents at once, some dependent on others in the same set), one could easily edit a complete XUL application. (I intend to create a demo of this as well.) Part of that could include transactions that affect more than one document at once. Here’s a sample XUL document I cooked up for adding a XUL menuitem, with support for localization and creating key and command elements related for this menuitem if the user desires. This user-interface would edit the master XUL document, a localization DTD, and possibly an overlay for menus.

Improvements are welcome! There’s certainly room for it. Send me an e-mail with your changes to this code; if it makes sense, I’ll add it. (Don’t worry about where the menuitem gets placed; I’ll be working on that.) Bear in mind this UI must fit into either a sidebar or a bottom bar (I haven’t decided which yet).

If you’re reading this via or, you’ll have to visit this article directly for the demo to actually work.


Verbosio is blocked by an old Mozilla core bug

Bug 201236

All work on Verbosio has effectively stopped because of this bug. Verbosio relies extensively on documents without windows. (Extra window objects are bloat.) Mutation events are also fairly important, as it is how Verbosio’s various pieces detect changes in the master document.

This sucks. This sucks the neutronium out of a black hole. A Verbosio build based on SeaMonkey 1.0 just became impossible, and that was a major goal I had.

UPDATE: Patch posted! I hope the reviewers like it.

I really should get around to requesting cvs checkin privileges for the main tree, instead of just docs…

Stand-alone editing vs repository editing, and other thoughts

This evening, I realized there’s something wrong with my virtual: protocol handler. It degrades gracefully to real protocols if a virtual file isn’t in the file service, but it doesn’t edit the loaded real file’s links to other files. I can’t point from a real file to a virtual one.

There’s really only two simple solutions to that problem: either have everything a virtual file points to become virtual, or have nothing it points to become virtual. A little thinking makes it obvious you can’t have everything virtual. If I’m editing, and I link to, the latter is content I don’t have any control over, so that mustn’t be virtual. On the other hand, if nothing’s virtual, you lose a lot of the benefits of having a virtual protocol in the first place; you can’t see the impact of one file on another.

After a little more thinking, I realized a deeper issue, a conceptual one. Specifically, some XML documents link to other files regularly (XUL, XHTML, XBL). But other XML files usually don’t (MathML, SVG, RDF). It’s a big consideration, one that HTML editors never had to think about. HTML is all about hypertext, which fundamentally is about linking.

This morning, I also hit on the thought that most files in a web environment are organized in a hierarchy of directories. This is something that’s obvious to web developers, but it also means an editor should consider hierarchy. You usually have a common point of reference for all files and directories within the hierarchy. This common point is often called the “base URI”.

When I edit web documents or files, I have to deal with one hierarchy in two or more places. There’s a server-side base URI, where the files really live, and a client-side base URI, where I edit my local copies before uploading changes. Plus, if I’m doing any sort of server-side processing of XML, I probably have a staging area where I do tests away from the production website.

So I figure content I control belongs in a repository, with its top being a base URI. That lets me maintain multiple repositories if I want: a virtual one for on-the-fly editing, a local one where the files are directly accessible, a staging repository for testing, and a production repository for the actual files. At the same time, I don’t have to use a repository structure if I’m editing individual files.

When you add it all up, it becomes ultimately an issue of user capabilities and user interface. Users will want the ability to edit stand-alone XML documents, and users will want the ability to edit interdependent XML documents. So the Verbosio back-end core code must be scalable to the repository model, while the front-end user-interface must be able to force a singleton model on the back-end. It doesn’t work any other way.

No, none of this is talking about FTP uploads, CVS or SVN repositories, or any publishing methods. This is strictly about how Verbosio will refer to documents and files it edits. Publishing, while very important, comes later.

Creating XPCOM interfaces to store the needed information is easy. The hard part is in coming up with an intuitive user interface for matching local files (or directories) to remote locations!

Verbosio project officially launched

Verbosio project home page

With the completion of the virtual: protocol handler and virtual file service, I decided to begin releasing bits and pieces to the community at large. With that, I created a “grab bag” directory, purposefully not organized according to the final Verbosio source, and launched the Verbosio project with it.

Over the next few days, I’ll be adding more goodies to the grab bag, pieces which will become part of Verbosio, but are not there yet. The grab bag is just temporary housing while I figure out the structure of things to come. There is no prototype Verbosio editor available yet, but I’m working on it, and may have something soon.

Feedback is welcome!