MozillaZine

Tree Closes For 0.9.8

Wednesday January 16th, 2002

Mozilla.org has closed the tree to approved checkins only, starting as of 12am Wednesday, and will do so until 0.9.8 has branched. 0.9.8 will have a variety of new items including new natively drawn widgets on WindowsXP, Mac OS X, and GTK, when you are in the classic skin (We will have more on this later, including screenshots); the addressbook was rewritten, and now supports printing, a new "Get Map" button allowing you to query for a map based on a card address, and other stability fixes; Windows MAPI support; and a huge amount of performance and stability work.

Many believe this is one of the last milestones prior to 1.0, and that Mozilla.org will actually have 1.0 following 0.9.9. 0.9.8 should branch sometime next week, with a release two Mondays from now. We'll keep you updated on both the branching and the release.


#32 Re: Re: native widgets are truly native

by strauss

Thursday January 17th, 2002 9:31 AM

You are replying to this message

Yes, XUL is still responsible for the large-scale structure of the window. What you and a few others aren't getting is that in the new regime -- at least on Mac and GNOME -- once you get down to a certain level XUL is out of the picture. It's not true that Mozilla just queries the theme engine for CSS attributes like foreground and border color. Instead, it calls the OS native widget rendering routines to draw the widget in its current state, rather than using XUL to render the widget from an HTML-like representation. I gave specific examples of the native OS widget rendering calls being used on both GNOME and MacOS. Did you look at the code? It's in nsNativeThemeMac.cpp and nsNativeThemeGTK.cpp.

As I noted, the Windows code is not as easy to read as the MacOS and GNOME code due to its indirection through an undescribed DLL. It's possible that the native code on Windows does work in the "semi-native" way, simply querying for CSS attributes and still calling out to HTML-like XUL versions of the widgets for rendering. If so, that would mean the feature was implemented differently on different platforms. I tend to doubt that, and the inconsistency would be a problem in itself if it were true, but I can't rule out the possibility based on what I see in nsNativeThemeWin.cpp.

Lee Strauss