MozillaZine

MozillaZine's ChromeZone Now Open!

Monday May 24th, 1999

Steve Morrison, creator of the XULTool, has joined MozillaZine (as some of you may already know). He has been hard at work getting the XULTool working on our site, and we're pleased to announce that the ChromeZone is now online.

Now, with a simple form, you can change the look and feel of Mozilla, and create your own themes! You can also choose from some ready-made themes we have available. You can also send your own themes to ChromeZone for addition to our site.

So, fire up apprunner and head over to the chromeZone.

We got a lot of great entries for our little "name our new chrome area" contest, but in our final vote, "ChromeZone" came out on top. A number of people submitted the name "ChromeZone" or a variation for our contest. Clayton Scott was the first, however, and his prize is a stuffed Mozilla doll from Netscape. I know we didn't promise any prizes for the contest, but we wanted to give something to the winner.

Thanks to everyone for you contributions, and if you have any suggestions for the chromeZone, let us know.


#287 Re:MozillaZine's ChromeZone Now Open!

by Maciej Stachowiak

Wednesday June 2nd, 1999 1:48 PM

You are replying to this message

Someone who hates XUL (e.g. MSNAK) please give a principled reason why XUL-based chrome must intrincally be slower, regardless of how it's implemented, than a "native" UI created out of Windows resources. Note: "extra layers of abstraction" will not cut it as a catch-all excuse. Resources are an extra layer of abstraction, but _everyone_ uses them on windows. Almost no one creates windows dialogs directly, one control at a time. And XUL manages to bypass the resource layer entirely, leaving no intrinsic reason why there must necessarily be more layers of abstraction.

As for Windows users refusing to accept any UI inconsistency, please compare the Internet Explorer toolbar to the toolbar of any other Windows app.

Regarding the JVM comment, I've found that modern JVMs have perfectly adequate GUI performance for relatively simple sets of widgets, on the level of complexity of the typical web broweser chrome.

What they _are_ really slow at is computationally intensive or file IO intensive applications.