Use DrawTheme* for form controls on OSX




16 years ago
16 years ago


(Reporter: Mike Pinkerton (not reading bugmail), Assigned: Mike Pinkerton (not reading bugmail))


Mac OS X

Firefox Tracking Flags

(Not tracked)



(4 attachments, 1 obsolete attachment)



16 years ago
investigate using OS routines DrawTheme* on OSX to draw our form controls to
look native.

Comment 1

16 years ago
Created attachment 52994 [details]
checkboxes and pushbuttons done

Comment 2

16 years ago
if you use ns6 to view the attachment, the QT plugin doesn't show you the entire
PNG. best results are to save it and use something else.

Comment 3

16 years ago
Created attachment 53000 [details] with aqua buttons

Comment 4

16 years ago
so there are a couple of issues here:
- checkboxes/radio buttons are 18x18, not the 13x13 we have now. this means that
we break the XP'ness of our layout. perhaps that's already done, though, by
different font sizing per platform.
- as demonstrated by the yahoo attachment, it just looks silly ;) are we sure
users really want this!?

Comment 5

16 years ago
Created attachment 53088 [details] [diff] [review]
patches to layout and gfx to do this

Comment 6

16 years ago
Created attachment 53089 [details]
new interface implemented by rendering context

Comment 7

16 years ago
just attached the patches to use native rendering for buttons and checkboxes.
Obviously, it's a quick and dirty hack and the aligment isn't correct, etc, but
it shows the basic approach i think we should take:

There is a new gfx interface called nsINativeFormControlRendering that the
rendering context implements. On this interface are methods to draw the
appropriate form controls in the given state (pressed, focussed, etc). That way,
we can keep all the native OS code w/in GFX and not dirty up layout with
platform ifdefs. 

Note that we'll probably want to keep the CSS-drawn form control code around
even when drawing native to the screen because at least on mac, the DrawTheme*
routines don't work in a printer context. In the printing case, I think it's
alright to fallback on css-drawn controls. As a result, we can use a runtime
determination to free us of ifdefs (does the rendering context impl this
interface and we're not printin? if yes, use it, if not, draw with css).

Comment 8

16 years ago
cc'ing bryner and hyatt as this impacts XBL form controls.

Comment 9

16 years ago
Wouldn't it be better to use the clear aqua buttons? Blue buttons are usually
reserved for default choices or in places where there is only one choice, aren't
they? I've never seen an instance in a Mac OS X dialog or window where all the
buttons are blue.

Comment 10

16 years ago
Created attachment 53953 [details] [diff] [review]
updated patch, buttons not blue, no more quartz link errors


16 years ago
Attachment #53088 - Attachment is obsolete: true
Very cool.

> - checkboxes/radio buttons are 18x18, not the 13x13 we have now. this means 
> that we break the XP'ness of our layout.

Authors have no guarantee about specific widget dimensions in other browsers
anyway and shouldn't rely on particular pixel dimensions.

> - as demonstrated by the yahoo attachment, it just looks silly ;) are we sure
>users really want this!?

Based on user comments I have seen: Yes. Mac users don't like Windows-style buttons.

Comment 12

16 years ago
First off, I'd like to say this is excellent news. 

Secondly, pink, did you get a look at what beard and I did in netwerk/protocol/
theme? Possibly worth mining for some ideas as we'd made some progress on this.

Thirdly, on the size issue - well web designers are going to go nuts, but I don't 
see much that can be done about that.

I did some reading in the Aqua HIG guidelines and playing with Interface Builder. 
I tried out the "large" and "small" versions of a lot of the controls. For list 
boxes (drop downs) the small one is 14 pixels high, and would thus be an easier 
drop in replacement, if somewhat against the guidelines.

Similarly the push button (OK) shrinks from 20 to 17. Perhaps this would be 
worthwhile considering, as in the end its going to break layouts if you use the 
larger controls, and the HIG are just guidelines.

Not sure how much it'll help you for checkboxes and radio buttons - give it a 
try... With those controls inteface builder always seems to claim the height is 
14 - I don't believe that though, the HIG says they're 18x18 including the 
shadow. Perhaps its the shadow that's causing the confusion, or maybe a bug.
    I applied this patch and, while not in final form, it looked promising. In
addition to the points others have brought up here about control sizes, here's
my suggestion:
    With the patch, drop down lists are being drawn as separate elements -  we
draw part of it ourselves, which still looks just as Windows-like, and then an
Aqua button to the right. This looks really wierd. I think that drop down lists
should be drawn as a single element, i.e. using one native pop-up menu. So, in
addition to DrawNativeCheckbox and DrawNativeButton, we need
DrawNativeDropDownList. Getting the data for the contents of the drop down list
might take some more work though.

Comment 14

16 years ago
Conrad raises a good point. When you have time, open up InterfaceBuilder and look 
at some of the options therein ->

(n.b. for the casual reader, the NS in the names below is NextStep not Netscape 

NSPopupButton is the basic "Drop Down" and it has 2 styles "Popup" and "Pulldown"
There's also an NSComboBox.

Leaving aside all discussion of whether having 3 styles in the OS makes sense, 
unfortunately, this richer model seems to currently apply to Cocoa, Carbon has 
only a single style of NSPopupButton, the one most similar to Mac OS 9. Apple 
have commited to true parity between Carbon and Cocoa, but the operative word is 

Then there's also the issue that there's probably some lag between the actual 
Control Manager controls and the Appearance Manager's DrawThemeXXXX ... I guess 
the Universal Interfaces headers files are likely to be the only up to date 

All that said, playing with these controls (do "Test Interface" in Interface 
Builder) does give one an idea of the range of possible looks and feels which 
Apple currently seem to find acceptable. My vote would be to us NSPopupButton in 
Popup mode if possible, because its most like Mac OS 9, is the style used in 
Cabon, and the design is faster to use. However DropDown mode may be easier to 
implement with Mozilla.

Actually, I believe we should try to implement contextual menus using native 
code, and perhaps this would impact the story on dropdowns/popups also. 

Comment 15

16 years ago
this has been superceded by hyatt's new nsITheme work so i'm closing it out.

Comment 16

16 years ago
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.