Verbosio progress, 02/24/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.
In no particular order, here are my commit messages from 02/19/2007 (the last blog entry) to 02/24/2007:
- Initial landing of chrome registry viewer for XUL application document packs.
- Include a method to get all chrome package names from a chrome document pack.
- Add chrome document pack interface, and implementation in XUL application document pack.
- Add JavaScript language pack extension to the build process.
- Initial landing of XUL language pack code.
- Base URI maps will no longer be responsible for handling wrappers; that responsibility goes to the document packs.
- Silence dump warnings for nsIClassInfo.
- Add base URI lookup test with reversed order for install.rdf base URI lookup versus chrome URI lookup.
- Add initial test harness for component-driven tests.
- Actually open the testing app in Verbosio, instead of just preparing to launch it.
- If a file is already open, don't open a new document wrapper for it; just focus on the file's wrapper tab.
- Fix thrown errors for closing a document, reopening it.
- Move openDocumentPack, openDocument, closeDocument, saveDocument into the verbosio object. Also, if a Verbosio window already has a document pack, open a new window for the new document pack.
- Add support for opening a document pack as the first argument on the command line, or as window.arguments[0] via nsIDOMJSWindow.openDialog().
- Follow-up to mozilla.org bug 370742, which fixed many bugs in tab bindings; this patch fixes a regression caused therein.
- Use document pack to open document wrappers, and restrict it to wrappers for which we have an established component class.
- Remove the need for language packs to implement nsITransactionListener. Transactions shouldn't be changed by a transaction listener anyway.
- Localization fixes.
- removeDocTab should consider unsupported viewers for a wrapper, and go back to the first document pack tab.
- Document wrappers, when initializing by a file, should take a document pack. The document pack will provide the base URI for the document, and for other documents the wrapper requires.
- Minor adjustments to XUL application base URI look-up, per test results.
- Use a more standard scope id for the XML inspector's JavaScript scope.
- Show the user the original doctype of the document.
- Store a reference to the document pack (we'll need it for DOCTYPE fix-ups), and get the transaction manager from the document pack.
- Add JavaDoc and interface references for methods in component.js.in.
- Add category manager registration code to Module.
- Make opening a document in the directory contents viewer the default action of a user double-clicking on a tree item. Also bold the open files item in the context menu.
- Add new screenshots for file system, chrome directories.
Posted by WeirdAl at February 24, 2007 7:07 PM
Hmm. I wonder how I missed this blogpost - regardless, I'm curious how you're accessing the list of another application's chrome, as well as whether I'm reading that dialog correctly in that it lets you edit that chrome. Does it? :-)
(From Alex: I use a JS component that reads the chrome.manifest files and builds a registry inside the component. I'm not so much reading the other app's chrome as building my own map for it. Then other extensions for Verbosio can read that map.)