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.
#137 Re:MozillaZine's ChromeZone Now Open!
by roc <firstname.lastname@example.org>
Wednesday May 26th, 1999 7:28 PM
You are replying to this message
Cross-platform UIs have always had problems, but there are reasons why they may not apply to Mozilla.
1) Bloat. The XP layer makes the application bigger than a version using the native UI. Mozilla already has to have a layout/rendering engine, XML parser, etc just to view Web documents, so if most of the new UI infrastructure reuses that (which it does), the footprint impact may not be huge.
2) Speed. The XP layer makes the application slower than a version using the native UI. Mozilla's layout/rendering engine already needs to be really fast to run the Web well. If it makes Web browsing swift and smooth, it can make the UI swift and smooth.
3) Complexity. Although XP layers are often simpler to program than the native UI, they are unfamiliar to most programmers and thus harder to work with. Mozilla tries to get around this by using XML, CSS, large chunks of HTML and other Web standards to describe the interface.
4) Style. XP layers don't look and feel like the native UI. They don't track changes in the native UI (either as the platform evolves or as the user changes system preferences). My feeling is that XUL is about evenly good/bad on this one. Some work is being done to make system-level preferences (e.g. colours) applicable to XUL UIs. Also, a lot of native applications don't track evolving platform UI, and it doesn't seem to matter that much. MS doesn't seem to have problems tweaking the look and feel with every Office release (new menus, new toolbars, new fonts, etc). Being able to push out new chrome on the fly could even be an advantage over native UI in this area. There's another argument that platform look and feel doesn't matter in the brave new world of Web-based applications, but I don't necessarily believe that.
5) Platform integration. Applications using XP layers don't integrate well with other applications on the same platform. This has been a problem in the past when apps interoperated in significantly different ways on different platforms, e.g. when some platforms had drag and drop and others didn't. These days things have settled down quite a lot; most of the variance revolves around COM. It remains to be seen how well Mozilla's XP-COM will interoperate with COM, but this is getting some attention so there is hope. Also, the drive to Web standards has created standard file formats and ways of thinking that let applications interoperate the same way on different platforms (e.g. XML).
6) Lowest common denominator. Applications that use XP layers are forced to use only UI features that are available on all platforms. Again, in recent history platforms have been converging, partly due to the drive to Web standards. Some of this is just that other platforms have made sure to have all the features of Windows that make sense... Furthermore, the more declarative style of UI programming that's fostered by XUL and CSS is more amenable to fallback in cases where the underlying platform doesn't support some functionality. In some cases, Mozilla people have worked hard to implement XP solutions that cover up possible shortcomings in the underlying platform (e.g. the tree widget).
Mozilla XUL may still fail, but it'll be really interesting to see how things work out.