Closed Bug 39375 Opened 24 years ago Closed 18 years ago

Platform-consistent look and feel for all XPToolkit widgets


(Core :: XUL, defect, P3)






(Reporter: mpt, Assigned: ben_seamonkey)


(Blocks 1 open bug, )


(Keywords: helpwanted, meta, platform-parity, Whiteboard: [Win: 0%,0%,0%][Mac: 0%,0%,0%][GTK: 0%,0%,0%] - Stage 1 checklist coming soon)

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 
Depends on: 26828
Keywords: pp
Whiteboard: Stage 1: [Win 0%][Mac 0%][GTK 0%]
Adding bugs that block some stages of this bug.
Depends on: 16277, 34572, 35996
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].
Keywords: helpwanted
Whiteboard: Stage 1: [Win 0%][Mac 0%][GTK 0%] → [Win: 0%,0%,0%][Mac: 0%,0%,0%][GTK: 0%,0%,0%]
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.
Depends on: 39403
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., since this 
is a tracking bug you can give the QA to if you like.
Assignee: trudelle → mpt
No longer depends on: 34572
Keywords: meta
Summary: Platform-consistent look+feel for all XPToolkit widgets → Platform-consistent look and feel for all XPToolkit widgets
Depends on: 39409
No longer depends on: 16277
No longer depends on: 35996
Depends on: 39410
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 
No longer depends on: 39410
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.
Depends on: 39410, 39581, 39582
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?
Blocks: uaag
Depends on: 40268
Depends on: 40269
Depends on: 40270
(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?
Depends on: 1004
Depends on: 40700
Depends on: 46174
sure. I leave it to someone else however to decide on the percentages ;) 
Assignee: mpt → ben
Whiteboard: [Win: 0%,0%,0%][Mac: 0%,0%,0%][GTK: 0%,0%,0%] → [Win: 0%,0%,0%][Mac: 0%,0%,0%][GTK: 0%,0%,0%] - Stage 1 checklist coming soon
*** Bug 48032 has been marked as a duplicate of this bug. ***
Keywords: access
Depends on: 49144
Blocks: 73812
removing access keyword
Keywords: access
Target Milestone: --- → Future
*** Bug 107235 has been marked as a duplicate of this bug. ***
Depends on: 117584
*** 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
Assignee: bugs → ben_seamonkey
Closed: 18 years ago
Resolution: --- → WORKSFORME

Starting from the new proton ui (i think), on linux the widgets used does NOT appear to be native anymore.
It used to be in the past.

You need to log in before you can comment on or make changes to this bug.