MozillaZine

Full Article Attached MozillaZine on Skins

Tuesday April 11th, 2000

I have decided to put my own head on the chopping block and weigh in on the Mozilla skins and native widgets debate. To read more, click "Full Article" below.


#49 Cross-platform GUI 101

by ttfkam

Wednesday April 12th, 2000 9:11 PM

You are replying to this message

"Apart from that, I think, using native widgets would have saved Mozilla *a lot* of work and bugs in the past and future.

"Disclaimer: I'm *not* speaking about XUL, which could (mostly) be implemented with native widgets."

=========================

Have you ever coded UIs in more that one GUI toolkit? I doubt it. Basically it is nigh impossible to make a common API for all of them. While they may appear to do the same thing, they may (and do) programmatically do it in drastically different and incompatible ways.

You bring up an interesting point with regards to preferences toward native widgets. I have developed Java applications with both the original AWT widgets and the newer Swing equivalents.

As a point of history, the reason why Sun moved away from native widgets (the implementation of the AWT package) was because different platforms' widgets reacted differently to input and rendered differently so that a Java applet/application that looked good in Win32 would end up looking horrible in Xlib or OS/2 PM.

Swing tried to make platform-neutral widgets that appeared on the surface like the native widgets with the platform-specific look&feel (basically skins). This appeased the platform widget purists to some extent while still allowing look&feel changes when required/wanted.

The only thing holding back Mozilla from _appearing_ to support native widgets is a custom CSS skin just like Swing. The only problem with this is that people need to spend the time to code the CSS for each platform -- a far cry from actually implementing the native widgets of all of the disparate platforms.

If you want native widgets, make a CSS file that makes the cross-platform widgets look and act like *insert_favorite_platform* widgets.

And no, mapping XUL on top of native widgets is not the answer. Layout issues (different sizing/spacing) being the most prominent reason. You end up with only a marginal advantage over straight native widgets.