This is a tracking bug for a community effort to develop platform-consistent look and feel (via XBL and CSS) for the XPToolkit widgets, so Mozilla can look like a native app on each platform. This bug depends on separate bugs for each widget. At this stage, the plan is for each bug to go through three stages. 1. A quick PNG, CSS, and XBL snow job to make the widgets look and behave like the OS widgets do when the OS is set to the default settings. Depends on: willingness of module owner to accept patches. Hopeful target: M20. 2. A more thorough job, which inherits platform settings whenever they are updated. Depends on: a thorough implementation of CSS UI fonts (bug 16729) and colors (bug 1004), and other platform-specific work to inherit those system settings which aren't covered in CSS (like widget sounds, for example). Hopeful target: M30. 3. (Optional) A thoroughly devilish scheme to use native widgets themselves (which, in theory, will have become sophisticated enough by then to do everything we want CSS- and DOM-wise), while maintaining the flexibility of XUL and friends. Depends on: a fair bit of Gecko hackery. Hopeful target: M40. The status line of this bug will record approximate total progress in matching the widgets of the three main graphical toolkits -- Windows, Mac, and GTK. Individual bugs will show status in matching the particular widget on each platform.

Adding bugs that block some stages of this bug.

What I think I'll do is close those other bugs as duplicates of the relevant widget bug (they are effectively Stage 2 or Stage 3 of the bug for some widget), and any special notes arising (e.g. `don't forget the Smart Scrolling preference') can be noted in the widget bug. Then once a particular stage is complete, if there are platform-specific faults with the implementation of that stage, separate bugs can be filed blocking the particular widget bug. The widget bugs can also depend on other bugs which involve getting platform settings or whatever. Please note, Status Whiteboard for this bug and its dependencies is now of the form [Platform: Stage 1 complete, Stage 2 complete, Stage 3 complete].

I think it is better to convert the old bugs to fit the stage scheme of this bug than close them. Stages 1 and 3 are very different. Combining them in a single widget bug risks obscuring the importance of stage 3. I think it is better to keep separate bugs pending for stage 1 and stage 3 per widget.

Henri: I've thought about separating the stages, but decided against it. If Stage 2 is implemented on a given platform for a given widget, that makes Stage 1 obsolete. Similarly implementing Stage 3 makes Stages 2 and 1 both obsolete. It's much easier to recognize such possible duplicated effort if all stages are kept in the same bug, rather than having three (or nine?) bugs for each widget. None of the widget bugs will be RESOLVED FIXED until Stage 3 is complete. Reassigning to self, to keep the spam off Trudelle. jrgm@netscape.com, since this is a tracking bug you can give the QA to nobody@mozilla.org if you like.

Implementing stage 2 depends on stage 1, but the stages 1 and 3 have no implementational interdepencency. In order to keep stage 3 bugs in the field of view of potential contributors, I suggest using two bugs per widget: one bug for tracking stages 1 and 2 and another one for tracking stage 3 progress. The completion of stage 3 work would of course obsolete the bug tracking stages 1 and 2.

How close is GTK to being a Model View Controller architecture? It seems that, for the initial stages at least, you're best bet would be to just ask the OS to blit an appropriate sized control in the box you want it drawn in. Naturally you walk into a wall at the point that you need some style attribute that the native controls don't support, but its better than a PNG based approach. The massive advantage of this approach is that it takes into account themes, schemes, skins and colours that the user has chosen. You can't do that if you're trying to fake the rendering yourself. (See Windows or Mac L&F for Swing) I know the native-os-blits-the-view is how it can be done for Swing L&F though no one has yet shipped such a L&F (though we did get to see a preview yesterday somewhere very public).

lordpixel: that would be Stage 3 of this bug for GTK. Stage 1 and 2 will almost certainly be easier, so they should be implemented first. Of course, if you or someone else can fix Stage 3 right now, that would be excellent because it would save someone from having to implement the other stages.

I'm afraid knocking up stage 3 overnight is a bit beyond my abilities :-) Maybe I'm being stupid but I just don't see how stage 1 is supposed to work. I can just about see how you might be able to fake a radio button and some of the other simpler controls using a PNG for on and one for Off, but even with these you have the issue of indicating they have focus. I also think you'll have huge problems with any control that can be resized. Checkboxes are always the same, but how will you handle ordinary buttons? Images that draw the top, bottom, left and right sides that you'll stretch. I'm not trying to be hypercritical here but I am having difficulty seeing how stage 1 can work and I hope someone can explain it to me. Maybe we should take this discussion out of the bug itself though?

(Discussions with Henri and lordpixel concluded by e-mail.) This bug is going to be around for a long time -- probably months at least. Therefore, if you have general questions or suggestions about it, please e-mail them to the owner of the bug in the first instance. If you are not satisfied with the response from the bug owner, then by all means comment in the bug itself, or in netscape.public.mozilla.ui. Ben, you've been doing a lot of the Stage 1 widget work -- would you like to take this bug until Stage 1 is complete?

sure. I leave it to someone else however to decide on the percentages ;)

*** Bug 48032 has been marked as a duplicate of this bug. ***

removing access keyword

*** Bug 107235 has been marked as a duplicate of this bug. ***

*** Bug 122003 has been marked as a duplicate of this bug. ***

*** Bug 165394 has been marked as a duplicate of this bug. ***

Mass reassign of my non-Firefox bugs to ben_seamonkey@hotmail.com