46174 - [Mac Classic] Widgets don't use Appearance Manager variation color

Status: VERIFIED FIXED

(SeaMonkey :: Themes, defect, P3)

Description

[Andrew Thompson]

Moz build 200007213

Mac Classic skin uses default "Lavender" blue for scrollbars, drop down menus
(like the Bookmarks in the personal toolbar) an dropown lists (like the font
choosers) and list boxes in HTML are using a darker blue

It should be picking up the user's Variation colour from Appearence.

Comment 1

[Matthew T (active 1999-2002)]

I think knowing about the variation color involves making a CSS value for it 
which hasn't been done yet ... But menus should still be identical to how they 
normally look with the Mac OS default, which is Lavender.

Comment 2

[Nikhil Bhatla (gone)]

A Couple Things: First, there is currently no underlying code in Netscape 6 to be 
able to grab the Mac system colors from the Appearance control panel.  I 
completely agree that it should grab whatever the user's system preferences are, 
but currently this is a very low priority.  The reason this feature doesn't 
already exist in the first place is due to Mozilla's goal to being truly cross-
platform, relying on as little info from any particular OS as possible.  I hope 
to get this fixed on the Mac soon though.

Second, the appearance of HTML widgets (like list boxes) are a different matter 
entirely.  In order to make it easier for web designers, we have designed a 
standard widget set that has a standard size and appearance no matter what the 
user's skin is.  The idea is that the skin only affects the mozilla app, and not 
any independant data that is being viewed through the browser, even though it 
detracts from the overall appearance.  The standard widget set is also a good for 
making Mozilla easily embeddable.

Comment 3

[Andrew Thompson]

Need fix for 1004 (Support CSS2 system colours)

Comment 4

[Matthew T (active 1999-2002)]

Blocks bug 39375 (platform-consistent look and feel for widgets). Also applies to 
focus rings, to progress meters, and (even though Apple doesn't do it) to 
disclosure triangles.

Doesn't really depend on bug 1004: as discussed in that bug, a Moz-specific CSS 
value needs to be added to cater for the Mac's variation color. That needs a 
separate bug.

Scrollbars and progress meters depend on bug 31726 (tinting of graphics), since 
they use various tints of the variation color.

Nikhil, if you know exactly who it was who came up with that utterly fallacious 
idea that having a cross-platform HTML widget set would `make it easier for web 
designers', please let me know and I'll have a quiet word with them. (Apparently 
they think Mozilla is the only graphical Web browser in existence ...)

This bug will probably be split up into half a dozen other bugs when I get the 
time to do it.

Comment 5

[Nikhil Bhatla (gone)]

Matthew - The idea behind having a standard size widget set has little or nothing 
to do with a belief that Mozilla is the only graphical browser on the market.  
The idea, which I agree with, has to do with a basic separation of content and 
view/presentation/UI that is good programming style.  I agree that the current 
embedded widget set is pretty damn ugly, but that doesn't mean that the idea to 
have a standardized widget set is not a good one.  And once the resources are 
available, the ability to skin the embedded widget set will come about...And this 
entire discusssion will be irrelevant.

Comment 6

[Matthew T (active 1999-2002)]

> The idea behind having a standard size widget set ... has to do with a basic
> separation of content and view/presentation/UI that is good programming style.

And having a standard size widget set would *discourage* that separation of 
content and view, and *discourage* good programming style, because it would 
encourage authors to assume that the same size widgets were being used 
everywhere -- when this would simply not be the case. (Much the same way as 
authors used to assume that text would be in Times New Roman unless they took 
drastic steps to prevent it.)

Comment 7

[Nikhil Bhatla (gone)]

There is nothing wrong with moving toward a cross-platform standardization of 
widgets.  There is an ideal that suggests that everything (including style, hence 
we have CSS as a standard) in a web page's content should be under the content 
provider's control, and that the browser is simply an outer frame on this 
content.  Short of being able to control what the widgets actually look like and 
how they behave, the content provider can at least be sure that their web page 
looks good across ALL platforms by testing it with the standard widget set.  
There is nothing wrong with this ideal.  

Ultimately, though, the content will be under 
the user's control, just as you can have preferences for fonts and other settings 
that you can set to override the content provider's choice.  In this way we will 
eventually (hopefully) have a user preference to determine which widget set the 
user would like to use: the standard, the current skin-specific, or one that is 
even part of a separate skin that is not the currently active one.

I dislike the current look of the embedded widgets as much as anyone else.  
They're really ugly, esp. on a Mac.  That doesn't mean that the idea to have 
standard widgets is a bad one though.

Comment 8

[Andrew Thompson]

Been having my usual weekend dig around.

To get the Accent/Variation colours for the current theme on calls 
GetThemeAccentColors			(CTabHandle *			outColors)	

which essentially returns a Quickdraw ColorTable containing 7 colours that make 
up the variation color. (Gold, Lavendar, Sunny or whatever).

This is a Platinum concept - other themes generally don't have Variation colours, 
so one must check for errors after calling this. (Lord knows what Aqua will do - 
I'll try to find out)

So to fix this bug, I think we need to add some constants to mozilla/source/
widget/public/nsILookAndFeel.h to capture the concept of scrollbar colours, then 
make alterations to mozilla/source/widget/src/mac/nsLookAndFeel.cpp to actually 
use GetThemeAccentColors to get the user's current colors. (Defaulting to 
Lavendar if the routine fails I guess).

Naturally, if one is adding these kinds of colour constants, one needs to make 
sure they return something sane on Linux and Windows, or add them in a place 
that's definately Mac specific.

Comment 9

[Andrew Thompson]

The return value of GetThemeAccentColours isn't documented, so I went and worked 
it out. All the actual colour values below are examples - they're what you get if 
you use the Gold Accent/Variation colour scheme. The important thing to note here 
is the indexes 0..6 and which colour they correspond to. I made the names up, but 
I think they're suitably descriptive.


	0 	MacAccentLigtestHighlight		#ffff99	
    1	MacAccentRegularHighlight		#ffff00	
    2	MacAccentFace			 		#cccc00	
    3	MacAccentLightShadow		 	#999900	
    4	MacAccentRegularShadow		 	#666600	
    5	MacAccentDarkShadow 			#333300	
    6	MacAccentDarkestShadow 			#111111	
    
    
Controls use the colours as follows:


Scrollbar

Top left corner			MacAccentLightestHighlight
Top and left sides 		MacAccentRegularHighlight
Face 					MacAccentFace
Bottom and left sides	MacAccentLightShadow
Grippy shadow			MacAccentRegularShadow
Grippy highlight		MacAccentRegularHighlight
Grippy "gleam"			MacAccentLightestHighlight (single pixel at the end of 
each ridge on the grippy)

Slider

(exactly as for scrollbar)

Progress Bar (regular)  -- you need to look at a screen capture - this is 
simplified

Central highlight				MacAccentLightestHighlight
First ring out from centre		MacAccentRegularHighlight
2nd ring 						MacAccentFace
3rd ring						MacAccentLightShadow
4th ring						MacAccentRegularShadow
botttom and right of shadow		MacAccentDarkestShadow

Progress bar, barber poll (denotes indeterminate progress)

Coloured part consists 10 stripes, as follows: (there is also the Silver part)


MacAccentDarkShadow
MacAccentRegularShadow
MacAccentLightShadow
MacAccentFace
MacAccentRegularHighlight
MacAccentFace
MacAccentLightShadow
MacAccentRegularShadow
MacAccentDarkShadow				(only use of this colour)
MacAccentDarkestShadow

Focus Ring

MacAccentLightShadow		(though you should use the GetThemeBrushAsColor call 
to get this)


Drag highlight (indicates a region is a valid drop target)

Use call to GetThemeBrushAsColor

Comment 10

[Henri Sivonen (:hsivonen)]

How about using Appearance Manager itself to draw the scrollbar graphics? Couldn't 

Mozilla ask Appearance Manager to draw the relevant scrollbar parts in an off-screen 

GWorld at run-time? Then Mozilla could slice up the resulting bitmaps, cache the slices 

and let the slices be accessed through pseudo URLs.



This way the scrollbars would also be compatible with many/most Kaleidoscope themes.

Comment 11

[Andrew Thompson]

Please see bug 38275. Something like this is indeed planned for the future.

Comment 12

[Henri Sivonen (:hsivonen)]

Bug 38275 doesn't look relevant. Wrong bug number perhaps?

Comment 13

[Andrew Thompson]

oops. bug  39375

Comment 14

[Henri Sivonen (:hsivonen)]

What I suggested would count as a stage 2 implementation. I believe using OS-drawn 
cached bitmaps is more efficient than constructing bitmaps using gfx and an OS-supplied 
palette.

Comment 15

[timeless]

Henri, if you want that stuff file please a different bug. Thanks. This bug is 
for the CSS colors and such for native coloring of moz widgets.  A minor 
reminder: We're allowing windows native widget support to rot, so don't expect 
anyone to work on mac native widget support [with the exception of menus which 
we do because...].  One of the reasons is that skin functionality demands more 
features than we can easily expose through native calls.
The arguement that the os can draw faster than mozilla is generally silly.  
Unless your OS uses 90% of all cpu cycles and gives 10% to the active app, 
there should be no reason that what one binary (mozilla) does should be any 
faster or slower than what another binary (system/guisubsystem) does.
-
Adding CCs [not related to my comments, but because of the bug itself]

Comment 16

[Andrew Thompson]

Nominating for rtm, cause the Mac community will fry us without this! I know 
MacIE5 has a similar problem, but its no where near as annoying.

I hope to get some time to work on this this week, but it will likely be to a 
similar quality standard as my patch attached to bug 1004. i.e. the basics will 
be there but it won't work. I need someone who can build on MacOS to help out!

>The arguement that the OS can draw faster than mozilla is generally silly.  

Really? You believe that Mozilla can blit just as fast, through all its layers 
of CSS, XUL, GFX and Dilbert knows what else, as the Mac Toolbox Quickdraw 
routines that Apple has been tuning since 1984? 

Mozilla is emulating natvie controls through several layers of APIs. With the 
best will in the world this *is* going to be slower. The questions are, is it 
slower enough to be noticable? Is it fast enough to be acceptable?

It seems OK to me, but then I have a G4 not a PowerPC 601 (G1, if you like)

Comment 17

[Nikhil Bhatla (gone)]

reassigning to hangas

Comment 18

[John Bafford]

//This rant is directed at everyone, not just timeless.



Timeless: lordpixel is right: Mac OS can probably draw the controls faster than 

Mozilla. And even if Mozilla could draw them faster, I'd still be against having 

Mozilla draw any widgets that the host OS provides.



And he's also right that the Mac community will fry Mozilla for not looking like 

every other Mac application. It doesn't MATTER that it's cross platform, and has 

all the latest features, can wash your dishes, make your toast, and walk your 

dog. If it doesn't look like a Mac app, it isn't a Mac app, and many Mac users 

will shun it for THAT REASON ALONE.



The Host OS, whether it's Mac OS, Mac OS X, Windows, BeOS, or whatever, provides 

a set of native widgets for three basic reasons. First, it's just *easier* to use 

OS widgets than to code your own. Second, it makes all the applications that use 

those widgets look consistent. Thirdly, it allows the OS vendor to add features 

to those widgets and have them take effect on a global basis.



Take the Mac transition from Classic B/W to Classic Color to Platinum to Aqua. An 

application written back in 1984 using native widgets would, with minimal effort, 

incorporate all the new functionality and appearance of widgets introduced in 

successive updates to the Mac OS user interface. A program written before the 

zoom box benefited from its addition with no extra code. Then Apple added color 

tinges to the windows and controls and apps got that for free. Then WindowShade 

was incorporated into the OS and apps got that for free. Then the Appearance 

Manager came along and apps got UI enhancments mostly for free. And again with 

Aqua. Your well-written app has to do nothing to get those throbbing buttons and 

window drop shadows and that gawd-awful genie effect to the dock.



Heck, Mozilla requires 8.5. This means that Appearance 1.1 can be assumed to be 

present, which means there's a TON of native widgets that can be used without the 

need to reimplement them.



There's another few bugs in the system that complain about the number of open 

files, and the fact that the Mac install has over THREE THOUSAND files that get 

installed. Maybe some of these files wouldn't be necessary if Mozilla just used 

native widgets instead of trying to define the looks of widgets in some XML file?



The point of this rant, which should probably be copied to every other user 

interface bug for every OS, is that it's just plain *silly* to duplicate the 

native widgets with less attractive Mozilla widgets that are "cross platform". 

The Appearance Manager is there for a *reason*. Apple added a ton of new controls 

for a reason: too many app developers were using too many different variations of 

controls that should have been system-wide to begin with.



"Relying on as little info from any particular OS as possible" is not being 

crossplatform. Being crossplatform is saying "Give me a scroll bar with these 

dimensions, with a page height of XXXX pixels, YYY of which are visible, and 

we're displaying starting at ZZZ pixels" and letting whatever OS-specific glue 

you need ask the OS to do that. And then you don't care if the user chose 

Lavender or Magenta or Puke Green as their accent color, because the OS drew the 

thing for you. Ask for a scroll bar in your XP front-end, and let your OS-

specific backend library take care of the details.



Part of responsible software development is adhering to the standards of the host 

OS. Part of responsible software development is writing efficient code.



And especially, part of responsibile software development is knowing WHEN to 

reinvent the wheel. Mozilla is reinventing too many wheels just for the sake of 

reinventing them.



//End Rant.

Comment 19

[Hixie (not reading bugmail)]

If you care so much, please help us support native widgets by submitting 
patches. The engineers who are already working on Mozilla (including all the
Netscape engineers) are waaay too busy to do this. We have plenty of other,
more important bugs to fix (like crashers).

And FYI: If Mozilla had not gone the XUL/XBL route, then Netscape would not be
working on a browser for the Mac at all.

Comment 20

[Andrew Thompson]

Attachment: Includes psued oce function to fetch variation colors

Comment 21

[Andrew Thompson]

Attachment: Header file to go with above pseudo code

Comment 22

[Andrew Thompson]

First, go read my comments on the patch attache to bug 1004.

You need to do this for 2 reasons:

i) this file also contains the bug 1004 work


ii) THIS CODE  is even WORSE than that code!

I'm ashamed to attach something this bad. The only use it has is to act as a 
starting point and a demonstration for someone who really wants to take this on 
of the most basic points needed to begin.

This is a single function whose job is to fetch a Mac accent variation colour 
when passed the appropriate constant, or default to using the Lavendar colours if 
something goes wrong.

Its not wired into the style system. What's needed is:

i) Someone compile debug and fix this function

ii) Someone needs to add some extra proprietary Moz CSS system colour constants 
so the rest of the application can find these mac accent colours

The first question you need to answer is whether the constants that you add can 
remain Mac specific or whether you need to give them dummy/sane colour values on 
all other platforms (Win, Linux, OS2, BeOS).

I worry that its the later because as far as I can tell adding new constants to 
the style system would require updates to at least these files:

/widget/public/nsILookAndFeel.h
/widget/src/xpwidgets/nsXPLookAndFeel.cpp
/layout/html/style/src/nsCSSProps.cpp

So I doubt you can contain it to Mac OS only :-( but I don't know that for sure. 
Also if you call the constants something like eColorMacXXXX you can just maybe 
note they're undefined on other platforms, because they make no sense.

You also need to define constants for the Focus Ring, Menubar selected colour, 
and drag highlight, and wire these up to GetThemeBrushAsColor as suggested above 
and demonstrated (for the official CSS2 system colors) in the part of the patch 
that relates to bug 1004.

A further issue is that of speed. I don't know how often Netscape calls GetColor 
- if its just at startup or occassionally, like during New Window, then we're 
probably OK with this, but I wonder about caching the colours to speed things up 
rather than querying the Appearance Manager every time. Of course. maybe looking 
these up is so fast it doesn't matter...

If we cache the colours then you need to look at the docs linked off bug 1004 and 
evaluate how difficult it will be to get Mozilla to respond to the Apple events 
sent when the systemwide theme changes so it can flush and rebuild the colour 
cache.

Actually, we may need to react to these events to be fully Appearance compliant 
in any case.

Comment 23

[Andrew Thompson]

I don't think I was clear enough on this so:

My C is rusty. I can't build Mozilla so I can't compile this. You need to be 
checking *everything* including going right down to the level of grubbing through 
Quickdraw.h  to make sure I'm dereferencing the data structures correctly.

Read the comment in bug 1004.

Comment 24

[Andrew Thompson]

Attachment: Note to self: Save file before attaching it :-)

Comment 25

[Andrew Thompson]

Attachment: Note to self: Save file before attaching it :-)

Comment 26

[Andrew Thompson]

Sigh - missed a close brace:

	} else {
		//hmmm, MacOS constant! what should I be using?
		if (colours == NIL || (**colors)->ctSize !=7) {
			//someone changes the struct on us
			err = NS_ERROR_FAILURE;
		}	
	}
    ^^^ missing in attachment

Comment 27

[hangas]

sending out for help, if you cannot help or know of better owner please return

Comment 28

[Paul Wyskoczka]

Updating QA Contact to [e-mail]

Comment 29

[rubydoo123]

why was this assigned to simon?

Comment 30

[Andrew Thompson]

[e-mail], this is closely related to bug 1004

Comment 31

[hangas]

Marking future and helpwanted.  I would love to see this done correctly but 
cannot find any volunteers.

Comment 32

[hangas]

Not for rtm, marking -

Comment 33

[Andrew Thompson]

Attachment: Working C++ patch that implements some appearance colour support

Comment 34

[Andrew Thompson]

Attachment: Patches to 2 Mac classic skin CSS files that demonstrate the patch at work

Comment 35

[Andrew Thompson]

Here is a working C++ patch. Its not a complete fix to this bug but it does make 
4 mac colours available:

1/ The Focus ring colour (primarily for text fields, but listviews and trees 
should use it)
2/ The colour of a selected menu item [*]
3/ The colour of text in a selected menu item
4/ The colour of the drop target focus ring in drag and drop operations.

These patches add extra constants to CSS following the naming convention:

-moz-mac-<colourname>

n.b. this patch incorporates the patch I made for bug 1004. There's no avoiding 
it, this builds on that work.

While the constants are visible on all platforms they only have sensible values 
on Mac OS. This is OK because they're only for use inside the Mac classic skin.

The second attachment is a patch to classic/global/mac
menu.css and textfield.css that show off the C++ patch.

The patch to menu.css can be considered complete, in that it implements all of 
the Mac colours that are currently defined. The patch to textfield.css simply 
implements the focus ring, ignoring any other hard coded colours in this file. I 
will open a bug on hardcoded colours in the Mac Classic skin.

[*] currently this is a couple of shades too light. To fix this I need to 
ressurect parts of the older non-working patch (from 08/09/00) on this bug

Comment 36

[Andrew Thompson]

Attachment: Improved version of previous patch to C++ nsLookAndFeel etc

Comment 37

[Andrew Thompson]

Attachment: Patch to classic/global/mac/menu.css to show of theme support

Comment 38

[Andrew Thompson]

Improved patches now query variation colours.
This corrects the menu problem mentioned earlier. 

C++ patch
supports variation colours
support Black & White high contrast platinum theme variation
apologies, patch 17947 has mac line endings.

menu.css patch
Also added support for properly displaying disabled item in Mac popup/contextual 
menus  - this patch is just for demo purposes. Final version will be posted on 
bug 57490

Comment 39

[timeless]

According to my friends the proper way to render disabled items in macos 
context menus is display:none.... It would help if a developer.apple.com url or 
equiv was included here showing that disabled context menu items can exist 
before we consider your last changes.
-end of confusion-
Of course mozilla doesn't care about macui standards so coloring it correctly 
is still a step forward and you can ignore this comment if you like.
As always thank you for working on this project

Comment 40

[Matthew T (active 1999-2002)]

The HIGs say <http://developer.apple.com/techpubs/mac/HIGOS8Guide/thig-56.html>: 
`Contextual menus should never supersede menu bar items; there shouldn't be any 
items in a contextual menu which are not also accessible through the menu bar'. 
(We break that rule anyway, see bug 34357.) And later: `You should never place a 
command in a contextual menu which is disabled in or cannot be chosen from 
another menu in the application'.

I am inclined to think that this is poor wording on Apple's part, and that they 
actually meant the following. `You should never place a command in a contextual 
menu which is not available in the menu bar. In addition, you should never enable 
a command in a contextual menu if it is disabled in the main menu bar.'

I see nothing wrong with disabled items in context menus /per se/ -- see my
2000-10-25 comment in bug 16081, for example, where having disabled items in a 
context menu is important to make the position of the other items consistent with 
related context menus. In any case, we have other non-native menus in the UI 
which might have disabled items, and this patch is not specific to context menus.

Comment 41

[John Bafford]

mpt: No, Apple means what they say: contextual menus should _never_ have
disabled items. If an item is disabled, then it doesn't apply to the context in
which the menu opened. If it doesn't apply to the context, then it shouldn't
show up in a contextual menu.

Comment 42

[Andrew Thompson]

hrm. Yeah. What I was doing was making the contextual menu items behave visually
like disabled items in the main menus in the menubar. But John and timeless are
right, Apple produced software never has (that I've seen) any disabled items in
a contextual menu, so display: none; is probably the right thing to do.

Of course, this *probably* only makes sense if the items are available (but
disabled) in some other menu in the menubar, otherwise we're hiding the option
altogether.

This issue really needs its own bug.

Comment 43

[Andrew Thompson]

Attachment: Simplified version of above. Now 1004 has landed, this is smaller

Comment 44

[Andrew Thompson]

Ok Ben G and Pierre have looked at this and OK'd it (with one minor change Ben
wanted to make the drag highlight colour cross platform).

Simeon (smfr) do you still you look at this? If not I'll go for a= from blizzard

Comment 45

[Andrew Thompson]

Attachment: Changed patch as requested by Ben Goodger. dragtargetzone is now XP. Implemented on Windows and GTK

Comment 46

[Andrew Thompson]

Implementation on Win/Linux uses text highlight colour.

Other platforms (OS2, BeOS etc) will just get their default colour for unknown 
colours, which is seems to be either black or white.

Comment 47

[Andrew Thompson]

OK, now I have sr=blizzard via email.

(hmm, 3 people reviewed this and none of them commented in the actual bug :-) 
good thing you guys know me huh?)

Comment 48

[Blake Ross]

Fix checked in.  Thanks for the patch, lordpixel.

Comment 49

[Patty Mac]

This bug is partially fixed on Mac (2001-01-09-08-Mtrunk). The highlight menu 

items show different color other than Lavender. However, the color that appears 

around the text field when you click on does not take any change. These two 

colors should be identical colors.



To show different color other than Lavender, open the Appearance Control Panel, 

go to Appearance tab, make sure the Appearance is "Apple Platinum" then change 

the Variation color to something other than Lavender.



I checked with the Netscape 4.x, the text field focus ring when you click on 

does not change any color. Does Netscape 6 want to change different than Netscape 

4.x?

Comment 50

[Andrew Thompson]

Netscape 4.X has very bad support for modern Mac standards. It just used black 
focus rings. This was what System 7 did but not Mac OS 8. While the classic skin 
is supposed to be like Netscape 4 engineering in its failings is probably taking 
that too far!

Are you saying that focus rings are not changing colours for you? I don't mean 
the border of the field but the ring that appears around it when you click in it 
(e.g. see the Name field on the Personal tab of the Internet control panel).

If these rings are stuck as lavender on your system can you give me/us a specific 
example of one which does not change?

2 which definately work on my system:

1/ The Home Page location text field on the Navigator tab in preferences

2/ The Search field on the Search tab of the sidebar.

Are these really stuck on lavendar on your system? 

If you change the colour in the Appearence control panel you might have to quit 
Mozilla and restart it for the colour to change -> there is a seperate bug on 
that issue. That's bug 57799.

Comment 51

[Patty Mac]

Thanks very much for your explanation, Andy! Yes, the focus ring around
it when you click in does change different color other than lavender.

It works on my system with the following:

1. The Home Page location text field on the Navigator tab in preferences
2. The Search field on the Search tab of the sidebar.

Andy, your explanation is very clear. Thanks again!  I think the scroll 
bar is still blue. Maybe this is a separate bug. Anyway, marking verified 
on Mac; OS: 9.0 (2001-01-12-08-Mtrunk).

Comment 52

[Patty Mac]

Marking verified on Mac; OS: 9.0 (2001-01-12-08-Mtrunk).

Comment 53

[timeless]

Mac Scrollbars are the WRONG COLOUR is Bug 65025.