Slashdot is carrying a story about the Eolas patent on plug-ins being essentially valid. I would really appreciate hearing from mozilla.org personnel what sort of impact this might have on the various products. I hope the answer is "none"...
Because this is likely to be an inflammatory subject, I'm going to close comments on this blog entry. I'd prefer someone from the Mozilla Foundation or Mozilla Corporation take a moment to respond publicly.
People who know me know I don't drive. They know I'm a big fan of public transit.
So I was a little annoyed Wednesday morning. Apparently, mudslinging and grandstanding are the order of the day now.
I'm hitting an interesting problem for Verbosio. Specifically, I can't figure out how to take a XUL file and convert it to a XUL document.
I've considered several ideas so far:
document.implementation.createDocument(XUL_NS, "xul:window", null). Unfortunately, this returns a XMLDocument, not a XULDocument.DOMParser.parseFromString(source, "application/vnd.mozilla.xul+xml"). This won't work because the XUL content-type isn't supported by DOMParser, and besides, it relies on document.implementation.document.cloneNode(false). See bug 42976, which no one's done anything on.Anyone else have good ideas? I really don't want to hack DOMImplementation right now, or implement cloneNode for XULDocument...
Background: This is about the need to edit documents containing XUL widgets (typically XUL documents). I could go with XMLDocument, but the results might be a bit hard to predict. On the other hand, I would want any XUL overlay processing instructions to be present, but not active. So I'm not sure what the right thing to do is here.
UPDATE: Thanks, Mr. Ross! That was yet another trick I did not know about! My quick tests from Venkman shows it works beautifully. There's a lot of interesting code there.
An article in the Wall Street Journal (thanks to Slashdot for the link) explains about Microsoft's decision to scrap their current work and start over.
This is probably a good thing. In fact, scrapping and restarting is sometimes necessary. For example, Netscape open-sourced their codebase for Netscape Communicator 4.x. The idea was open-source contributors would help them get to version 5.0.
That didn't happen. I can't find the exact article explaining the reasons why, but I recall reading the mozilla.org team decided to scrap that codebase and start over with Gecko. As I understood it, the codebase for Netscape 5.0 was just not amenable to doing what people needed done. The result was Mozilla 1.0 and Netscape 7. (Netscape 6 was a forgettable experience.)
I'm having experience with scrapping and restarting myself. Abacus, you may recall, was intended as a MathML editor for Mozilla. Ideally, it would be embedded in Mozilla Composer. That's not going to happen. I'm going to scrap Abacus and rewrite it for Verbosio, which is a much more extensible architecture (and is designed to support XML, which Composer is not).
I can get away with this, though, because Abacus has such a small customer base (effectively zero). With larger projects such as Firefox or Windows, I'd be a little concerned about backwards-compatibility. Netscape 6/7 decided to deliberately not support certain bug-features of Netscape 4, and that was probably wise. Be careful what you break when you scrap and start over.
I'm looking at Bug 28174 as one which I and my employer intend to fix. The catch is no one's said exactly how to do so.
As I see it, there are several things we need to do for this bug:
Of these, I know I can do #3. #1 requires C code, and I'll try to partner with one of my coworkers on this. We'll probably need some help, at least in determining where the code goes in the source tree under xpinstall. #4 is a matter of debate, and your comments here would be useful. #2 is something we will need help on; I don't think anyone here knows how to do that. It might be as simple as a XPCOM service from C, but I don't know.
My concern for the moment is just to get the checkboxes part of comment 23 working. We'll deal with other issues later.
I'll update this blog entry based on your comments. So please offer useful feedback, particularly technical details.
UPDATE: Guys, having opinions on the way you want it to appear is all well and good. But I need technical expertise on how to make it work. Any takers?
Theoretically, I could put out an initial milestone of Verbosio, my prototype XML editor, for general consumption if I spent a week or two finishing up the bare minimum functionality. But that would leave a lot of potential users (particularly the Mozilla development community) very disappointed in Verbosio. It would have rudimentary editing capability, and that's it.
Besides, I keep having ideas that just can't be ignored. Yesterday, I chatted on #developers about syntax checking for JavaScript source and possibly CSS stylesheets as well. (XML's equivalent is well-formedness.) Properly designed components could tell you if your document is unusable. This evening, I realized that the buttons for selecting nodes from a toolbar would be better done with images and tooltips than wordy labels, so I started designing a set of simple (I hope!) button images in SVG. I'll convert those to PNG images later. The new idea stream just goes on and on.
Then there's the dreaded Verbosio Manual, which I absolutely have to write. In creating the Verbosio architecture, I've diverged a little ways from traditional XUL application development. No one will write extensions for Verbosio if they can't understand how. The model I've built for extension development is a little more rigorous than I suspect most extension developers are used to, and it may not fly.
Plus, glazou has finally indicated his prototype XML editor, ETNA, is starting to come together. I really wouldn't mind being a beta-tester for that, or maybe even an alpha-tester.
I've talked about Verbosio for months now on my blog. I want your opinion: where in its evolution would you expect a XML editor project to be, before you wanted to touch it and work with or on it? I'm not talking to end-users here, I'm talking to the development community. I want to do an initial release at the right moment, but I don't know when that is from a technical standpoint.
Feedhouse readers might've missed the announcements. The SeaMonkey project has launched two blogs, one for general announcements, one for QA. SeaMonkey blog SeaMonkey QA blog
Also, release candidates for SeaMonkey 1.0 alpha are available. The blogs above didn't give checkout instructions for the source, so here's the commands you need to get the 1.0a client.mk file:
cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -r SEAMONKEY_1_0a_RELEASE mozilla/client.mk
Also copy the following as mozilla/.mozconfig (generated from the Mozilla Build Configurator)
# # See http://www.mozilla.org/build/ for build instructions. # # Options for client.mk. mk_add_options MOZ_CO_PROJECT=suite mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@ # Options for 'configure' (same as command-line options). ac_add_options --enable-application=suite ac_add_options --enable-svg
Or you can use CTho's .mozconfig file.
UPDATE: Revised to include the SeaMonkey 1.0a branch tag.
http://www.cagle.com/working/050817/ares.jpg
In a repository mode of editing (where you can edit several documents at once, some dependent on others in the same set), one could easily edit a complete XUL application. (I intend to create a demo of this as well.) Part of that could include transactions that affect more than one document at once. Here's a sample XUL document I cooked up for adding a XUL menuitem, with support for localization and creating key and command elements related for this menuitem if the user desires. This user-interface would edit the master XUL document, a localization DTD, and possibly an overlay for menus.
Improvements are welcome! There's certainly room for it. Send me an e-mail with your changes to this code; if it makes sense, I'll add it. (Don't worry about where the menuitem gets placed; I'll be working on that.) Bear in mind this UI must fit into either a sidebar or a bottom bar (I haven't decided which yet).
If you're reading this via planet.mozilla.org or feedhouse.mozillazine.org, you'll have to visit this article directly for the demo to actually work.
XULRunner is a bit intolerant in its chrome.manifest files when it comes to jarred chrome versus flat chrome. For example, I filed bug 295023 because I typically build with flat chrome, and the sample app insisted that its chrome was jarred.
There's actually a simple, undocumented way to avoid this problem. You force the build process to use a particular chrome format just for your XUL application. If you want to force jarred chrome, add this line to your Makefile.in file, after the autoconf.mk line:
MOZ_CHROME_FILE_FORMAT = jar
That's it. The build process will take that, and override the user's default setting. Alternatively, if you insist on flat chrome:
MOZ_CHROME_FILE_FORMAT = flat
XULRunner apps should use one of these settings for any Makefile.in tied to their chrome.manifest. Of course, it's not a nice thing to do in a traditional SeaMonkey application, where jar.mn rules. In this case, you're forcing your choice format on the developer building. If you can use jar.mn instead of chrome.manifest, please do.
I'm not the person you should be talking to.
I get roughly one e-mail a week from people wanting this feature to be in SeaMonkey 1.0, or that person wanting to contribute. I hate to say it, guys, but you're really talking to the wrong person. I care a great deal about SeaMonkey, but I don't speak for the project. I'm not on the SeaMonkey Council, and I probably should not be.
If you see a feature you want in SeaMonkey 1.0, your first stop should not be to write me an e-mail. Yes, I typically forward these e-mails to a Council member. But that's zero guarantee they will be acted on. Instead, you should use Bugzilla. If the bug's already filed, set a blocking-seamonkey1.0a or 1.0b flag to "?". DO NOT SET IT TO "+". That right is reserved strictly for the project drivers, I believe. If you can't find the bug after a careful search under both the Core and the Mozilla Application Suite products, then you should probably file a bug. (Note that bugs for extensions such as ChatZilla, DOM Inspector and Venkman usually exist under Other Applications, so search there too.) Please don't file bugs about extensions that live outside the Mozilla codebase.
So what do I do for SeaMonkey? Not a whole lot. I hang out in the #seamonkey channel on irc.mozilla.org often as WeirdAl; if I'm there, I can usually answer questions, but mainly to point you in the right direction. It's rare that I have the ultimate answer to your question. I try to track SeaMonkey progress for two reasons: one, my employer is considering SeaMonkey as a future codebase, and two, I want Verbosio (my personal project for editing XML) to work on it. Beyond that, the SeaMonkey project is just something I think of fondly.
I also try to organize the occasional "Town Hall" meetings, when I or members of the community feel there's a need for one. That hasn't been too often. The simple fact is, I'm not aware of any major changes that the community needs to be aware of.
Finally, I write about SeaMonkey in my blog when I feel there's news. Again, this hasn't happened often. Because there's no SeaMonkey-specific blog, I might be perceived as the only public voice you see for the SeaMonkey Council. Let me repeat it once again: I don't represent them. My views are strictly that: my own.
If you really want to help, the #seamonkey channel on irc.mozilla.org is always open. It might take a while to get a response. Also keep an eye on the SeaMonkey Project Home Page.
When I switched from SeaMonkey to XULRunner as a basis for developing Verbosio, I hit a snag: certain chrome overlays didn't exist. For that matter, certain chrome packages, such as communicator, didn't exist. That was not a happy discovery.
Fortunately, the crew at #developers on irc.mozilla.org had a solution I didn't know about: scripted overlay loading. It's really simple:
window.addEventListener("load", function foo() {
document.loadOverlay("chrome://verbosio/content/verbosioOverlay.xul", null);
}, true);
You have to do this after the document has finished loading; otherwise, you get a couple nice assertions and a broken application.
I can already see this having a couple of good uses. One is sniffing navigator.userAgent to determine if you're in SeaMonkey. (I know, I know, that can be overridden. For an alternative, #developers, gavin namely, suggested nsIXULAppInfo.)
if (navigator.userAgent.indexOf("SeaMonkey") != -1) {
document.loadOverlay("chrome://communicator/content/tasksOverlay.xul", null);
} else {
document.loadOverlay("chrome://tasks/content/tasksOverlay.xul", null);
}
I pass null as the second argument for two reasons. One, these overlays (unlike custom ones) are pretty much guaranteed to be there. So they'll load. That's the point of user-agent checking in this case. Two, the API is guaranteed in the IDL comments to change, and I'm not inclined to support two different versions...
Another option is loading overlays based on specific values of window.arguments. If I open a Verbosio window with an argument of "demo", I can turn off normal editing overlays and apply overlays specific to the demo mode of Verbosio. Or I can use the user's preferences to determine which combination of Verbosio extensions he wants applied.
All work on Verbosio has effectively stopped because of this bug. Verbosio relies extensively on documents without windows. (Extra window objects are bloat.) Mutation events are also fairly important, as it is how Verbosio's various pieces detect changes in the master document.
This sucks. This sucks the neutronium out of a black hole. A Verbosio build based on SeaMonkey 1.0 just became impossible, and that was a major goal I had.
UPDATE: Patch posted! I hope the reviewers like it.
I really should get around to requesting cvs checkin privileges for the main tree, instead of just docs...
Say you have a document <root xmlns="http://weblogs.mozillazine.org/weirdal/namespaces/root/"/>. Your default namespace has no prefix for DOM XPath to look up. So if you try to do this:
var resolver = document.createNSResolver();
var result = document.evaluate("//root", document, resolver,
Components.interfaces.nsIDOMXPathResult.ANY_UNORDERED_NODE_TYPE, null);
alert("Node: " + result.singleNodeValue + "\n");
It's not going to work. You can't get to it using Mozilla's default namespace resolver. Instead, you have to create your own:
var resolver = {
lookupNamespaceURI: function lookup(aPrefix) {
if (aPrefix == "default") {
return document.documentElement.namespaceURI;
}
}
}
var result = document.evaluate("//default:root", document, resolver,
Components.interfaces.nsIDOMXPathResult.ANY_UNORDERED_NODE_TYPE, null);
alert("Node: " + result.singleNodeValue + "\n");
That will alert a node instead of throwing an exception. It'd really, really be nice if Mozilla's native XPathNSResolver was smart enough to actually give you a default prefix. Of course, to do that in any sane way, you'd probably have to add a matching lookupPrefix() method, so that if you fed lookupPrefix() a default namespace URI, it would spit back a prefix you could use with your xpath evaluation.
It took me several hours to figure this out, and then only with the help of a devmo-linked tutorial on XPath basics. I want to file a bug on this, but I'm not sure the bug would be valid. If it were valid, I'd fix it myself in a matter of minutes. (It's worth noting the DOM 3 XPath spec is a Working Group Note, so we're not under any obligations whatsoever to not do anything to the native resolver.)
UPDATE: Err, I spoke too soon about a matter of minutes, before writing any code on it. If I have <root xmlns="http://weblogs.mozillazine.org/weirdal/namespaces/root/"><real xmlns=http://weblogs.mozillazine.org/weirdal/namespaces/real/"/></root>, then I'm a wee bit hosed at real. I need to work out a JS-based solution first.
UPDATE 2 Hm. "//xmlns:root" seems to work just fine. I remembered something about default namespaces. An attribute xmlns="foo" has a namespaceURI of "http://www.w3.org/2000/xmlns/", not null. So that works, and actually fits my needs perfectly. Nothing to see here, move along.
UPDATE 3 I realized about an hour ago that the xmlns: prefix in XPath only covers the namespace URI of the resolver's initializing node; other nodes with different default namespaces are still lost. Plus, XPath is the wrong solution for the problem I had in mind anyway. Back to the drawing board...