671119 - Calendar widget colors do not adapt to GTK high contrast themes

Status: RESOLVED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Zane]

Attachment: calendar.png

User Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110628 Ubuntu/10.04 (lucid) Firefox/3.6.18
Build ID: 20110628230241

Steps to reproduce:

Installed Thunderbird 5.0 w/Lightning 1.0b4 in Ubuntu and tried viewing the calendar with the GTK theme set to High Contrast Black (white text on black background).


Actual results:

The Calendar views (the little mini one and the big calendar view) do not conform to the High Contrast Black theme and are too bright for me to use them effectively. I have an eye disease that makes it very hard to read unless I have a dark high contrast theme. See attached screenshot.


Expected results:

The calendar views (and any widget for that matter) should conform to the colors for the current system theme.s

Comment 1

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Zane, I'm sorry the calendar views are not colored dark with that theme. I'll see what I can do, its hard to find a balance between using system colors for everything and making the design appealing for the average user. I definitely agree that something should be done though!

Comment 2

[Zane]

Philipp:

Thank you for your interest in my situation. In consideration of your statement regarding the average user, I have a few thoughts for approaching this problem:

1) In an options dialog, allow the user to specify whether they would like to use the default colors or use system colors for the widgets.

2) (for the long run) Make all aspects of the application(including the calendars) conform to the current Lightning/Thunderbird theme. This way, a user could get a high contrast black theme or even a theme that conforms to system colors. Other users can be happy with the default theme or download a new theme that fits their taste.

3) "Bite the bullet," and make sure all widgets do conform to the system theme. One school of thought that many seem to be subscribing to lately is that the user chooses a system theme because he wants his applications to look that way. If he wants them to look appealing, then he can get a better theme.

Hopefully these provide some good ideas. I really like Thunderbird w/Lightning and would love to see it become both the most accessible and the best in terms of user experience overall.

Thank you!

Comment 4

[Richard Marti (:Paenglab)]

Attachment: mini-day-box - use system background color

The first patch gives the mini-day-box a system background color and instead of a background image a gradient. This fits the widget better to different themes.

I'll add more patches for other widgets. A patch for the minimonth is coming soon.

Comment 5

[Richard Marti (:Paenglab)]

Attachment: Comparison with before and after the patch

On top the mini-day-box before patch. On bottom with patch.
On the left with default Win7 theme and on the right with high contrast theme.

This is not the Linux high contrast theme but it looks similar.

Comment 6

[Richard Marti (:Paenglab)]

Attachment: minimonth using system colors

The second patch changes minimonth to use system colors.

Comment 7

[Richard Marti (:Paenglab)]

Attachment: Minimonth under Linux with patch applied

Screenshot of minimonth with default colors and with high contrast colors under Linux. On top today selected and on bottom September 30 selected. Under Win and Mac today selected is better matching with the pre patch version. Linux doesn't have this color as system color.

Comment 8

[Stefan Sitter [:ssitter]]

Richard, nice that you volunteered to fix Bug 435096 :) Do the month/year popup menus look ok too? Could it be possible to improve the < o > button visibility, e.g. by someone using some semi-transparent images with the text color as background?

Comment 9

[Richard Marti (:Paenglab)]

(In reply to Stefan Sitter from comment #8)
> Richard, nice that you volunteered to fix Bug 435096 :)

:) do know about other bugs with such problems?

> Do the month/year popup menus look ok too?

Do you mean the minimonth as popup? Then it looks the same (only on Linux high contrast theme the month/year labels change to a unreadable green on hovering the popup. I'm not sure if I should fix this in this patch or in a new).

> Could it be possible to improve the < o > button visibility, e.g. by someone
> using some semi-transparent images with the text color as background?

I'm not sure if I understand you correct but I think this didn't work well because the background with text color would be bigger than the images. When you look at the attachment 562247 [details] the dropmarker arrow on the right looks similar to the < o > buttons with HC themes.

Comment 10

[Decathlon]

Comment on attachment 562246 [details] [diff] [review]
mini-day-box - use system background color

Granted that I'm not an expert about themes, and accessibility, I'd also prefer an opinion by someone in the ui reviews about the navigation buttons.

IMHO the buttons are fine, they are pretty visible with high contrast themes and are similar to the dropmarker arrow in the button to the right. The images with default theme don't change so much (the circle looks a bit bigger but the borders don't look jagged). But I wouldn't know how to answer to the question by Stefan Sitter in comment #8.

About the background image, in the build I've done with your patch, the background looks different from your screenshot i.e. basically the same without the patch, that is fine. Instead, from your screenshot, the background looks too gray, it seems almost that the background-color property was set to "none" instead of  "Window".

About the gradient image, generally speaking, what's better, the image-gradient.png or the -moz-linear-gradient css property? Is there some guideline from Mozilla? In any case I see that, at least on Windows 7, the image quality is a bit lower (the gradient has horizontal line with not uniform color), but this is insignificant and doesn't concern the patch.

r+ but I would also like to know an opinion by Andreas Nilsson.

Comment 11

[Stefan Sitter [:ssitter]]

I meant the popup menus that show up if you click on the [month] or [year] button inside the mini-month control or the [v] button inside the mini-day control.

Comment 12

[Richard Marti (:Paenglab)]

Comment on attachment 562246 [details] [diff] [review]
mini-day-box - use system background color

(In reply to Decathlon from comment #10)
> Comment on attachment 562246 [details] [diff] [review] [diff] [details] [review]
> mini-day-box - use system background color
> 
> About the gradient image, generally speaking, what's better, the
> image-gradient.png or the -moz-linear-gradient css property? Is there some
> guideline from Mozilla? In any case I see that, at least on Windows 7, the
> image quality is a bit lower (the gradient has horizontal line with not
> uniform color), but this is insignificant and doesn't concern the patch.

On high contrast themes the -moz-linear-gradient isn't applied but I experienced the image is still applied. Without this gradient in HC themes the readability is better for handicapped persons (the main reason for this themes?)

> r+ but I would also like to know an opinion by Andreas Nilsson.

Done

Comment 13

[Richard Marti (:Paenglab)]

(In reply to Stefan Sitter from comment #11)
> I meant the popup menus that show up if you click on the [month] or [year]
> button inside the mini-month control or the [v] button inside the mini-day
> control.

Yes they are looking normal because they are still system menus. Under Win7 the menus have a vertical line in the middle. I plan to fix this in a special Win7 bug, when I know if bug 684518 will land or not.

Comment 14

[Decathlon]

Comment on attachment 563162 [details] [diff] [review]
minimonth using system colors

In this patch I don't like the colors assigned to "today" and "selected day". Original colors have a meaning because are the same in the calendar views (even the border for the "today" day that allows to understand when today is in the minimonth when it's selected).
Other colors about days text, header background are fine, not so much difference compared to the original look. Pop-up minimonth in todaypane and dialogs (New Event, Edit recurrence etc. are fine). 

I've tried to search a solution and I've seen that would be possible to do something by using 

"@media all and (-moz-windows-default-theme)" and 
"@media not all and (-moz-windows-default-theme)"

and including the original rules about minimonth-day with [today="true"],[selected="true"] and [selected="true"][today="true"] in the first one, and the new rules in the second one, but I'm not sure this is the best solution.
Richard, you know this things by far better than me, would be great to find a solution that keeps the original colors for today and selected day in the minimonth.

r- for what mentioned above.

A screenshot about minimonth on Win7 follows.

Comment 15

[Decathlon]

Attachment: Minimonth under Win7 with patch applied

Comment 16

[Richard Marti (:Paenglab)]

The problem is, minimonth.css is a common file and it has to fit for all platforms. -moz-windows-default-theme works only for Windows and Linux and Mac would use the non-default rules. I think, the best would be to move out minimonth.css from common files to theme specific location like. Then I can set system specific rules.

Comment 17

[Richard Marti (:Paenglab)]

Attachment: minimonth using system colors v2

This patch patch moves minimonth.css to the themes.
- Mac is unchanged because it doesn't exist a real high contrast theme.

- For Linux it's almost the same as in first patch except minimonth has now -moz-field as background color. It's in mostly themes lighter and fits better with ltnSidebar. I leave also the the border color for selected minimonth-day.

- Win has the same changes as Linux plus changed colors for minimonth-day when selected and today. Now this looks almost like before the patch on default theme.

Comment 18

[Richard Marti (:Paenglab)]

Attachment: Minimonth under Win7 with patch v2 applied

Comment 19

[Andreas Nilsson (:andreasn)]

(In reply to Stefan Sitter from comment #8)
> Richard, nice that you volunteered to fix Bug 435096 :) Do the month/year
> popup menus look ok too? Could it be possible to improve the < o > button
> visibility, e.g. by someone using some semi-transparent images with the text
> color as background?

On Linux we could make use of the toolkit arrows in a similar fashion to what the tab cycle buttons use in Firefox. For the O-button it could be possible to use a svg that have fill="-moz-dialogtext"

Comment 20

[Andreas Nilsson (:andreasn)]

(In reply to Decathlon from comment #10)
> Comment on attachment 562246 [details] [diff] [review] [diff] [details] [review]
> About the gradient image, generally speaking, what's better, the
> image-gradient.png or the -moz-linear-gradient css property? Is there some
> guideline from Mozilla? In any case I see that, at least on Windows 7, the
> image quality is a bit lower (the gradient has horizontal line with not
> uniform color), but this is insignificant and doesn't concern the patch.
> 
> r+ but I would also like to know an opinion by Andreas Nilsson.

I prefer css over images where possible. Simpler to change as the code is right there, should be slightly faster to load since we have fewer files to load and one file less in jar.nm. This is also in line with what have been done on Firefox css-wise (as in rendering the tabs with css instead of relying on chopping up images for example).

Comment 21

[Andreas Nilsson (:andreasn)]

Comment on attachment 564053 [details] [diff] [review]
minimonth using system colors v2

In general good direction, some issues I spotted.
* There is a yellow line around the currently selected date (Linux).
* Not sure I like the gray background on the dates that are not part of the current month. Just a white background should work all right.
* Slightly odd that hover and onclick colors are blue, but once you release the mousebutton in become gray. What if we make the current date outlined and hover, onclick and selected date "background: Highlight;"?

Comment 22

[Richard Marti (:Paenglab)]

Attachment: mini-day-box - use system background color v2

Patch is using now svg images for the navigation buttons. I've also changed with this patch minimonth.css to remove the now unneeded png file.

Decathlon, when you test this on HC themes be sure to restart TB because the svg images don't pick up the new colors on theme change.

Comment 23

[Richard Marti (:Paenglab)]

Attachment: Miniday with svg buttons on HC theme

Comment 24

[Andreas Nilsson (:andreasn)]

(In reply to Richard Marti [:paenglab] from comment #22)
> Created attachment 564795 [details] [diff] [review] [diff] [details] [review]
> mini-day-box - use system background color v2

Just a quick note that there is a small error with jar.nm on line 15 in the patch. Refers to both png and svg.

Comment 25

[Richard Marti (:Paenglab)]

Attachment: mini-day-box - use system background color v2.1

Fixed wrong extension in jar.mn

Comment 26

[Andreas Nilsson (:andreasn)]

Comment on attachment 564826 [details] [diff] [review]
mini-day-box - use system background color v2.1

In general, works great!
Only one small thing, the nav icons become invisible upon hover with the Linux HC/Invert theme as they get the same colors as the buttons. Fixing this with specific icons for hover would make the number of icons grow to 6, but perhaps if we use -moz-appearance: button-arrow-previous; and -moz-appearance: botton-arrow-next; [1] for this we would just be down to two icons.

https://developer.mozilla.org/en/CSS_Reference/Mozilla_Extensions#-moz-appearance

Comment 27

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

(In reply to Andreas Nilsson (:andreasn) from comment #20)
> I prefer css over images where possible. Simpler to change as the code is
Just a note, you should be able to use a css stylesheet even for an svg file. Just give it an id and I think its the usual <?xml-stylesheet href="..." type="text/css"?>

Comment 28

[Richard Marti (:Paenglab)]

Attachment: mini-day-box - use system background color v3

Next try with system arrows for Linux. The today button has on Linux a hover svg image for better visibility on HC themes.

Comment 29

[Andreas Nilsson (:andreasn)]

(In reply to Philipp Kewisch [:Fallen] from comment #27)
> (In reply to Andreas Nilsson (:andreasn) from comment #20)
> > I prefer css over images where possible. Simpler to change as the code is
> Just a note, you should be able to use a css stylesheet even for an svg
> file. Just give it an id and I think its the usual <?xml-stylesheet
> href="..." type="text/css"?>

Definitely, this was specifically regarding png vs css.

Comment 30

[Andreas Nilsson (:andreasn)]

Comment on attachment 565161 [details] [diff] [review]
mini-day-box - use system background color v3

As discussed on IRC, since -moz-appearance: button-arrow-previous/next; seems specific to Linux (?) using svg's for the arrows on Win and Mac is ok.
ui-review+ from me!

Comment 31

[Richard Marti (:Paenglab)]

Attachment: minimonth using system colors v3

This patch needs the mini-day-box patch applied first.

Win and Linux are using the same colors - no difference in code.
The othermonth days have now the same background color as the minimonth.
The "today" day has highlight as text color. The selected day has a highlight border.
The hovered days have a highlight background.

I haven't changed the Mac part because Mac has no special high contrast theme.

Comment 32

[Richard Marti (:Paenglab)]

Attachment: calendar-views using system colors

Now the main calendar part for Linux and Windows. Mac is still using the old colors (I only changed the title colors and arrows to match the other).

This patch needs the mini-day-box patch applied first.

I've used the same colors for today and selected as in Mini-Month.
I've used also under Linux svg images for the arrows because I didn't found a -moz-appearance with that big arrows.

Under Win I think everything works well also with HC themes. Under Linux with HC theme the tabs (Day, Week, Multiweek, Month) aren't visible as separated tabs. I haven't found matching border colors for them which are working well also under Ubuntu theme or Clearlooks.

Comment 33

[Andreas Nilsson (:andreasn)]

(In reply to Richard Marti [:paenglab] from comment #31)
> Created attachment 565370 [details] [diff] [review] [diff] [details] [review]
> minimonth using system colors v3
> 
> This patch needs the mini-day-box patch applied first.
> 
> Win and Linux are using the same colors - no difference in code.
> The othermonth days have now the same background color as the minimonth.
> The "today" day has highlight as text color. The selected day has a
> highlight border.
> The hovered days have a highlight background.
> 
> I haven't changed the Mac part because Mac has no special high contrast
> theme.

Looks good on Linux, looking at windows next.

Comment 34

[Andreas Nilsson (:andreasn)]

Comment on attachment 565370 [details] [diff] [review]
minimonth using system colors v3

As mentioned in Comment #21 I would rather see the current day use the outline (it can still have the highlight as text color too) and selected have Highlight as background color and Highlighttext as text color. As it is now the current date is slightly hard to spot in the Light HC theme.
Apart from that all looks good.

Comment 35

[Richard Marti (:Paenglab)]

Attachment: minimonth using system colors v4

I misunderstood you and crossed the selected with the current(today). This patch now switches this two. The other parts are unchanged.

This patch needs the mini-day-box patch applied first.

Comment 36

[Andreas Nilsson (:andreasn)]

(In reply to Richard Marti [:paenglab] from comment #35)
> Created attachment 566589 [details] [diff] [review] [diff] [details] [review]
> minimonth using system colors v4
> 
> I misunderstood you and crossed the selected with the current(today). This
> patch now switches this two. The other parts are unchanged.
> 
> This patch needs the mini-day-box patch applied first.

Just a quick note that there is an extra semicolon on like 144 in the patch. After fixing that the patch applies cleanly.

Comment 37

[Andreas Nilsson (:andreasn)]

(In reply to Richard Marti [:paenglab] from comment #35)
> Created attachment 566589 [details] [diff] [review] [diff] [details] [review]
> minimonth using system colors v4
> 
> I misunderstood you and crossed the selected with the current(today). This
> patch now switches this two. The other parts are unchanged.
> 
> This patch needs the mini-day-box patch applied first.

Can I get this too:

.minimonth-day[selected="true"] {
  background-color: Highlight;
  color: HighlightText;
}

Comment 38

[Andreas Nilsson (:andreasn)]

Comment on attachment 566589 [details] [diff] [review]
minimonth using system colors v4

Oops, last comment was a bit drive-by as I had to run to a meeting.

The selected item seems hard to spot under certain conditions, I think it would be better to do something like below.

.minimonth-day[selected="true"] {
  background-color: Highlight;
  color: HighlightText;
  border: 1px solid ButtonFace;
}

 ui-r+ with that fixed.

Comment 39

[Richard Marti (:Paenglab)]

Attachment: minimonth using system colors v5

Patch with changes following comment 38.

Setting ui-r+ referring comment 38.

Comment 40

[Andreas Nilsson (:andreasn)]

Comment on attachment 565580 [details] [diff] [review]
calendar-views using system colors

Looks good. For matching the minimonth, it might be good with a Highlight border around the current day. ui-r+ with that added.

Comment 41

[Decathlon]

Comment on attachment 565161 [details] [diff] [review]
mini-day-box - use system background color v3

As far as I can see it's everything OK. About the look, I tested only on Windows.

I don't try it, but maybe the [disabled] attribute could be applied directly to the class .miniday-nav-buttons instead of to each button with the id selector in the file today-pane.css.

A nit I noticed is a little difference in the rendering of the two arrows (left/right) as shown in the following zoomed screenshot.
Since the image is the same (one is the scaleX(-1) of the other), how can this happen? Not a patch's problem though.

r+

Comment 42

[Decathlon]

Attachment: little difference in the left/right svg arrows

Comment 43

[Richard Marti (:Paenglab)]

Attachment: mini-day-box - use system background - checked-in

Patch for check-in with .miniday-nav-buttons[disabled] instead of each button.

I think the different rendering of the two arrows comes from system anti-aliasing.

Carrying over r+ and ui-r+ from previous patch.

Comment 44

[Richard Marti (:Paenglab)]

Attachment: calendar-views using system colors V2

Patch using andreasn's proposal with highlight border around today day.

Setting ui-r+ according comment 40

Comment 45

[Decathlon]

Attachment: Minimonth on Win7 - An example with non system colors on HC themes

I repeat myself, I'm not an expert about UI, themes, accessibility and so on, so, since the patch about *minimonth* has got the ui review, I can simply tell my opinion.
IMHO we are attempting to make better a theme that will be used in the, let's say, 5%, maybe the 10% of the computers while we are making worse the default theme that will be used in the 95%-90%.
Using only system colors is a big restriction and the inevitable limitations that occur with this choice should affect mainly the less used theme.
E.g. IMHO with this patch (minimonth using system colors v5), the "selected" day in the minimonth gets a too prominent look compared with the "today" day: all highlight vs. bordered highlight (see screenshot 1st part), moreover when today is the selected day you can't distinguish it from a normal selected day, so you can't understand if today is in that month.

I think that using a bit of non-system color would not harm if we can keep a minimum of contrast in the element involved. 

e.g. (see screenshot 2nd part)
.minimonth-day[selected="true"] {
   background-color: #FFFABC; 
   color: black; 
   border: 1px solid #D9C585;
}


-------------------


I also tested patch "calendar-views using system colors V2" that's about the *calendar views*.
This patch also got the UI review + but here I don't agree *mostly* of the choice done:

- font dimension (well done only about the view tabs);
- day colors;
- border colors;
- day numbers on the box's left side;
- events get lost the gradient;
- events get lost horizontal and vertical padding;
- in multiweek/month view the event boxes are 2 pixels higher;
- drag shadow color;
- the position of the "today" text in the button in the header has changed again (see bug 465512 for details), but now with a gnomestripe theme it's going to be simpler to fix it;
- the padding around the views (I preferred the white that comes down from the tabs as before);
- ... .

Instead I like the new tabs  maybe with rounded corner (that has been changed and discussed again in bug 465512), and the absence of the light gray day label in the day boxes.

There are a few bugs:
- In multiweek and month views is missing the week days header top border and the right border on the extreme right(this last one causes a misalignment in all the headers);
- the view padding on the top size is missing and the left size needs to change like the right side;
- there isn't the selected day in month and multiweek views;
- in day and week views the week day header of the selected day gets bold but this behavior has been deleted in bug 526887 because it causes a modification in the columns' width when these are small.

IMHO in this patch, more than the previous, we are doing worse the default theme to guarantee a better high contrast theme.

Unfortunately I don't have the competence and knowledge to suggest another way (if exist), but is it not possible doing like are doing e.g. Google Calendar and HotMail in their web applications? I.e. marking with contrasting color only the UI lines and the text (see next screenshot about HotMail) and allow the default theme to be colored in *any way* we want.

Philipp, I would like to hear your opinion as well. This patch is going to change a lot in the look of the views, maybe would you like to take over the review?

Comment 46

[Decathlon]

Attachment: HotMail calendar on web page in HC theme

Comment 47

[Richard Marti (:Paenglab)]

(In reply to Decathlon from comment #45)
> 
> e.g. (see screenshot 2nd part)
> .minimonth-day[selected="true"] {
>    background-color: #FFFABC; 
>    color: black; 
>    border: 1px solid #D9C585;
> }

I'll let Andreas or Philipp decide, if this one hardcoded piece is okay.

> I also tested patch "calendar-views using system colors V2" that's about the
> *calendar views*.
> This patch also got the UI review + but here I don't agree *mostly* of the
> choice done:
> 
> - font dimension (well done only about the view tabs);

I haven't changed any font dimension, nor style. Something strange must happened with your version.

> - day numbers on the box's left side;

What's not good, the color?

> - events get lost the gradient;

I haven't changed anything on the events except the dragshadow.

> - events get lost horizontal and vertical padding;

Again, no change with padding.

> - in multiweek/month view the event boxes are 2 pixels higher;

Should be no change by me.

> - the position of the "today" text in the button in the header has changed
> again (see bug 465512 for details), but now with a gnomestripe theme it's
> going to be simpler to fix it;

Should be no change by me.

> - the padding around the views (I preferred the white that comes down from
> the tabs as before);

Should be no change by me.

> There are a few bugs:
> - In multiweek and month views is missing the week days header top border
> and the right border on the extreme right(this last one causes a
> misalignment in all the headers);

I see this borders.

> - the view padding on the top size is missing and the left size needs to
> change like the right side;

Should be no change by me.

> - there isn't the selected day in month and multiweek views;

The label with the date should have the highlight background color.

> - in day and week views the week day header of the selected day gets bold
> but this behavior has been deleted in bug 526887 because it causes a
> modification in the columns' width when these are small.

Guilty, but only in week view. I made this for a better feedback, but can revert this.

Again something must happen with your build because I haven't changed padding's or sizes.

> Philipp, I would like to hear your opinion as well. This patch is going to
> change a lot in the look of the views, maybe would you like to take over the
> review?

I can second that.

Comment 48

[Decathlon]

Ok, Richard it seemed strange.
I'm sorry, if you want to kill me I give you the authorization ;-)
The build is perfect but many problems was caused by a typo in your patch "calendar-views using system colors V2". In the line 1076 a "]" is missing:

+.calendar-month-day-box-day-off[relation="today",

and caused by that I saw a month view like this:
http://img585.imageshack.us/img585/2232/ss20111024103311.png

Sorry for not took a look to the error console before writing here (the UI review + confused me).

I'm going to examine the patch today. Just at first glance, about the selected day with the blue day date header I think should be avoided because in the past I try to propose something similar for the "today" day but it was rejected (see bug 455045 comment 6).

Comment 49

[Andreas Nilsson (:andreasn)]

(In reply to Decathlon from comment #45)
> Unfortunately I don't have the competence and knowledge to suggest another
> way (if exist), but is it not possible doing like are doing e.g. Google
> Calendar and HotMail in their web applications? I.e. marking with
> contrasting color only the UI lines and the text (see next screenshot about
> HotMail) and allow the default theme to be colored in *any way* we want.

As far as I'm aware we can't do changes that affects the HC themes only yet (that's bug #425598).
Thanks for your feedback on these changes, going to think about them during the day. I think I'm still leaning towards this new simpler appearance and behavior. I want Phillips thoughts on this too.

Comment 50

[Richard Marti (:Paenglab)]

(In reply to Decathlon from comment #48)
> Ok, Richard it seemed strange.
> I'm sorry, if you want to kill me I give you the authorization ;-)

No, never ;-)

> The build is perfect but many problems was caused by a typo in your patch
> "calendar-views using system colors V2". In the line 1076 a "]" is missing:
> 
> +.calendar-month-day-box-day-off[relation="today",
> 
> and caused by that I saw a month view like this:
> http://img585.imageshack.us/img585/2232/ss20111024103311.png
> 
> Sorry for not took a look to the error console before writing here (the UI
> review + confused me).

I'm sorry for the problems because of the typo, you should kill me ;-). I'll fix it with the next patch after your review and eventually changes after Philipp's comment.
 
> I'm going to examine the patch today. Just at first glance, about the
> selected day with the blue day date header I think should be avoided because
> in the past I try to propose something similar for the "today" day but it
> was rejected (see bug 455045 comment 6).

Yeah, but now it's a little bit different because the selected day has no tan background.

Comment 51

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Demo of how the views could look like without system colors

(In reply to Decathlon from comment #45)
> Created attachment 568952 [details]
> Minimonth on Win7 - An example with non system colors on HC themes
> 
> I repeat myself, I'm not an expert about UI, themes, accessibility and so
> on, so, since the patch about *minimonth* has got the ui review, I can
> simply tell my opinion.
> IMHO we are attempting to make better a theme that will be used in the,
> let's say, 5%, maybe the 10% of the computers while we are making worse the
> default theme that will be used in the 95%-90%.
> Using only system colors is a big restriction and the inevitable limitations
> that occur with this choice should affect mainly the less used theme.
> E.g. IMHO with this patch (minimonth using system colors v5), the "selected"
> day in the minimonth gets a too prominent look compared with the "today"
> day: all highlight vs. bordered highlight (see screenshot 1st part),
> moreover when today is the selected day you can't distinguish it from a
> normal selected day, so you can't understand if today is in that month.

I'm also not very happy with how Mozilla handles high contrast theming. The mentioned bug about exposing the high-contrast bit was almost closed WONTFIX and is not a blocker, so we are forced to stay with a very limited set of colors to make HC themes work.

In an ideal world, instead of removing more and more color in favor of default colors, I'd even like to expand the color set used in calendar. I spent a few hours together with a friend who is very good at design and he has given me a few new colors and styles that make the calendar view look very nice. Of course this would be counteractive to the HC views patch, but do we really want to sacrifice all those nice colors?

If there is a way to detect if a HC theme is installed and this is not yet exposed to CSS,  we (or maybe even Thunderbird) could write that attribute to the window and then add rules like:

window[highcontrast] .some-view-element {
   background-color: SomeSystemColor;
}

I've attached a screenshot of how the  month view could look like if we don't obey the system colors.

I'm happy to take over review of the minimonth patch if needed and surely I could also take over the views patch, but in the latter case I'd most likely disagree and r- it. Not because I'm trying to bash it down, I really appreciate that you are looking into this, but I just think that using system colors for everything doesn't cut it.

Comment 52

[Richard Marti (:Paenglab)]

Attachment: minimonth using system colors v6

Philipp gave a good hint to invert the background colors of the other-month and this-month to follow the Calendar-view. This patch implements this. This is the only change to the prvious one.

Comment 53

[Richard Marti (:Paenglab)]

Attachment: Lightning with most recent patches under Win7 Aero

This screenshot shows the Month view (with Tabs on top ;) ). The 24th is today and the 26th is selected.

Comment 54

[Richard Marti (:Paenglab)]

Comment on attachment 568755 [details] [diff] [review]
calendar-views using system colors V2

I talked with Philipp over IRC. The decision is we stop the minimonth an calendar-view implementation until Gecko offers High Contrast selectors. as Decathlon says, were fixing something for 5% and are making it for the other 95% worse isn't a good choice.

I'll land the miniday patch because it doesn't harm much and cancel the other review requests.

Decathlon thank you for your amount of work here.

Comment 55

[Matthew Mecca [:mmecca]]

(In reply to Philipp Kewisch [:Fallen] from comment #51)

> If there is a way to detect if a HC theme is installed and this is not yet
> exposed to CSS,  we (or maybe even Thunderbird) could write that attribute
> to the window and then add rules like:
> 
> window[highcontrast] .some-view-element {
>    background-color: SomeSystemColor;
> }


Is there a way we could pref this off? Instead of trying to detect the theme, offering a preference that would drop back to system colors? That might offer a solution for the 5% without limiting our default views.

Comment 56

[Richard Marti (:Paenglab)]

(In reply to Matthew Mecca [:mmecca] from comment #55)
> Is there a way we could pref this off? Instead of trying to detect the
> theme, offering a preference that would drop back to system colors? That
> might offer a solution for the 5% without limiting our default views.

Not that I know. Maybe somebody with JavaScript knowledge can make a pref for Lightning where the user can check in the preferences window or a pref in about:config. Then we could use:

minimonth[highcontrast] .some-view-element {
   background-color: SomeSystemColor;
}

This would be Lightning only.

Comment 57

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

(In reply to Richard Marti [:paenglab] from comment #56)
> (In reply to Matthew Mecca [:mmecca] from comment #55)
> > Is there a way we could pref this off? Instead of trying to detect the
> > theme, offering a preference that would drop back to system colors? That
> > might offer a solution for the 5% without limiting our default views.
> 
> Not that I know. Maybe somebody with JavaScript knowledge can make a pref
> for Lightning where the user can check in the preferences window or a pref
> in about:config. Then we could use:
Yes, an about:config pref would work out nicely, just set it in the common onload event handler here:

http://mxr.mozilla.org/comm-central/source/calendar/base/content/calendar-chrome-startup.js#40

Add something like this at the end of the function:

if (cal.getPrefSafe("calendar.view.useSystemColors", false)) {
  document.documentElement.setAttribute("highcontrast", "true");
}

You could also persuade Thunderbird to do this in their onLoad events, which means you get to use more colors there. In any case, you could then use the following CSS:

window[highcontrast] minimonth {
  background-color: SomeSystemColor;
}

Comment 58

[Richard Marti (:Paenglab)]

Pushed to comm-beta http://hg.mozilla.org/comm-central/rev/88ee178d968d

Comment 59

[Richard Marti (:Paenglab)]

Mini-day part
Pushed to comm-aurora http://hg.mozilla.org/releases/comm-aurora/rev/3d76059e165f
Pushed to comm-beta http://hg.mozilla.org/releases/comm-beta/rev/f9c9a95a86bc

Comment 60

[Richard Marti (:Paenglab)]

Attachment: minimonth using system colors v7

I added now the about:config preference calendar.view.useSystemColors to toggle between fixed colors and system colors. The selector for the systemcolors is now: window[systemcolors]

I've changed after a proposal of Philipp the background colors of 'this month' and 'other month' also in fixed colors mode to be consistent with the calendar view.

Comment 61

[Decathlon]

Comment on attachment 570537 [details] [diff] [review]
minimonth using system colors v7

It works fine but this code:

>+
>+    // Check if the system colors should be used
>+    if (cal.getPrefSafe("calendar.view.useSystemColors", false)) {
>+      document.documentElement.setAttribute("systemcolors", "true");
>+    }
> }

has to be moved inside the function commonInitCalendar() instead of commonFinishCalendar() otherwise it doesn't work (probably a paste error), moreover a 4 spaces indentation would equalize the file' style.

For pinstripe and gnomestripe I merely checked for typos or errors without testing.

r+ with the mentioned changes.

Comment 62

[Richard Marti (:Paenglab)]

Attachment: minimonth using system colors for check-in

Patch for check-in with silly paste error and indentation fixed.

I'll start now with the calendar-view.

Comment 63

[Richard Marti (:Paenglab)]

Attachment: calendar-views using system colors V3

Calendar-views using window[systemcolors]. I'm using for the .calendar-nav-control (inclusive the tabs) system colors because I'm thinking here it makes sense to use always system colors.

Comment 64

[Richard Marti (:Paenglab)]

One question: when this patches land, what should be done to inform the users about this config in about:config (eg. FAQ, release notes etc.)?

Comment 65

[Matthew Mecca [:mmecca]]

(In reply to Richard Marti [:paenglab] from comment #64)
> One question: when this patches land, what should be done to inform the
> users about this config in about:config (eg. FAQ, release notes etc.)?

Maybe this should have a setting in the preferences dialog.

Comment 66

[Richard Marti (:Paenglab)]

Attachment: New pref in pref window

(In reply to Matthew Mecca [:mmecca] from comment #65)
> (In reply to Richard Marti [:paenglab] from comment #64)
> > One question: when this patches land, what should be done to inform the
> > users about this config in about:config (eg. FAQ, release notes etc.)?
> 
> Maybe this should have a setting in the preferences dialog.

I tried it, but the checkbox worked inverted (checked for not using system colors), so I used a text which corresponds to the checkbox. Would this be okay with this text? And is the place under Views tab okay or is General better?

Comment 68

[Decathlon]

(In reply to Richard Marti [:paenglab] from comment #66)

> ...
> And is the place under Views tab okay or is General
> better?

IMHO would be better the "General" tab, but the decision is up to Philipp or Andreas.

Comment 69

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Before we start adding this to the Lightning prefs window, do you think you could propose this for Thunderbird instead and have Lightning make use of it? No matter where we add it, it would always be better placed in the Thunderbird part of the prefs window.

Regarding the UI text, you could consider changing the pref name so the checkbox is not inverted or indeed change the UI text. If you'd like to go with the latter try avoiding just negating the text, but rather rephrase it.

I assume you need something like "Reduce colors to allow high contrast themes" ?

Comment 70

[BJ]

I'm very late coming to this thread and now only because I might have posted a dupicate Bug 702245. I'm afraid I haven't read all the comments above, there are simply too many, but I did make a start from the top.

As a visually impaired user who needs white text on black I would like to say I agree completly with the suggestions from Zane 2011-07-13 11:00:26 PDT. I also been using TB and lignting for a number years and am right behind making the best mail/calendar client around.

I don't use the Windows High Contrast Black scheme because, basically, it's awaful. I simply modify the display appearance settings and set the Window object colours to white text on a black background. I also go through the ojects and set text colour to white, plus change fonts to arial and make them a little bigger.

A theme which completely overided the system colours might be fine providing it's basic ie. I can't cope with graduated colour backgrounds and 3d effects (really don't like the new 3d buttons in Thunberbird - can't read the text on them easily). Or, better still, use the Windows settings. But please don't mix and match taking some parts from the OS and setting others in the theme. Also remember that Thunderbird has settings for text and background - which I've changed to give me white text on black.

I am very sorry if these comments of mine are too late. But I'm really really pleased you guys are taking this issue on board and making such quick progress. Thank you!

Comment 72

[Richard Marti (:Paenglab)]

Attachment: Add pref in General tab

I've put the pref now in General tab. I've found the problem with the inverted functionality, I had copied inverted="true" from an other pref. Removing this solved this.

What do you think about the wording? To take effect of a change TB needs to restart. I think this needs JS magic but as you know, I'm a noob in this. If you can head me to a similar function I can try to copy this.

(In reply to Philipp Kewisch [:Fallen] from comment #69)
> Before we start adding this to the Lightning prefs window, do you think you
> could propose this for Thunderbird instead and have Lightning make use of
> it? No matter where we add it, it would always be better placed in the
> Thunderbird part of the prefs window.

Because TB don't use this functionality (it uses more or less always system colors) I think it would be hard to add there.

Comment 73

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

(In reply to Richard Marti [:paenglab] from comment #72)
> Created attachment 580727 [details] [diff] [review]
> Add pref in General tab
> 
> I've put the pref now in General tab. I've found the problem with the
> inverted functionality, I had copied inverted="true" from an other pref.
> Removing this solved this.
> 
> What do you think about the wording? To take effect of a change TB needs to
> restart. I think this needs JS magic but as you know, I'm a noob in this. If
> you can head me to a similar function I can try to copy this.
Regarding the wording, I think we should make it less technical. Something more in terms of "Optimize colors for accessibility" maybe? What kind of js magic are you thinking of? A bar that says a restart is required? We could just add a text to the label, i.e. (requires restart). On the other hand, what exactly makes this dependent on a restart? You could add a pref observer on the window (maybe we even have one) that switches the attribute when the pref is switched?

> 
> (In reply to Philipp Kewisch [:Fallen] from comment #69)
> > Before we start adding this to the Lightning prefs window, do you think you
> > could propose this for Thunderbird instead and have Lightning make use of
> > it? No matter where we add it, it would always be better placed in the
> > Thunderbird part of the prefs window.
> 
> Because TB don't use this functionality (it uses more or less always system
> colors) I think it would be hard to add there.

I was thinking maybe Thunderbird is interested in using more than system colors too?

Comment 74

[Richard Marti (:Paenglab)]

(In reply to Philipp Kewisch [:Fallen] from comment #73)
> (In reply to Richard Marti [:paenglab] from comment #72)
> > Created attachment 580727 [details] [diff] [review]
> > Add pref in General tab
> > 
> > I've put the pref now in General tab. I've found the problem with the
> > inverted functionality, I had copied inverted="true" from an other pref.
> > Removing this solved this.
> > 
> > What do you think about the wording? To take effect of a change TB needs to
> > restart. I think this needs JS magic but as you know, I'm a noob in this. If
> > you can head me to a similar function I can try to copy this.
> Regarding the wording, I think we should make it less technical. Something
> more in terms of "Optimize colors for accessibility" maybe? What kind of js
> magic are you thinking of? A bar that says a restart is required? We could
> just add a text to the label, i.e. (requires restart). On the other hand,
> what exactly makes this dependent on a restart? You could add a pref
> observer on the window (maybe we even have one) that switches the attribute
> when the pref is switched?

Yes I meant a pref observer to change the window attribute.

> > (In reply to Philipp Kewisch [:Fallen] from comment #69)
> > > Before we start adding this to the Lightning prefs window, do you think you
> > > could propose this for Thunderbird instead and have Lightning make use of
> > > it? No matter where we add it, it would always be better placed in the
> > > Thunderbird part of the prefs window.
> > 
> > Because TB don't use this functionality (it uses more or less always system
> > colors) I think it would be hard to add there.
> 
> I was thinking maybe Thunderbird is interested in using more than system
> colors too?

Are you on Tuesday at the StatusMeeting. Could you ask them?

Comment 75

[BJ]

I don't inow it fhis is relevent but it might indicate an associated issue.

I have set the TB colours to have white text on black. When I send a message to the printer I get a page of solid black (black  text on black). But if I set the TB colours back to black on white it prints corrently (black on white).

Comment 76

[Richard Marti (:Paenglab)]

(In reply to BJ from comment #75)
> I don't inow it fhis is relevent but it might indicate an associated issue.
> 
> I have set the TB colours to have white text on black. When I send a message
> to the printer I get a page of solid black (black  text on black). But if I
> set the TB colours back to black on white it prints corrently (black on
> white).

This bug has nothing to do with printing. Please file a new bug for this problem.

Comment 77

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Attachment: Prefs observer patch - v1

Here's the js magic to set the attribute on the window, feel free to merge with any upcoming iterations.

Comment 78

[Richard Marti (:Paenglab)]

Attachment: Add pref in General tab with Prefs observer

Thanks Philipp for the observer code. The pref change works now like a charm.
I'm giving the review to Decathlon so you don't have to review your own code ;)

This patch needs the minimonth patch (attachment 574044 [details] [diff] [review]) first.

Comment 79

[Decathlon]

Comment on attachment 574160 [details] [diff] [review]
calendar-views using system colors V3

It seems everything fine apart from this rule:
 calendar-month-day-box-item[selected="true"] .calendar-color-box
that seems defined twice. Could you please double check?

I guess the black color for the month/week name text in the view header is unavoidable because of the system color assigned to the navigation buttons. Isn't it?

With the HC theme the selected day is more identifiable than the "today" day, but I think this is unavoidable as well.

Maybe the color of the labels that show the start-end time while a drag occurs in week/day view, could be changed with a gray color (also visible on black background), because while dragging, the selected event is a light yellow (the same for every HC theme) and the labels over it are not so visible with themes HC1 and HC2 in Windows7.

Another little issue, not due to this patch though, is that when I change the theme to an HC one, the font is also changed and I can see that when the "today" button is pressed, the whole view is being shifted one pixel to the top, not in a permanent way, only when the button is pressed. Maybe the 
button's height should be defined in a different manner, but this is matter for another bug.

Comment 80

[Richard Marti (:Paenglab)]

Attachment: calendar-views using system colors for check-in

(In reply to Decathlon from comment #79)
> Comment on attachment 574160 [details] [diff] [review]
> calendar-views using system colors V3
> 
> It seems everything fine apart from this rule:
>  calendar-month-day-box-item[selected="true"] .calendar-color-box
> that seems defined twice. Could you please double check?

Correct, I forgot to remove this after landing of bug 698760

> I guess the black color for the month/week name text in the view header is
> unavoidable because of the system color assigned to the navigation buttons.
> Isn't it?

Yes that's the reason.

> With the HC theme the selected day is more identifiable than the "today"
> day, but I think this is unavoidable as well.

Andreas wished to be consistent between minimonth and Calendar-views.

> Maybe the color of the labels that show the start-end time while a drag
> occurs in week/day view, could be changed with a gray color (also visible on
> black background), because while dragging, the selected event is a light
> yellow (the same for every HC theme) and the labels over it are not so
> visible with themes HC1 and HC2 in Windows7.

I'm using now GrayText.

> Another little issue, not due to this patch though, is that when I change
> the theme to an HC one, the font is also changed and I can see that when the
> "today" button is pressed, the whole view is being shifted one pixel to the
> top, not in a permanent way, only when the button is pressed. Maybe the 
> button's height should be defined in a different manner, but this is matter
> for another bug.

This happens also without my patch because of the
padding-top: 0px !important; /* a workaround to center the label vertically on Windows */
for the .today-navigation-button

I'll file a bug for this.

Comment 81

[Decathlon]

Comment on attachment 581028 [details] [diff] [review]
Add pref in General tab with Prefs observer

The patch works, but since the method init() (inside calendarWindowPrefs) calls the method observe(), the line

>+    calendarWindowPrefs.init();

already checks whether the system colors should be used while the initialization occurs,
hence the following "if" can be deleted:

>     // Check if the system colors should be used
>     if (cal.getPrefSafe("calendar.view.useSystemColors", false)) {
>         document.documentElement.setAttribute("systemcolors", "true");
>     }

Otherwise you could leave the above "if" and deleting the line with this.observe() inside the init() method:

>+        // Make sure the system colors attribute is set on the window
>+        this.observe(null, "nsPref:changed", "calendar.view.useSystemColors");


r+ with the first or the second fix.

However, activating the preference while TB running doesn't allow to get the full HC theme functionality because of the svg images in the navigation buttons. Without a restart these images don't get the right color with the HC themes and without them it seems like the theme doesn't work properly. I think that the text in the checkbox should have a reference to the TB restart (unless the color changing in the svg images can somehow be forced without a restart).

Comment 82

[Richard Marti (:Paenglab)]

Attachment: Add pref in General tab with Prefs observer for Check-in

(In reply to Decathlon from comment #81)
> Comment on attachment 581028 [details] [diff] [review]
> Add pref in General tab with Prefs observer
> 
> The patch works, but since the method init() (inside calendarWindowPrefs)
> calls the method observe(), the line
> 
> >+    calendarWindowPrefs.init();
> 

I tried to remove this but then the changes aren't immediately.
 
> already checks whether the system colors should be used while the
> initialization occurs,
> hence the following "if" can be deleted:
> 
> >     // Check if the system colors should be used
> >     if (cal.getPrefSafe("calendar.view.useSystemColors", false)) {
> >         document.documentElement.setAttribute("systemcolors", "true");
> >     }
> 

This is used on startup to set the attribute. I leave this.

> Otherwise you could leave the above "if" and deleting the line with
> this.observe() inside the init() method:
> 
> >+        // Make sure the system colors attribute is set on the window
> >+        this.observe(null, "nsPref:changed", "calendar.view.useSystemColors");
> 

Removed this and it still works.

> However, activating the preference while TB running doesn't allow to get the
> full HC theme functionality because of the svg images in the navigation
> buttons. Without a restart these images don't get the right color with the
> HC themes and without them it seems like the theme doesn't work properly. I
> think that the text in the checkbox should have a reference to the TB
> restart (unless the color changing in the svg images can somehow be forced
> without a restart).

The svg images are always used - no change happens here when using system colors.

I would say a user is already on a HC theme or a theme with special colors and switches then to the system colors mode. I think a user needing such a theme doesn't work on default theme and because Lightning supports now system colors, he decides to switch to a HC theme.

Comment 83

[Decathlon]

(In reply to Richard Marti [:paenglab] from comment #82)

> 
> I tried to remove this but then the changes aren't immediately.
>  

I gave you a bad explanation. Sorry.
Let's say that you can delete *either* these lines:

    // Check if the system colors should be used
    if (cal.getPrefSafe("calendar.view.useSystemColors", false)) {
        document.documentElement.setAttribute("systemcolors", "true");
    }
    
*or* these lines:
   
    // Make sure the system colors attribute is set on the window
    this.observe(null, "nsPref:changed", "calendar.view.useSystemColors");
    
because both do the same work during the *initialization* phase (i.e. setting the "systemcolors" attribute to the preference value), and both aren't called *anymore* after the initialization.


> I would say a user is already on a HC theme or a theme with special colors
> and switches then to the system colors mode. I think a user needing such a
> theme doesn't work on default theme and because Lightning supports now
> system colors, he decides to switch to a HC theme.

This sounds reasonable.


Richard, only as information, have you tried to explore what reported by BJ in comment #70? i.e. try to set the background color with the settings that came from Thunderbird's Display option.
I don't know whether it is feasible, actually I'm even not able to make working those settings on my Thunderbird, but maybe there is something to set that I don't know.

Comment 84

[Richard Marti (:Paenglab)]

(In reply to Decathlon from comment #83)
> Richard, only as information, have you tried to explore what reported by BJ
> in comment #70? i.e. try to set the background color with the settings that
> came from Thunderbird's Display option.
> I don't know whether it is feasible, actually I'm even not able to make
> working those settings on my Thunderbird, but maybe there is something to
> set that I don't know.

Yea I saw this comment. Where exists these colors: -moz-default-background-color, -moz-default-color, -moz-hyperlinktext, -moz-activehyperlinktext and -moz-visitedhyperlinktext. TB lets you only set the foreground and background color through the prefs window. The other colors have to be configured with about:config. I haven't used this colors because I thought it would be to complicated for the normal user when he has to set the theme and then also this colors. And with only this two colors it would be hard to set the correct elements to still fit with the other element colors.

BJ: Maybe we can think about an improvement with this colors in a followup bug, when you have tested this bug after landing.

Comment 85

[Richard Marti (:Paenglab)]

Pushed to comm-central:
<http://hg.mozilla.org/comm-central/rev/9d1481961771>
<http://hg.mozilla.org/comm-central/rev/31541cf7e951>
<http://hg.mozilla.org/comm-central/rev/f30f06893902>

Comment 86

[BJ]

(In reply to Richard Marti [:paenglab] from comment #84)
> (In reply to Decathlon from comment #83)
> > Richard, only as information, have you tried to explore what reported by BJ
> > in comment #70? i.e. try to set the background color with the settings that
> > came from Thunderbird's Display option.
> > I don't know whether it is feasible, actually I'm even not able to make
> > working those settings on my Thunderbird, but maybe there is something to
> > set that I don't know.
> 
> Yea I saw this comment. Where exists these colors:
> -moz-default-background-color, -moz-default-color, -moz-hyperlinktext,
> -moz-activehyperlinktext and -moz-visitedhyperlinktext. TB lets you only set
> the foreground and background color through the prefs window. The other
> colors have to be configured with about:config. I haven't used this colors
> because I thought it would be to complicated for the normal user when he has
> to set the theme and then also this colors. And with only this two colors it
> would be hard to set the correct elements to still fit with the other
> element colors.
> 
> BJ: Maybe we can think about an improvement with this colors in a followup
> bug, when you have tested this bug after landing.

I would be very happy to try it. I guess I'm unusual. I don't use the Winddows HC as provided but do set background anf text colour myself to white on black. And I then use the TB Display options to do the same within the TB default scheme.

Thanks.

Comment 87

[BJ]

I see the status of this bug has changed to FIXED. I'm running Lightning 1.2 and it's not fixed for me!

Comment 88

[BJ]

Attachment: Shows Minimonth not fixed with Lightning 1.2

Note the mouse pointe puts a black box around the buttons othrewise you wouldn't know they were there. But also note the text on the buttons is still not visible.

And also note that below the Minimonth pain the text and background has changed to white on black. Is this section taken from the OS settings (mine are white on black)?

Comment 89

[Richard Marti (:Paenglab)]

BJ, have you in Tools/Options then Lightning/General checked 'Optimize colors for accessibility'?

Comment 90

[BJ]

Attachment: Lightning 1.2 showing failure to set all the colours

I have set my Win7 colours to have lime green text on a red backround.

This clearly shows that not all the colours have been set in the GUI and some have been taken from the OS. You must either set both foreground (text) and background colours, or neither. Please see the W£C WAI guidelines on this at:

http://www.w3.org/TR/WCAG-TECHS/F24.html

Comment 91

[BJ]

Please see the 2 attachments I've just aaded.

Also note that the second attachment show a problem in the TB interface tab buttons. The first has text colour set by TB, the seconc set by my OS.

Comment 92

[BJ]

(In reply to Richard Marti [:paenglab] from comment #89)
> BJ, have you in Tools/Options then Lightning/General checked 'Optimize
> colors for accessibility'?

Hi Richard. No I haven't. Didn't realise it was there. I'll give it a try but you can see that the default colours have not followed basic accessibilty guidelines.

I hit this issue so many times on web sites. Firefox doesn's have this problem anyway. But I encounter it all the time in TB (now fixed in some places) and obviously in Lightning it is a major oversight of the guidelines.

I should need to select any special accessibilty features. I have my own software to set things how I want which works fine providing the foreground/background guidelines have been followed.

Comment 93

[BJ]

(In reply to Richard Marti [:paenglab] from comment #89)
> BJ, have you in Tools/Options then Lightning/General checked 'Optimize
> colors for accessibility'?

Hi again Richard.

I did the following:

1) Clicked on the TB Tools button
2) Clicked on the Add-ons button
3) Scrolled down to Lightning and clicked it's Options button

This opeen the options for TB not for Lightnign.

I'm running TB10 and Lightning 1.2

Comment 94

[BJ]

I left the word "not" out of the last paragraph of comment 92. It should have read:

Comment 95

[BJ]

 I should NOT need to select any special accessibilty features. I have my own software to set things how I want which works fine providing the foreground/background guidelines have been followed.

Comment 96

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Sorry, thats not going to happen. Given the complexity of the calendar views, the default theme would look very dull if we only use the very very limited set of system colors for the views. If we turn on this feature by default, users that are not interested in using system colors will be turned down. And who goes into the lightning options expecting to make the colors better? Its the first impression that counts, and that shouldn't be limited to maybe 5 colors.

Comment 97

[Richard Marti (:Paenglab)]

(In reply to BJ from comment #93)
> 3) Scrolled down to Lightning and clicked it's Options button
> 
> This opeen the options for TB not for Lightnign.

Thats right. Now on the right you are seeing a Lightning tab. Select it and you can choose your needs.

Comment 98

[BJ]

I'm not asking you to do that. I'm asking you to choose the colours you want and set both foregroung and background colour. At the moment you are only setting some of the colours you want, and allowing the OS to set the rest. Please please please set all you colours not take this half and half approach where you let the OS set the text colour and you set the background.

This is basic common sense and it breaks my heart that W3C needed to outline as a guideline.

Comment 99

[BJ]

What I woulde ask of your choice of colours is that you ensure there is sufficent contrast between foreground and background eg. don't put pale blue on pale grey.

The default view should be fairly simple. What's the point of allowing personas and themes otherwise?

Comment 100

[BJ]

My second attachment today shows where you have failed to set the colours. There shold be no lime green or red if you have set them all.

Comment 101

[BJ]

Attachment: Lightning 1.2 gereral options tab

Lightnig 1.2 Options tab

Comment 102

[BJ]

(In reply to Richard Marti [:paenglab] from comment #97)
> (In reply to BJ from comment #93)
> > 3) Scrolled down to Lightning and clicked it's Options button
> > 
> > This opeen the options for TB not for Lightnign.
> 
> Thats right. Now on the right you are seeing a Lightning tab. Select it and
> you can choose your needs.

Sorry Richard I still do see it. Please see my latest screen shot.

But I@m afraid I have to repeat that had ALL the colours of the interface been set I wouldn't need to be looking for someting like this.

Comment 103

[Richard Marti (:Paenglab)]

Yeah, the Target Milestone is 1.3. So this bug is in Lightning 1.3 and not in 1.2.

Comment 104

[BJ]

(In reply to Philipp Kewisch [:Fallen] from comment #96)
> Sorry, thats not going to happen. Given the complexity of the calendar
> views, the default theme would look very dull if we only use the very very
> limited set of system colors for the views. If we turn on this feature by
> default, users that are not interested in using system colors will be turned
> down. And who goes into the lightning options expecting to make the colors
> better? Its the first impression that counts, and that shouldn't be limited
> to maybe 5 colors.

Phillip. Thunderbird had exactly this same problem with it's search feature resulst. Once reported they fixed it pretty quickly. Do you not see that what is reuuired is very simple and you can make Lightning as pretty as you like.

I've been an IT proffesional for 27 years and am head of our Unix team. I do know what I'm talking about. I'm forced to use Windows because of the flexibilty of the access software I use (for which I'm a bera tester).

I have reported this issue to many manufacturers. Most rececntly Adobe who are going to fix the problem in their next release.

Comment 105

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

This is getting slightly out of hand. If you would like to discuss this, then the newsgroups are the right place to go. I'm happy it was easy for Thunderbird's search feature (which I believe uses 2-3 colors).

I'm happy you have spent such a long time in the profession, but the flipside of what you are saying suggests you think I don't have sufficient experience to know what I am doing or saying.

I don't see a pretty way of using only system colors in the view as we use much more colors than just 2-3 to make the views look pleasant. If you have a suggestion to make, please do attach a mockup of what system colors you would like to use where.

Comment 106

[BJ]

(In reply to Philipp Kewisch [:Fallen] from comment #105)
> This is getting slightly out of hand. If you would like to discuss this,
> then the newsgroups are the right place to go. I'm happy it was easy for
> Thunderbird's search feature (which I believe uses 2-3 colors).
> 
> I'm happy you have spent such a long time in the profession, but the
> flipside of what you are saying suggests you think I don't have sufficient
> experience to know what I am doing or saying.
> 
> I don't see a pretty way of using only system colors in the view as we use
> much more colors than just 2-3 to make the views look pleasant. If you have
> a suggestion to make, please do attach a mockup of what system colors you
> would like to use where.


Phillip. I'm not suggesting you don't know what you are doing. But have not understood what I'vw been trying to point out. I'm not asking you to use only system colours. I'm asking you to use whatever colours you want. But I am asking that when you set a background colour you alos set a forground (test colour). The attachment I sent with the nast colours showed which colours had not been set. Yhere should not have been any lime green or red had those part of the interface had the colours set.


If you look at my first attachment from today. Look at the difference between the main calander pane on the right. And the Minimontbh pane on the left. The test at the top of the Minimonth pane is not visible. The text at the top of the main pane is visible. This is because the text colour for the Minimonth was not set. That is why it appears as lime green in my second attachment.

The Monimonth top section has the background set to white by Lightning. But because the text colour has not been set it's taking the colour from the OS. Therefore those of us using white text get white on white. It's just a matter of setting the text colour to black, if you want black, within Lightning.

The W3C guideline confirm this, and for web designers suggest solutions to achieve it. 

The only reason I mentioned my longevity was to try to get to review what I was saying because I felt my comments had only been glanced at and not understoo.

Comment 107

[Stefan Sitter [:ssitter]]

Please read the complete bug information. This bug is marked fixed for Lightning 1.3 that is currently in beta testing. You are using the previous release Lightning 1.2. Of course you don't see the fix. Please retest with the appropriate version.

Comment 108

[BJ]

I now have Lightning 1.3 and the Minimonth problem has not been fixed. Although the main calander window has been improved. There are still some colours in the UI that need to be set. I will upload a coulple of screenshots to demonstrate.

If forground colour has been set but not backround, or vice versa, then it can cause a real accessibility problem for visually impaired people. BOTH forground and background colour must bet set, or BOTH must not be set. The  point is that forground and backgroung need to be treated together and not just set one of them.
 
I refer again to the W3C WAI guideline which explain it better than me: http://www.w3.org/TR/WCAG-TECHS/F24.html

Comment 109

[Richard Marti (:Paenglab)]

BJ, this bug is closed. Please open a new bug which addresses directly your concerns and put your screenshots there.

This bug is already long and it would be easier to follow and address your issues in a new bug.

Comment 110

[BJ]

Attachment: L1.3 Minimonth colour problem-

This image shows that the text colour has not been set for the text at the top of the Minimonth frame. The name of the month and button text to change month can't be seen. But the same part of the main calander frame displays well. Perhaps the Minimonth frame could be made to look like the main frame?

Comment 111

[BJ]

Attachment: L1.3 image which shows where colours have not been set in the UI

This image shows where colours have not been set in the UI. If all colours had been set there would be no lime green or red.

The lime green in the Minimonth frame shows the text colour has not been set and so the colour has been taken from the OS settings (where I set it to lime green). This does not comply with the W3C WAI guidelines on needing to set BOTH forground and background colour.

It also shows regions of the UI with lime green on red which does domply with the guideline since BOTH forground and background colour not been set. But I think this shows where UI colours need to be set in order to ensure the look of the UI is maintained no matter what colours are set in the OS.

In short. If you want the Minimont text to be black. Please set it to balck and don't let it default to OS colours.

If I'm repeating myself it's because I don't think I've made myself understood previously. I'm not asking for any special colours to be used. I'm asking that the colurs that are wanted be set. And I'm trying to show where this has not yet happened.L

Comment 112

[BJ]

(In reply to Richard Marti [:paenglab] from comment #109)
> BJ, this bug is closed. Please open a new bug which addresses directly your
> concerns and put your screenshots there.
> 
> This bug is already long and it would be easier to follow and address your
> issues in a new bug.

Oh hesk. Just spotted your comment after all that work :(  Originally I did log it as a separate bug, then it was decided it was a duplicate of this one. Then it was deemed that it was fixed when it was only fixed in parts of the UI but in Minimonth which was my origianl point. The solution lies in this bug report and if I create a new one I'd only have to refer back to this one???

Phiipp - should I raise a new bug? I do take Richard's point about this one being rather long.

Comment 113

[Richard Marti (:Paenglab)]

I would say, you are misinterpreting your results. The red and lime green colors are saying Lightning is using the system colors correctly (defined to use this colors) and in your setting the minimonth and calendar-view isn't using the system colors (you can change this in options -> lightning -> general -> optimize colors for accessibility). Using system colors means TB and Lightning are following the color scheme the system uses. Using fixed (not system colors) ends in appearing as an alien in the system (set dark Hight Contrast in your system and check how minimonth and calendar-view are looking with the bright colors). And the system colors are not only two colors, also the Grey areas and black text in Thunderbird are system colors (they are grey because you haven't changed them to red or lime green).

And again setting foreground and background doesn't mean to use custom colors. Also system colors are colors and this colors are making a program a part of a system and not an alien (like for example ITunes on Windows).

Comment 114

[BJ]

(In reply to Richard Marti [:paenglab] from comment #113)

Hi again Richard.

> I would say, you are misinterpreting your results.

I am. But I'm obviously not being clear enough. I urge you to take a look at that link where they explain it really well.

The red and lime green
> colors are saying Lightning is using the system colors correctly

Only when we have lime green on red. In Minimonth we have lime green on white. The lime green is coming from the OS but the white is coming from Lightning. The user may have set any colour in their OS for the text but the background is set to qhite. This is my problem. In my OS I have text set to white and Lightning has set the background in Minimonth to white. You can see the result of that in my first screenshot - white on white = invisible text. That first screen shot is how Lightning appears to me in real life.

> (defined to
> use this colors) and in your setting the minimonth and calendar-view isn't
> using the system colors

Minimonsth is using system colourrs for the text at the top. Looke at the difference between the top of the main pain and Minimonth.

> (you can change this in options -> lightning ->
> general -> optimize colors for accessibility).

Ah. I'd forgotten that. Somebody mentioned before when I was on 1.2. It could be just rignt for me :)

> Using system colors means TB
> and Lightning are following the color scheme the system uses. 

Yes. Excellent. Eccept TB sets its own colours in a few places too which can be a problem.

> Using fixed
> (not system colors) ends in appearing as an alien in the system (set dark
> Hight Contrast in your system and check how minimonth and calendar-view are
> looking with the bright colors). And the system colors are not only two
> colors, also the Grey areas and black text in Thunderbird are system colors
> (they are grey because you haven't changed them to red or lime green).

I only changed the colours of the Window Text and Windown Background objects. To change those colours I would have had to change the Windowns 3D Objects colours. But lets look at one thing at a time. (3D objects have both forground and background colours too for text and background, and these are independent of the Window Text and Window Background).

> 
> And again setting foreground and background doesn't mean to use custom
> colors. Also system colors are colors and this colors are making a program a
> part of a system and not an alien (like for example ITunes on Windows).

I didn't follw that.

I totally agree with your comment about not wanting thngs to look Alien. But a comment further up from someone on the dev team said I wouldn't be allowed to set my own colours because I might make the UI look nasty and they wanted control over the appearance to ensure the product looked good. I'm being bettered from two sides.

I don't really care what is done. All I'm asing is that if a forground colour is set in Lightning then the background colour should also be set in Lightning. And if a background colour is set in Lightnigh then the forground colour is also set in Lightning. (The later is problem in Minimonth - forground is from the OS but background is from Lightnign). I'm also happy if system colours are used.

Just stick to the guideline about setting both forground and background colours, or neither forground and background colours. Iv'e obviously made the problem seem harder than it is somehow.

Anyway. I'm itching to try the new accessibilty settings...

Bruce

Comment 115

[BJ]

Richard,

Several years ago myself, and a few others. reported the Minimonth problem. They were rightly deamed duplicates and I think my report was chosen as the primary. Then after a couple of years of nothing happened it was decided my report was a duplicate of this GTK issue in Linux. You can see early comments from others like me towards the top.

Our original reports were for MS Windows. And I'm not sure if they rreally were dupliicates. Anyway here we are many years on and I seem to be starting agian after getting a bashing on this thread.

Can I suggest that before a bug is determined FIXED that the duplicate problems flagged are taken a second look at first. Otherwise they get lost like this one.

Oh well. The sky is blue and the sun is shining :)

Bruce

Comment 116

[BJ]

The accessibility setting ROCKS !!!

Nice job! Thanks.

(But I['m still right about the need to set both forground and background colours and not setting only one of them (or not setting them BOTH)

Bruce :)