A few days ago, Benjamin Smedberg astutely summarized his thoughts on a XUL IDE: “I like this dialog, steal it”. Now, that wasn’t the point of his blog entry, but it did leap out at me.

You see, I’ve been talking for over two years now about Verbosio. In particular, I’ve been talking about this markup template system, and how you could build markup templates for Verbosio in Verbosio, etc., etc., etc. But I never found a nice, short way to describe what my intent was, until Benjamin (accidentally, and without his knowledge) did it for me.

Verbosio’s markup template system is all about “stealing” code.

Now, I want to be clear: I don’t mean stealing code in the sense of taking someone’s copyrighted works without their permission. You should never use any editing tool to plagiarize someone else’s work. For XML documents under an open-source license, however (MPL/LGPL/GPL, anyone?), it’s fair game. Besides, by the time you’re done creating a template, it’s highly unlikely the template will more closely resemble the original than it would resemble any other similar piece of code.

Below are a couple of screenshots of a wizard I’m building

. This wizard will let you take a fragment of XML written in a given XML language (in this case, XUL), and transform it into a Verbosio markup template. The template (specifically, its user interface) appears in the upper-right corner of the wizard. The upper-left corner lets you select nodes to edit for the template. The bottom panel is where you would set up the attributes and text contents of the template.

You can accuse me of building a really bad user-interface in this wizard, and I would accept that criticism without shame. My goal here is to build something that works, for a proof-of-concept release. I’m still working on this wizard, to be honest. But here I’ve accomplished the hard part: taking a minimalist XUL element (<xul:button/>), and building a template for that XUL element. A few dump() statements in the background show the template even works – you can change the button within the template. (Don’t knock me on the attribute name column – it’s a placeholder for real namespace-aware attributes.)

Now I have to integrate the above functionality (which took me at least two days of code on this alone, and several weeks of design speculation) into Verbosio’s core, and create a complete path from unknown element to new element template. That’s coming, hopefully by the end of the week.

I keep telling myself I’m two to three weeks away from a proof-of-concept release. Unfortunately, finding those weeks is proving very difficult. Hence, not much outward progress on Verbosio lately.

Just a way you can edit DTD entities with the XML you’re also editing!

It also is a little dynamic:

Finally, the changes you’re making don’t apply until you hit the “OK” button. If you then open up the DTD document, you’ll see the DTD itself also has the new value:

I had originally written this so the DTD entity would be exposed beneath the attribute value, so you could change the DTD name and value by independent textboxes. One glance at that user interface told me it wasn’t going to work – it was going to be non-obvious. So I redesigned it from scratch. The “goalposts” you see in these images are actually SVG markup, living anonymously within a XBL binding on a <markup:entity-box/> element inside a XUL document. That’s four different XML languages, plus JavaScript – one of those languages being a graphics language – all working together to give an unique look and feel which I hope is intuitive. XULRunner 1.9a5 just smiles at this and says, “More, please.”

The effects aren’t perfect, and neither is the implementation. For instance, if you type into the textbox something larger than the textbox’s visual size, the goalposts move outside the textbox’s horizontal boundaries. Also, actually committing the changes (clicking “Ok”) does far more DOM operations than are strictly necessary. Here, all that Verbosio should need to do is a few attribute modifications, but in reality it also does node insertions and removals. So the code, while functional, needs some optimization.

The change log, as usual, is in the extended entry.

Continue reading Verbosio progress, 06/10/2007 →

Well, why not?

I’ve been thinking for a while that Verbosio could bring a lot to the table if you could use it to work on Firefox extensions. Fundamentally, it would be trivial to add support for that to Verbosio.

Verbosio is a XUL application I’m building for editing XML. That’s its fundamental goal. For the 0.1 release, Verbosio’s first requirement is the ability to reliably edit Verbosio. That means Verbosio needs to understand XUL, XBL, a little JS and a little CSS, DTD… all things that you need for a Firefox extension editor too.

I really do think I could add support for Firefox extension development in a day

. It’d be as simple as creating a single component implementing xeIDocumentPack. That same component would mean support for editing Thunderbird extensions, NVu extensions, Sunbird extensions, Songbird extensions, Flock extensions… you name it, if it’s a XUL-based application extension, Verbosio could probably start editing it with that single component.

So I’m thinking I should add a second requirement to Verbosio 0.1: “Verbosio should be able to edit Firefox extensions reliably.” With that one requirement met, Verbosio would be significantly more useful to the Mozilla community at large, and it would invite people to look at Verbosio more. That might be enough eyeballs to make my bugs shallow.

UPDATE: Done! Now you can open extensions in Verbosio for editing.

It’s meat and potatoes time.

As I’ve mentioned in earlier posts, I’ve spent some time creating a “preview” or rendered view of a XML document the user is editing:

Of course, seeing the document alone is no fun. You want to be able to edit it. That’s what Verbosio is for.

So let’s say you hit Ctrl+E (right now you have to click) on the selected menu item. What do you get? How about, oh, an interface for changing that menu item’s properties?

This is what I’ve been dreaming of for the last year and a half: a way to edit XUL on the fly, visually. (Of course, it’s not just XUL – not in the long run. XUL’s simply what I chose to work with first.)

It’s also supporting my vision for Verbosio: having extensions drive most of the work, while Verbosio handles the common tasks. The preview viewer is provided by a Verbosio extension. The yellow box is provided by Verbosio’s core, while its contents (the “XML markup template”) come from another Verbosio extension. Support for the document you see comes from the same Verbosio extension as the markup template, a XUL language extension. The XUL language extension also provides some metadata about the XUL language in another component (including some basics about how to handle whitespace). Another extension told Verbosio how to open the chrome application the user is editing.

This is a starting point. I’m going to expand it soon, so that you can:

• Work with sets of elements (like radio buttons inside a radio group, or cells in a table)
• Build your own templates within Verbosio, using documents you have open in Verbosio
• Edit DTD localization entities underneath the labels you see
• Create templates for creating new documents in supported XML languages from scratch

Sometime after that – once I fix other API issues and some pretty important regressions – I’ll release Verbosio 0.1 alpha 1. My changelog is in the extended entry.

In the meantime, I’m also very aware of the need to get other eyes on the code behind Verbosio. Just recently, Paul Rouget borrowed my chrome registry viewer code for his CodeEditor tool. That to me is a solid vindication of what I’ve been trying to do.

At the same time, the entire Verbosio code base is unreviewed and only partially documented. Sooner or later, I’m going to need volunteers who are willing to work with Verbosio – and me – and improve the hackety-hack code I’m crafting from scratch. Very little of this code, as it now stands, would pass any realistic peer review. So I will start asking, as of now, if other people want to directly involve themselves in the Verbosio project over the next few months.

I just want fellow developers to start thinking about it. I couldn’t really do that before, because it’s so hard to put into words what Verbosio is all about. Now, hopefully with the screenshots above, the vision can become clearer.

For now, though… the steak’s on the barbecue.

Continue reading Verbosio progress, 04/26/2007 →

The goal is in sight… literally.

A few days ago, I checked in another viewing extension to Verbosio, one that shows you what the document would really look like. It’s not editable yet – it’s just an iframe – but at least now you can see what your changes do to your document. (No screenshots yet – what’s so pretty about an iframe?)

It also means I’m finally done writing mostly component code and now I can get back to writing mostly chrome code. I can finally make Verbosio into an editing application instead of a clunky DOM Inspector clone. 🙂

I’m working now on integrating my markup template system with the visual rendering. Just this evening I landed sample code from the experimental branch to mark a starting point. I’m also beginning to figure out a little more clearly what Verbosio and its extensions need from each other.

Already I’m thinking about a Verbosio 0.1 alpha 1 release in the near future (read: within a few weeks). I will have a very tough time deciding what makes 0.1a1 and what should come later, though.

The changelog since March 7, 2007 is in the extended entry.

Continue reading Verbosio progress, 04/11/2007 →

When a XML editor finishes messing with DTD’s, the next thing which comes to mind is entity references (&foo;). In the case of Mozilla code, these entity references don’t exist: the XML parsing code replaces the entity ref with the appropriate source code from the DTD. So the DOM in Mozilla never actually sees entity references.

This is a major problem for Verbosio

. As a XML editor, it must know where a XML document uses entity references. With that knowledge, Verbosio can then provide a user-interface which guides people to editing the DTD entity underneath the entity ref.

What makes it more interesting is that Mozilla really has no effective code for entity references in DOM. Try var foo = document.createEntityReference("bar");. You’ll find out that, even if there is no declared <!ENTITY bar "...">, no error will be thrown; instead, foo is null.

How can Verbosio work around this? At present, I have an imperfect solution, a XML “entity manager”. Read on if you have any interest.

Continue reading Verbosio progress, 04/07/2007 →

The system clipboards Mozilla offers to XULRunner apps restricts us to primitive values: strings, numbers, etc. (I haven’t yet figured out how they store images, but that’s another discussion.) If you’re trying to copy a DOM node to the operating system’s clipboard, you quickly find out it’s not that easy.

Since Verbosio’s a XML editor, heavily reliant on the DOM, what am I supposed to do? Well… I cheated. Read on for more details.

UPDATE: A few commenters have suggested I have erred. I’d really appreciate someone coming up with some sample code to demonstrate a better way, using the native clipboard. (I may or may not use it, but it’s nice to know.)

Continue reading Copying objects to an application’s clipboard →

I wouldn’t normally post again so soon, except that I have finally fixed Verbosio bug 16341. A little string replacement, and I’m finally able to generate a clean DOM.

Thanks to Ben Bucksch, who was willing to give up a bit of sleep to help me decide what to work on next. That would be clipboard operations – copying being the more difficult one, because that would mean copying nodes

. It’s not as glamourous as other ideas I have to work on, but it is necessary.

Robert Sayre recently told me DTD’s are just about useless. I disagree: they’re worse than useless – at least, the way Mozilla deals with them. 🙂

Specifically, the only thing Mozilla code really uses DTD’s for is chrome localizations of labels, accesskeys, etc. But if you’re dealing with chrome:// URL’s in the XUL application you’re editing, you really don’t want cross-contamination from the editor’s own chrome files. Factor in DTD’s calling on and loading other DTD’s, and you have the beginnings of a royal mess.

It’s a mess of my own making, though, because I want a complete object model for the XML documents I edit, not just the source code. Also, Mozilla’s use of DTD’s is appropriate for 99% of current uses; I just happen to require a bit more careful handling. It’s the price I pay, although hacking around it required two whole weeks for me to figure out…

More in the extended entry.

Continue reading Verbosio progress, 03/07/2007 →

The logjam has officially broken. This week, I spent most of my time adding little usability features (like opening a file when you double-click on it in a directory tree) and doing some behind-the-scenes clean-up of the code.

I also added a new feature which any XUL developer should find interesting: a chrome directory viewer. This is different than Gijs Kruitbosch’s Chrome List extension, in that mine examines the chrome registry of an outside application, and lists alternate locales & skins as well. (Not that there’s anything wrong with Chrome List; Firefox extension developers should take a good look at it.)

To do this, I added yet another Verbosio interface, for xeIChromeDocumentPack. Whether I needed this interface or not isn’t entirely clear; I didn’t find any other interface on mozilla.org which matched the needs.

As I’m still waiting for bonsai.mozdev.org (they’ve planned it for 2nd Quarter 2007), I really lost track of all the changes I’d done this week

. The list, harvested from cvs log and in the extended entry, is rather impressive, even to me.

Coming up: support for editing DTD’s, virtual:// revisited, and a fix for a Verbosio data loss bug.

Continue reading Verbosio progress, 02/24/2007 →