Gradual progress lately. I’m still building pieces I need to make Verbosio a relatively smart editor.

First, as Myk Melez talked about Komodo Edit, and Robert Accettura followed suit, I decided to get Komodo Edit 4.0. It just came out of beta. Like it did for Myk and Robert, it has replaced my standard text editing environment(s). I won’t reiterate the features they pointed out; suffice it to say I’m pretty pleased with it so far.

Continue reading Verbosio progress, 02/18/2007 →

Earlier today, I realized I need to search the local file system from Verbosio. There’s really no such capabilities in native mozilla.org code. So, I built a basic file search capability on my own, and checked it in to Verbosio.

See the Full Article section for more details. (I also introduce a new way to implement multiple XPCOM components in a single JavaScript file.)

Continue reading Searching a local directory from Gecko →

Textbox demo

I had an idea late last night: what if I could position UI for configuring a XUL element without moving or resizing that element? This would give a decidedly WYSIWYG feel to editing XUL interfaces.

The above link is a demo of one way this might work

. In essence, I’m emulating the <xul:popup/> element, but with XUL controls included and working. I’d like your feedback on it, including good practices for opening and closing the “context” box, and accessibility support.

There’s also some strange happenings with shift+tab which I’d like help figuring out.

UPDATE: The shift-tab issues are bug 306058.

While I tried to clean up source code editing in Verbosio, I ran into a serious problem: mozdev bug 16341. Basically, the XML document I was editing was pulling in DTD entities from the Verbosio application, not from the document’s intended chrome URL’s

. In other words, Verbosio was getting confused about where to get source code from.

This little mistake is not easy to fix, unless Verbosio knows something about the context it’s working in. This goes back to the question of “stand-alone” editing versus “repository” editing (which I tried, and failed, to define in a prior blog entry). Stand-alone editing means a bunch of files which are not related to each other. Repository editing refers to files which reference one another and/or link to one another, so edits to one affect other files as well.

For XML files which refer to other files (like localization DTD files), stand-alone editing cannot work. The entities in external files must load, or the XML document is not well-formed.

(Yes, I know Mozilla does strange things with external entities, that don’t follow the XML spec. Deal with it. I have to.)

I had gone for stand-alone editing first, figuring that was going to be very simple. Now it’s a stand-alone complex (pun intended) and a major (pun again intended) design flaw.

The solution, for now, is to implement a whole bunch of features I didn’t want to implement this early. More importantly, I have to break stuff to fix stuff, again. This will give me basic support for one type of repository editing: XUL applications and extensions.

I had hoped to have Verbosio 0.1 ready in time for OSCON 2007 in Portland, OR. I seriously doubt that’s going to happen now, but it might be halfway usable by then.

It’s not all gloom and doom. Today I checked in the first big piece of the new approach: a file-system tree viewer. I’m almost certain I could have used a RDF datasource for this (rdf:files), but I needed this in a hurry, and RDF in XUL is something I still don’t fully get. So I went with what I knew. If anyone wants to base this on RDF, I’ll take patches.

Lots of little things since my last update:

• Source code editing (with some serious bugs for XML)
• Minimal support for editing text documents
• Saving documents Verbosio is editing
• Using Verbosio to launch another copy of Verbosio

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.