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.


#22 native widgets are truly native

by strauss

Wednesday January 16th, 2002 9:35 PM

You are replying to this message

Looking through the code, one finds that in the nsITheme subclasses, the OS is being called to draw the widgets. These are not XUL widgets that are making calls to determine foreground colors and the like -- they are fully native widgets. On the Mac, this is being accomplished by calling the Appearance Manager to draw them. On GTK, the GNOME toolkit is being called for drawing buttons, not just for coloring buttons drawn in XUL. The Windows code is difficult to understand since it indirects everything through a non-described DLL, but it seems probable that the same implementation strategy is being used on all three platforms.

For instance, with respect to GTK, look at the routines in nsNativeThemeGTK.cpp, which call native GNOME routines like gtk_widget_set_rc_style, gtk_widget_realize, and gtk_button_new. These are not just theme attribute queries used to "fill in the blanks" of XUL-rendered widgets -- they're native OS widget calls. Similarly, in nsNativeThemeMac.cpp, native MacOS Appearance Manager calls such as DrawThemeButton, DrawThemeWindowHeader, DrawThemeEditTextFrame, and DrawThemeTrack are being used for rendering. I'm not sure why some people are insisting that XUL is still being used as the rendering layer for native widgets, but the code shows otherwise on GNOME and Mac at least.