Lots of little things since my last update:
What does the last item mean? Think of software applications as objects (like fruits). Verbosio is an application (let's say a pear). Currently, when you run make-project.pl for Verbosio, you don't get one copy of Verbosio; you get two. (Cloning digital pears is cheap.) The first copy is the "default" copy, and uses the "default" profile. The second copy is a "testing" copy, using a "testing" profile. The default copy can open the testing copy.
Why would I want you to do this?
Verbosio's design is for a very scalable XML editor. Verbosio itself is mostly written in XUL (a XML language), XBL (another XML language), and JavaScript. So out of the box, Verbosio has strong potential to edit two of its three major language components. The third, JavaScript, Verbosio will also support editing. JavaScript is an integral technology for the WWW and for Gecko-based products and extensions in particular. Editing JS in Verbosio would eliminate another barrier for using Verbosio in the real (virtual) world - and move Verbosio closer to a "dogfood" status.
Alas, I'm not there yet. I knew instinctively that mozilla.org's XMLSerializer (which I do use a bit) wouldn't produce exactly the same document as what the user put in.
Case in point, these days I usually write my XML markup like this:
<vbox>
<textbox id="myTextBox"
multiline="true"
rows="20"
cols="15"
/>
</vbox>
Your way of writing XML will probably differ greatly. However, Verbosio currently treats this as:
<vbox> <textbox id="myTextBox" multiline="true" rows="20" cols="15"/> </vbox>
It might be technically accurate, but it enforces its own code style on the user. That's really annoying, especially when you have to deal with a version control system like CVS or Subversion. I also have issues with expanded entities in <!DOCTYPE > tags.
So I'm going to make a special request now. I'd like people to comment to this blog entry with different examples of XML source code conventions. I need test documents, so I can write a "preserve source formatting" functionality for Verbosio. Please paste links to the examples; don't put the examples in-line. Please also make sure for longer examples that they are internally consistent (and as different from other posted examples as feasible). I'd really appreciate some basic "litmus tests" for this.
In the meantime, I'm going to work on other easy-fix items for Verbosio, such as closing a document, and on some larger-scale items, like opening a chrome CSS stylesheet by clicking on a link in a XUL document.
The second major piece of Verbosio 0.1, its XML Inspector extension module, is now in a semi-stable, "alpha" state.
The first major piece, the core architecture, isn't there yet. I have much more work to do, including implementing the other ten major pieces, before I can declare victory on that.
Recently, someone commented that they thought Verbosio was "just a fancy DOM inspector-type thing". Given what I've been talking about for months now, this is a very understandable assumption. Indeed, the XML Inspector module takes its inspiration directly from DOM Inspector (thank yous go out to hewitt, timeless, caillon, sdwilsh, and all the other contributors to DOM-I...), but actually is a completely new code base. Most of the features you find in DOM-I you won't find in this module. Many of the features are too much for Verbosio's needs, and a couple things Verbosio needed that are unlikely to return to DOM-I.
What will you find? Well, I've preserved the DOM Nodes view (that's your tree representation of the DOM). On the right hand panel, you'll be able to edit attributes, comments, processing instructions, text and character data nodes. You'll also be able to add attributes to elements. So far, nothing new.
Oh, and you'll also be able to create new elements from scratch. That's something DOM-I doesn't let you do right now.
Screenshots? You want screenshots? Okay. I'll give you screenshots. Bear in mind the whole UI is in a very early state; better editing capabilities than ordinary textboxes are on the schedule.
The biggest thing to note, though, is that I've developed 90% of the code the XML Inspector module uses for another major piece of Verbosio entirely. It's for the Verbosio markup template system I blogged about three months ago.
Although I've not yet marked any bugs fixed, I realized I needed to write down some of the core concepts in Verbosio, at a high level (not just code documentation). So I started writing the Verbosio Developer's Manual, first unofficial draft.
So if you have any interest in how it's supposed to work, well, here you go. The manual covers the core concepts in Verbosio that I've been working on for the last couple of years. This should clear up a lot of questions people may have about Verbosio, and hopefully help you understand what I'm referring to when I start babbling.
Feedback on this Developer's Manual is welcome!
Also, for anyone interested in talking with me directly about Verbosio, I've decided to maintain a #verbosio channel on moznet. Just look for WeirdAl (that's me) for whenever I'm signed in to moznet.
A few weeks ago, I talked about reusing code. Working on a similar problem, I found that reusing pre-existing Mozilla code isn't as easy when the code doesn't exist.
Take Composer's Paste command. It takes content from a clipboard and inserts it, sometimes wiping out the pre-existing content to do so. But a paste-content transaction is not a paste-content command. As there's no obvious transaction class which handles that, I'm stuck. I need a transaction so I can do, undo and redo the paste.
Martin Honnen in the m.d.t.dom newsgroup posted a simple solution for one part of this problem, doing the insertion. I replied, wondering how to undo it. This morning, I think I solved my conceptual problem... in an unorthodox manner.
Whenever an application changes a DOM node in a way, Gecko looks for a mutation event listener for that type of change. If one or more such mutation listeners are applicable, Gecko dispatches a mutation event, and the listeners pick it up.
A transaction, via its doTransaction method, can modify a document in a number of ways, but the types of changes (as far as the DOM and event listeners are concerned) are finite and well-defined. So while the transaction acts on a portion of the document, a specialized set of event listeners can get all the details of the changes. If those details are recorded as a property of the transaction, then undoing the transaction becomes relatively simple: just undo the recorded actions in reverse order. Redoing the transaction is equally simple.
So a few more library functions, and now people who write editors for Verbosio's XML documents may only need a doRecordedTransaction() (meaning "go forward for the first time") method. Undo and redo are just absorbed into the master application; authors won't have to write specific code for those cases.
This means another API change to Verbosio (I am making too many of those), but it's early in the process and not too much code rewriting. Sure, the application has to work harder, but that's all right. It's more good stuff for extensions down the road.
During the winter break, I mostly spent my time off, dealing with various family issues, including the death of my grandfather.
I also implemented adding an attribute to an element. This is significant because it is the first editing action which couldn't be done inline. Other edits to date have been text node changes, or deleting a node -- stuff that doesn't require a lot of detail. A new attribute can have a namespace URI, a prefix, a local name and a value. That's four different input fields.
DOM Inspector does this (thanks to bug 205872 and Shawn Wilsher) through a dialog. But I've long understood that, as I say in the Verbosio overview, "Dialogs are exceedingly annoying to the end-user." To solve this, I came up with the idea of an inline <xul:precondition/> element binding. I had even written some mockup code in July 2006 to express how Verbosio should handle preconditions.
Mockup code is, naturally, not real-world code. Over the break, I realized the code was not workable and had to be scrapped. Good intent, presumably good UI, just not usable. A bit of rewriting, some debugging and a real-world application (adding attributes) later, and the code is now operational.
Next on my to-do list is a bit of code reorganization; I wrote a lot of code just for this Inspector-based feature which I expect I'll be reusing in a more global setting for Verbosio (the XML template editor I talked about a few months ago). I'll also be implementing the ability to insert new content into a XML document (something I know DOM-I doesn't do right now). Both of these will be done via the precondition model.
Lastly, for several months I've been hunting for a book which describes best practices in user-interface design. It's one thing to have technical references on UI elements. It's something else entirely to know how to design a user-friendly UI. The Firefox UI team succeeded at this brilliantly and raised the standard for the rest of us! So I've been scratching my head trying to figure out what's good and what's bad in UI design, and there is an astonishing lack of written work about that.
Two days ago, I found "Designing Interfaces", by Jenifer Tidwell. I think this book is exactly what I've been looking for - I've only gotten into it about three chapters, and it's a fairly well-written guide. More importantly, it's not a code-based guide. It guides readers towards sensible, useful user-interface layouts and the motivations behind them. I think anyone doing lots of UI work should take a look at this book, and UI reviewers should probably read it too (though they may find they already know most of it).