Closed Bug 104128 Opened 23 years ago Closed 23 years ago

Use DrawTheme* for form controls on OSX

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: mikepinkerton, Assigned: mikepinkerton)

Details

Attachments

(4 files, 1 obsolete file)

checkboxes and pushbuttons done
96.35 KB, image/png
Details
my.yahoo with aqua buttons
141.56 KB, image/png
Details
new interface implemented by rendering context
2.36 KB, text/plain
Details
updated patch, buttons not blue, no more quartz link errors
12.22 KB, patch
Details | Diff | Splinter Review 
investigate using OS routines DrawTheme* on OSX to draw our form controls to
look native.
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.
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!?
Status: NEW → ASSIGNED
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).
cc'ing bryner and hyatt as this impacts XBL form controls.
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.
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.
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.
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 
"eventually".

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 
"documentation".

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. 

this has been superceded by hyatt's new nsITheme work so i'm closing it out.
honest.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: