Tk Source Code

As of [dbc4faf03f] the default field background of Ttk entry widgets under macOS Aqua is systemWindowBackgroundColor rather than systemTextBackgroundColor. This is only noticeable under light mode, where the Ttk entry field background is gray rather than white.

The ttk::style configure . … command near the beginning of aquaTheme.tcl first sets -background to systemWindowBackgroundColor. Prior to [dbc4faf03f] a subsequent ttk::style configure TEntry … command would then set -background to systemTextBackgroundColor. For the aqua Ttk theme, -background is treated as the -fieldbackground when the latter is not set, and -fieldbackground is not set by default.

Originally reported by a Tcl::pTk user: https://github.com/chrstphrchvz/perl-tcl-ptk/issues/21

Thank you Christoper.  I think I incorporated all of your suggestions.

I will try to think about what to do about the fieldbackground alias in 8.7.

My immediate suggestion remains to remove the couple of lines from aquaTheme.tcl which set -fieldbackground for TEntry and TSpinbox, so that only -background is set in those cases.

I.e.:

--- library/ttk/aquaTheme.tcl.orig
+++ library/ttk/aquaTheme.tcl
@@ -44,8 +44,7 @@ namespace eval ttk::theme::aqua {
        # Entry
        ttk::style configure TEntry \
            -foreground systemTextColor \
-           -background systemTextBackgroundColor \
-           -fieldbackground systemTextBackgroundColor
+           -background systemTextBackgroundColor
        ttk::style map TEntry \
            -foreground {
                disabled systemDisabledControlTextColor
@@ -66,8 +65,7 @@ namespace eval ttk::theme::aqua {
        # Spinbox
        ttk::style configure TSpinbox \
            -foreground systemTextColor \
-           -background systemTextBackgroundColor \
-           -fieldbackground systemTextBackgroundColor
+           -background systemTextBackgroundColor
        ttk::style map TSpinbox \
            -foreground {
                disabled systemDisabledControlTextColor

See patch in [3c69cab43f] for remaining highlight colors.

I'm not sure whether I fully understand the concern over different appearance between platforms; I would appreciate if someone else can offer their understanding or help bridge ours.

My immediate suggestion remains to remove the couple of lines from aquaTheme.tcl which set -fieldbackground for TEntry and TSpinbox, so that only -background is set in those cases. That way a program is free to set either -background or -fieldbackground, each achieving the same effect.

Alternatively, to simplify things and reduce inconsistency with other themes, I think the -background compatibility alias for -fieldbackground should be disallowed in Tk 8.7. I personally would be fine with it being disallowed 8.6.12 as long as the documentation is updated to say that using -background instead of -fieldbackground is disallowed as of 8.6.12.

Christopher, can you provide a patch for the other default values that you
mentioned?

Thank you Christopher.  It was sloppy of me to neglect to deal with the defaults
and the insert background change was an egregious mistake on my part.  I have
committed the changes you suggested for the defaults.

Now I need you to explain what you think should be done with -fieldbackground.
I really don't know.  I don't like the idea of a code paradigm which produces
something that looks fine and makes sense on some platforms but looks terrible
on macOS.

There are other DEF_*_HIGHLIGHT colors for other widgets currently hardcoded to BLACK which should probably be updated to NORMAL_FG as well.

I appreciate the effort to get this resolved, but I am not completely satisfied with the changes that were merged.

To reiterate my comment from 2021-03-06 07:17:28:

• Setting -fieldbackground by default prevents programs from using the -background compatibility alias as currently stated in the documentation for the aqua theme (note that it is an error to set -fieldbackground to {} if it is already set to a valid color).

• The changes to tkMacOSXDefault.h were unrelated to this issue and so I felt were unexplained. I have now examined the effects those changes:

  • DEF_ENTRY_HIGHLIGHT_BG and DEF_TEXT_HIGHLIGHT_BG (-highlightbackground, the background of the highlight area around the non-Ttk entry and text widgets) are now TEXT_BG (systemTextBackgroundColor) instead of NORMAL_BG (systemWindowBackgroundColor). I believe this should be reverted for consistency with other platforms (X11 and Windows) where these are still NORMAL_BG and for consistency with the color of nearby or containing widgets whose default backgrounds are also NORMAL_BG.

  • DEF_ENTRY_INSERT_BG (-insertbackground, the color of the insertion cursor for non-Ttk entry widgets) is now TEXT_BG (systemTextBackgroundColor) instead of NORMAL_FG (systemTextColor). I strongly believe this should be reverted, because the insertion cursor color is now the same as -background (the text field background), making the cursor appear invisible.

  • DEF_ENTRY_READONLY_BG_COLOR (-readonlybackground, the color of the non-Ttk entry widget text field background when -state is readonly) is now TEXT_BG (systemTextBackgroundColor) instead of NORMAL_BG (systemWindowBackgroundColor). I believe this should be reverted for consistency with other platforms, where -readonlybackground is the same color as -disabledbackground rather than -background.

  • DEF_TEXT_HIGHLIGHT (-highlightcolor of the text widget) is now NORMAL_FG (systemTextColor) instead of BLACK. This change is arguably correct, because this makes the highlight of a focused text widget noticeable under dark mode, but I feel the check-in comment should mention why this change is desirable.

Hi Csaba, sorry for the slow response.  I made the same change for the
ttk::spinbox and merged the fix.  I will close the ticket now.

Any chance to see the bug-58222c42b3 branch merged (and this ticket closed) in the near future?

Please recall that the proposed changes should be made for TSpinbox, too.

Yes, you are right.  I was confused.  Sorry.

And we're not asking for the background behind the entry box to be configurable.

I think there is some confusion: I understand "field background color" as referring to the text field color, and not anything to do with buttons.

Brad describes how a container background color is drawn first; my understanding of the documentation is that this color should not be configurable. So the clam theme -background behavior Csaba points out I believe contradicts documentation (which is what my earlier comment was based on); although the behavior was likely undocumented for a long time, and when documentation was added not too long ago, it overlooked this behavior.

The Aqua theme cannot change the color of a button (which would seem
to be what Tk calls the "field background color").  The native buttons
are all the same color unless they are -default buttons, in which case
they use the controlAccentColor. Since the Aqua buttons have rounded
corners, the "background color" needs to match the color of the
containing widget to avoid looking bad.

The color of the containing widget is also not controllable for native
widgets.  It is nominally the windowBackgroundColor, but there are
exceptions due the fact that the native notebook panes and labelframes
have no border but are distinguished from their container by having a
slightly darker (or lighter in dark mode) contrasting gray color.

Currently the Aqua ttk widgets automatically handle matching the
"background" to the color of the container, and ignore both options.
But Tk widgets do not do this.  If you want the background to match
correctly for a Tk button, there are the systemWindowBackgroundColorN
colors, where N is a digit indicating how deeply nested the button
is within widgets which use a color that contrasts with the color
of their container. This means that it is possible to do the matching,
but it is up to the programmer to do so.  You are free to use a red
background with a Tk button, making a red rectangle that does not
match the gray window background  and which contains a button that
has the standard Aqua button color(depending on whether light or
dark mode is in effect).

Another example is the clam theme.  It has rounded corners, behind which the color specified as the value of the -background style configuration option can be seen.  If you change this color to red then each corner will contain a red pixel.

Marc Culler wrote:
> An entry widget is drawn by filling a large rectangle with the fieldbackground
> color and then drawing the text on top of that rectangle.  The text consists
> of rectangles of varying sizes, each filled with the background color and
> containing a glyph drawn in the foreground color.
> 
> I can't conceive of a context in which it would not look awful to have
> different background and fieldbackground colors. But someone must have had
> such a context in mind when the decision was made to provide all three of
> these options.  What could it have been?

That may be what was implemented for the aqua themne, but that's not how
background and field background are used in other implementations. (And why
the older mac ttk entry box made life difficult).

For non-aqua: the background is the overall background of the entire widget.
This can be seen when using graphical entry boxes with rounded corners.  The
background color shows up behind the corners of the entry box.

Drawn in order: background of the widget, the border/focus/highlight, 
the field background, the text.
Graphical entry boxes supply the border/focus/highlight and field background.

The ttk::spinbox widget has the same appearance problems as ttk::entry (light gray background rather than white).  Consequently, the proposed changes should be made for TSpinbox, too.

Comments regarding [cdbd93edca]: currently I think the only desirable thing to add back to aquaTheme.tcl is

ttk::style configure TEntry \
	    -foreground systemTextColor \
	    -background systemTextBackgroundColor

plus a comment explaining why -fieldbackground is not set by default: i.e. for the documented behavior to be preserved, the -fieldbackground should not be set by default, otherwise a program could not set a custom -background.

It turns out that setting -foreground by default is desirable: currently systemLabelColor is being used instead, which is closer to gray than the correct color systemTextColor.

I do not understand why changes are made to tkMacOSXDefault.h: the updated constants are not used by the Aqua Ttk entry widget.

I'm not sure if this answers Marc's question, but there is no instance where both -background and -fieldbackground have an effect simultaneously. Both options correspond to the color used to draw the rectangle behind the text; I'm not aware that there is even a way to specify the "text background" color used when glyphs are being drawn.

Other Ttk themes have only ever used -fieldbackground, and do not use -background. The aqua theme originally only had -background, instead of -fieldbackground as it should've had for consistency with other themes. Rather than renaming the -background option to -fieldbackground in the aqua theme, the backward-compatible behavior was added in [8dff92174e] where -background and -fieldbackground would act the same, but with -fieldbackground taking precedence (as currently documented).

Here is something I need to know.  What is an example of a context, Aqua
or not, in which it would make sense for the text background color in an
Entry widget to be different from the fieldbackground color?

An entry widget is drawn by filling a large rectangle with the fieldbackground
color and then drawing the text on top of that rectangle.  The text consists
of rectangles of varying sizes, each filled with the background color and
containing a glyph drawn in the foreground color.

I can't conceive of a context in which it would not look awful to have
different background and fieldbackground colors. But someone must have had
such a context in mind when the decision was made to provide all three of
these options.  What could it have been?

To make the resolution to this issue and [e1e881b920] more consistent, I wonder if custom field background colors should be ignored in addition to custom foreground colors.

Another user reported this issue on the MACTCL list: https://sourceforge.net/p/tcl/mailman/message/37233380/

Running ttk::style configure TEntry -background systemTextBackgroundColor should serve as a workaround.

I am still quite unfamiliar with the details of Ttk (both configuration and implementation), so I am simply unaware whether there's a more proper solution than setting -background to systemTextBackgroundColor by default in aquaTheme.tcl as previously done.

I don't think -fieldbackground can be set by default, since that causes a custom -background to be ignored, contradicting documentation:

-background color

For backwards compatibility, when using the aqua theme (for macOS), this option behaves as an alias for the -fieldbackground provided that no value is specified for -fieldbackground. Otherwise it is ignored.

@chrstrchvz: from what you say it seems like the best solution would be to
set the -fieldbackground of a Ttk Entry to systemTextBackgroundColor.  Can
you see a reason why that would not work?

Not sure what should be done to address this; I don't know whether reinstating ttk::entry configure TEntry -background systemTextBackgroundColor is the correct approach.

Also not aware whether other Ttk widgets are affected by similar issues.