Now Verbosio can delete a range of nodes and undo that deletion.

I actually was scratching my head last night trying to figure out how I’d break this thorny problem down into manageable pieces. This morning, it occurred to me mozilla.org’s
editor code had already solved this problem in the old Composer application in SeaMonkey, with a DeleteRangeTxn class. If I could create instances of that class from chrome or JS-based component code, I’d be in business.

Unfortunately, nobody seems to have done that before, either. So I filed bug 363290 for that. The patch is in the review pipeline.

I also found out, from reading the code behind this old transaction class, that I needed a nsIEditor object..

. something I’ve been avoiding until now in Verbosio. So I wrote up a quick & dirty nsIEditor component with most of the methods and properties not implemented. I expect, right now, to use it only as a placeholder for other calls into native transaction code.

If ETNA and Verbosio merge, hopefully ETNA will have a more complete nsIEditor implementation, and use it better than I do. For now, it’ll work, though.

I estimate that it would have taken me at least a week to implement deleting a selection from the document before I thought of Composer. By reusing that code, I reduced my implementation time down to about four hours (nine to ten if you count the long breaks I took today.) That sort of time savings makes me a happy coder.

Verbosio can now edit text nodes.

That may sound like very little (“sixteen months of work on this, and the best you can do is edit a little string of text?”), but I’ve put a lot of effort into building infrastructure. Just editing text nodes itself turns into a little hassle

. Text boxes work differently with keystrokes and clipboard pastes, so I had to handle that carefully. I also had to give people the impression that their changes in the textbox were live (that is, the text node updated as they typed) while letting undo work. My work this week has been centered around handling that case in a somewhat predictable manner.

On top of that, it’s not sixteen months of work on just Verbosio… I’ve had to set it aside often, for weeks at a time.

Really, this is just the tip of the iceberg. Now I can work on more interesting abilities, like deleting a range of nodes and undoing that, or changing attributes on an element. Later on, well, things will get very sweet indeed.

I had hoped to have a certain list of “immediate to-do” items finished by now, per my previous blog entry. Instead, I got sidetracked. Royally.

First, I ran into an as-yet-undiagnosed layout bug where the DOM had all the nodes in the right place, but certain XBL bindings were not applying. This caused me so much grief that I set the problem aside after a couple days banging on it alone. Then I had a few Bright Ideas.

To spare people who don’t care (because this is a long blog entry), the rest of this article is in the extended section.

Continue reading Verbosio progress, 12/2/2006 →

I’m continuing to build basic functionality for Verbosio, my extensible XML editor project. Remember when I said “Designing an editor is hard“, not once, but twice? Well, hard problems just slow me down. They don’t stop me

. 🙂

Right now, the following things work:

• Opening a XML document.
• A DOM Inspector-like tree view rendering.
• Selecting a sequence of nodes in the view.
• Opening the extensions manager and error console.
• Context menu and editing menu for undo, redo, cut, copy, paste, delete (the items appear and show enabled/disabled status, that is).
• XPath Generator from mozilla.org bug 319768 is now temporarily a Verbosio extension.
• Recompiling IDL interfaces on-the-fly
• Synchronizing between the source directories in the repository and the object directories where the XULRunner application lives.
• Undoing and redoing transactions (what the user actually does).

The last is a “maybe”, because I haven’t got any fully-fleshed-out transactions to do or undo. The first transaction I’m attempting to implement is a delete transaction. In the world of single DOM nodes, a deletion is easy. In the world of a range of nodes (think selected hypertext), it gets more interesting. That is, deleting is easy, but undoing the deletion is more interesting. Especially since there are several possibilities with ranges which I have to consider.

My immediate to-do list for Verbosio looks like:

• Finish implementing and testing the Delete command for XML documents.
• Implement a rudimentary Copy command.
• Implement a Cut command (Copy + Delete).
• Implement a Paste command.

• Implement saving and closing documents.
• Make exiting the application check for unsaved documents.
• Implement a “Preview mode” viewer for documents.

With luck, I could have the above done in a week. Beyond that, my longer-term to-do list for Verbosio includes:

• Writing a basic XUL-based SVG editor (or finding one that’s already out there and adapting it) for Verbosio.
• Implementing markup templates into Verbosio itself, and the template generator.
• Finishing the XBL language pack.
• Adding chrome editing capabilities.
• Editing a XUL application or extension as a complete project (what Verbosio calls a “document pack”).
• Creating back-up copies of files in the event of a crash.
• Properly using the virtual:// protocol I created earlier.

Of the longer-term list, only the first two or three are requirements for a version 0.1 release of Verbosio. At this point, I’m down-scaling my lofty ambitions for the 0.1 release. It’ll still be a good little editor if I meet the above targets, just useful enough for developers to start working with. For now, that will be satisfactory.

I don’t like “satisfactory”. I like “excellent”. But after a couple years of slogging through this code and other projects, “satisfactory” will have to do for now.

P.S. I also bought a new MacBook on Friday, to replace the laptop that collapsed a few months ago.

Over the last several days, I’ve been working on getting some basic functionality working in Verbosio again, picking up where I left off several months ago. I realized as I was working on this that I had two separate interfaces, one of them exceedingly minor, that could and should be merged. So now, language packs (which describe a particular XML language) will also be able to do some basic validation of their contents.

As part of that, I started thinking about XBL, which I hope will be the first XML language Verbosio will be able to usefully edit

. XBL documents, fundamentally, are a mix of XML and JavaScript. So to make sure a XBL document is “valid” (that is, readable by Gecko products), I can combine well-formedness checking in XML with syntax checking in JS… very, very carefully.

The result is a partially-written, untested JavaScript component which does a whole lot of legwork to handle implementation elements, and will soon do similar legwork on handler elements. One factor of the design (which complicates it, but will make it very cool when I get it working) is to figure out where a JavaScript syntax error is in the XBL document and generate a full error message, complete with source code line and exact line number. I’m fairly certain I can pull it off.

Here’s a sneak peek at my “XBL language pack component“. The function in question here is called “getFirstSyntaxError”. Under normal circumstances (no error at all), it would return null. There are probably a dozen little bugs (and half a dozen big ones) lurking in there, but I think I’ll make it workable in the next few days.

If I do succeed at this, it opens up a whole new avenue for Verbosio, as a proof of concept. XUL, XHTML, and SVG documents can all have inline scripts (though not in as complex a structure as XBL does). By mixing XML well-formedness with JavaScript syntax checking, Verbosio could help page authors fix simple bugs on the fly.

For editing XML, I wanted to have some sort of template system, where XML markup could be abstracted into a simpler system for reusability and flexibility. I didn’t know of any standardized template system like that, so I wrote one.

Designing the mental model proved relatively easy: XBL’s anonymous content design was inspirational with its <xbl:children/> element. I also needed a repetition model, though, so I came up with a repeat element as well (very different from Web Forms 2’s repeat element). I also wanted to separate the UI from the actual output of the templates. Finally, I wanted to provide, in the design, at least, placeholders for custom XML and JavaScript to override what the template normally does.

Making all that work took a lot longer. So long, in fact, that I created an “experimental” section of Verbosio’s CVS repository to work on it in a minimal-code environment, long enough to get the basics working.

I finished the functionality parts of the XBL bindings two days ago. Then, because I knew no one but me would know how the thing worked, I spent several hours documenting it.

Verbosio’s markup language specification, version 0.1.0.

For those of you with XULRunner trunk, and a desire to see some of it in action, read the full article link for details on testing it.

Next on Verbosio’s agenda: creating the XUL wizard for creating markup templates from already-existing XML markup. If you want to edit XUL, XHTML, etc., and you’ve got samples on hand, this tool would guide you through creating templates you and everyone else could use. Good stuff cooking.

Continue reading Verbosio markup templates: check →

A few minutes ago, I completed a set of XBL-based bindings

. This set of bindings implements a repetition model (somewhat dissimilar to Web Forms 2’s model, but workable for now), and uses one group of user-interface elements to set attributes for another group of UI elements.

In English, I’ve made a significant step forward in having XUL edit XUL.

There are still a few issues to work out (extracting the edited XUL from the binding, and feeding XUL in for editing, and making the edits nearly-WYSIWYG… they apply, but for some reason you can’t see a radio button’s label change). The source code is at http://www.mozdev.org/source/browse/verbosio/experimental/templates/chrome/content/editorTest (see elementTemplate.xul and elementTemplate.xml). Be aware this code is experimental, so it will change in the near future.

XUL for editing XUL has another benefit. Because I would use XUL for editing other XML languages (based on my One for one blog entry), I can use XUL to create the XUL-based editing templates for each language.

Verbosio follows this “One for one” concept. Individual language-specific editors become extensions. Now, it’s becoming feasible (not just possible!) to build at least basic extensions with Verbosio itself. That’s what I call eating your own dog food. I’m not there yet. But it’s in sight.

Verbosio logo (draft)

I decided to try my hand at a bit of artwork tonight. I’d been wondering what sort of logo I’d use for Verbosio, and this came to mind – another reference to XML, and to writing.

Opinions? Has this sort of logo been used by someone else before? I’d hate to infringe on someone’s trademark…

UPDATE: The general consensus is that it is unique (yay!), but a bit basic. To me, that’s okay for now

. I’ll gladly accept contributions of new SVG markup (preferred) or PNG graphics that do the logo in a better way. Just please don’t hold any license on it; I’m not sure what licensing to hold the logo under for the project anyway, considering Verbosio is open-source, low-budget and likely to stay that way…

There are so many things wrong with Verbosio in its current state that it’s hard to keep the faith, and keep going. A number of large issues have been bubbling around, the biggest one being that I can’t support WYSIWYG editing. But that’s a discussion for another day.

Because Verbosio is intended as a complete application, involving a combination of chrome, content, and extensions, getting a proper development environment is notably a struggle. For example, I simply forget how to recompile IDL files after I’ve made a change to them. IDL’s are actually pretty important in Verbosio, so that barrier alone to development is tough.

On top of that, I frequently make changes to Verbosio code, and forget to move it back to my Verbosio repository. I’ve probably got six or seven complete copies of Verbosio in various states of disrepair, and so by not using the advantages of CVS revision tracking (SVN would be better, but mozdev doesn’t have that yet), I have allowed myself to lose pieces of code in development… which is even worse than outdated IDL’s.

So on Friday evening, wanting to get myself organized, I grabbed Mozilla Sunbird 0.3a2 (I’m a developer – alphas only frighten me a little), and started writing down some of the unfinished business I have with regard to Verbosio and mozilla.org bugs. It turned out to be a big list… and the first thing on it was to simplify the development process between repository and objdir’s. In other words, time to write some Perl and shell script code.

Now, I’m not all that great at Perl. But over the last year at ManyOne Networks, I’ve been exposed to more than a little of it

. So with a handy Sams Teach Yourself Perl in 24 Hours guide, a few script subroutines borrowed from work, and an unhealthy bit of trial and error… I got a basic make-project.pl script written to handle exporting repo code into objdir code, and set up for the reverse.

I could have written it as a Makefile, I suppose… but Perl seemed to have more of the capability I needed. The Makefile will of course call on the Perl script… later.

Just to write this one script has literally taken me about 18 hours in pretty much one straight shot (one break for food, and another break for Saturday night anime). Along the way, I learned a few things:

• XPIDL generates .xpt files for one IDL file. To get more than one IDL into a .xpt, you have to use xpt_link. I think it was shaver who told me that…
• Mozilla’s cygwin-wrapper doesn’t like /tmp. Imagine that. I can’t really blame them, though.
• I am woefully inexperienced with shell scripting.
• I really should learn more about Perl, in particular Perldoc.
• I should also find or write a common assert() & design-by-contract functionality for Perl. die()’s okay, but not great. I like debugging structures in any programming or scripting language. (Maybe I can ask Damian Conway nicely for it. If he can handle Klingon with Perl…)
• Okay, I didn’t so much “learn” as “already knew” this one: when one doesn’t eat for over 15 hours, including sleep, a mental numbness begins… I skipped breakfast and lunch, and my dinner was at about a quarter to nine PM here. I last ate at about 1:30 am. I actually wanted to leave about 5 PM, but it took me another three hours to get my code to a stable-enough setting (i.e. no more “Just one more change to get this working”) where I could walk away.

I woke up Saturday morning about 8:30 AM. It’s now 3:15 AM Sunday. Marathon coding sessions for me are relatively rare, but they do happen. Kinda like when I was writing my book for Sams Publishing – though I’m not planning on doing 40 hours without sleep like I did five years ago. I’m going to bed now.

Incidentally, I’ve been spending a bit of time lately writing patches for mozilla.org trunk code, just to support features that a editor like Verbosio should have. Patches that really make Verbosio moderately useful.

I’ll take suggestions on CPAN modules for design-by-contract…

In designing Verbosio, I made an assumption that said ID attributes were going to be troublesome. Simply put, every ID attribute must be unique to the document. But when you include fifty or more overlays, somewhere an ID attribute being not-so-unique is a distinct possibility.

To solve this, I introduced a concept of scope and local id combinations. But this alone was not enough. What about XUL’s command and key attributes, which are inherently tied to ID? These were IDREF-type attributes for all intents and purposes, and I could not support them.

Until today.

I conducted an experiment where I set ID attributes after the XUL document had finished loading. I also set command attributes. This mimics how Verbosio would work to a great deal

. Surprisingly, it worked perfectly. One of my biggest fears about Verbosio development has evaporated.

A demonstration of scope and local id, with local id refs, combining for ID and IDREF attributes. It apparently doesn’t work in Firefox 1.0.7, but does work in a SeaMonkey trunk and 1.8 branch SeaMonkey. So Firefox 1.5 users should see it too.