Tk Source Code

In the current implementation of Aqua ttk, all ttk widgets use the light gray
system background color named ModelessDialogBackgroundActive.  This is the same
color that Apple uses as the background for most dialog windows, and in recent
releases of the OS there is no difference between the active and inactive
background colors.  So a Toplevel with that background color containing ttk
button, entry and optionMenu widgets looks very much like a native dialog.

But problems arise when one uses a notebook or a ttk::labeledFrame.  These are
based on the Appkit widgets TabbedPane and GroupBox respectively.  Those Appkit
widgets do not just draw frame boundaries around their contents.  Instead, the
contents are enclosed in a rectangle with rounded corners which has a darker
background and a subtly shaded border.  When these widgets are nested inside
each other, each one will have a slightly darker background than its container.

This ticket aims to fix this.  It is a known bug dating to the original Aqua
port and it makes it impossible to create complex dialogs on a mac which have
an appearance consistent with native dialogs.  The file macosx/ttkMacOSXTheme.c
acknowledges the bug with this comment:

/*----------------------------------------------------------------------
 * +++ Background and fill elements.
 *
 *	This isn't quite right: In Aqua, the correct background for
 *	a control depends on what kind of container it belongs to,
 *	and the type of the top-level window.

In fact, however, experiment indicates that the TabbedPane and GroupBox both
use the same background color, and that there is a fixed palette of increasingly
dark gray colors which are used when widgets of either type are nested inside
each other.

The bugfix branch has been merged.  I think we can close this ticket.

@bll - you are getting a bit off-topic here. I was talking about the specific issue of setting the background of a ttk::spinbox or ttk::entry without requiring a test of the windowingsystem and without messing up the fieldbackground. You are talking about all possible problems that can arise with apps which target both macOS and another platform. It still looks to me like the specific fieldbackground issue is now fixed. What am I missing?

That said, your wiki page is both interesting and out of date. A lot of that stuff has now chenged, hopefully some of it for the better. We should update your page to reflect the current state of things.

@marc: I wish.  I have quite a few work-arounds for the aqua theme and mac os x.

Some stuff is outlined here: 
   https://wiki.tcl-lang.org/page/Tk+differences+on+Mac+OS+X?V=20

I understand how wm -attributes zoomed vs wm state zoomed came about.  Though
I feel there should be a single interface to handle this sort of thing.

This sort of low-level interface issue appears in other places.

@bll - if you set both background and fieldbackground on all systems then the mac will use the fieldbackground that you set, and ignore the background. So it looks to me like you could avoid using any system-dependent code. Of course on the mac your app would not actually change its background color while on the other OS's it would. But that is a limitation of the mac port, not a requirement for checking which windowingsystem you have.

@Marc, it is because I (may) want to set the background color (when I run
multiple copies of my application, it's nice to have different background
colors so I can tell them apart).  With the aqua theme, this would change the fieldbackground.  So I have to protect the background change with the if 
statement.

@Marc,
ah ok..., I've run the progressBar from the demo and saw the correct behavior....
it's not at all what I expect... :(
on x11, the 'bar' is going from left to right and right to left, this is why I've report about behavior of ttk::progressbar.

but you are right, actual code is ok.

++

Thank you Nicolas and Brad for all of your help with this! I plan to leave this ticket open for a while until things settle down. I see that I neglected to test the build on all of the older SDKs, for example.

Nicolas, there is an indeterminate progress bar in the progress bar demo. Maybe you could copy the code from there.

Brad, the -background option is ignored if you supply a -fieldbackground option. If you use only -fieldbackground on all platforms it should work fine. if you use both options on all platforms, the -fieldbackground option will override the -backgrond option on the mac but, again, it should work fine. So I don't see why you would ever need any platform-specific code. There is no way to get different background and fieldbackground colors on the mac, but that isn't going to be changed by using platform specific code.

Hi Marc, Brad,
just to let you know... I've compiled the core.8.6 merge and there's no major issues...
many thanks Marc for your work on macOS integration.

I still do not succeed to execute an -mode indeterminate ttk::progressbar, but I can live with that and change all my calls to determinate mode (which works fine).

best regards,
nicolas

That's a decent solution.

I have no choice in my code except to continue to have:

    if { $theme ne "aqua" } {
      ttk::style configure TEntry -background $bdjbg
    }

since -background is not ignored for the aqua theme (like it does for ttk::label).

I'm actually the one who put that information into the manual page
at the same time I was documenting the styling options.

I just really dislike these cross-platform incompatibility issues.

The indeterminate progress bar does work. The animated bright spot is faint, but it is there. The animation is done by the HITools library. I am not going to write a replacement.

The manual says that in the Aqua theme the -background option sets the fieldbackground and the -fieldbackground option does not work. (This suggests that ticket 058836a5ba was not completely ignored.)

I don't see any backwards compatibility problem as long as the old behavior of -background is retained. No existing code should be using -fieldbackground since it is documented as being broken. So what I did is to make them both do the same thing, but make -fieldbackground take priority if it is set to a non-default value.

> is it possible to add -fieldbackground for ttk::spinbox in the aquaTheme.tcl?

On the mac version of Tk, -background is the -fieldbackground for
spinbox and entry.
I had opened a ticket for this a long time ago.  It was ignored.

One of the issues is that it has been the incorrect way for so long, it has
become a backwards compatibility problem.

also, indeterminate mode for ttk::progressbar does not work...

++

Hi Marc,

is it possible to add -fieldbackground for ttk::spinbox in the aquaTheme.tcl?

best regards,
Nicolas

Brad's ttkdemo.tcl script points out a serious (but not hard to fix) flaw in my attempt to correct the original issue in this ticket, namely that the background colors of ttk widgets are wrong when widgets lie inside ttk::labelframes or notebook pages (which may be nested). Commit 5442d6af34 fixes this. I will upload a screenshot of the demo taken after the commit.

The problem was that I was computing the nesting depth by counting the number of ttk::labelframes or notebook pages in the parent-child path from the toplevel to the widget. In other words, I was assuming that the geometry manager of a widget is always a parent. Using pack -in commands, as Brad does, makes this assumption invalid. What needs to be done instead is to traverse the geometry master-slave tree.

Unfortunately there was no way to find the geometry master of a window in the C API. This commit adds one. The required change was very small -- a total of 6 lines of code. The idea is to add one field, named geomMasterPtr, to the TkWindow struct. Then Tk_MaintainGeometry is modified to set this field and Tk_UnmaintainGeometry is modified to clear it. The value can be accessed with a new macro Tk_GeomMaster. It is too bad that this project is leaking into the generic code. And presumably a TIP would be required for this change. Perhaps an alternative would be to remove the macro, so there is no change to the API. But I think it is very reasonable to be able to find a window's geometry manager and I think this project illustrates why it can be useful to be able to do so.

nope... :)

++

@Marc,
Hi,
does your last commit could solve the high CPU rising?

++

What I said below about the expected behavior of the scrollbar was not correct. This comment is meant to say it correctly, and add some detail. Here are the key points:

• The underlying conceptual model is that there is a large view, of which a portion is visible. A scrollbar controls (in one dimension only) where the visible part is located. The thumb size is supposed to indicate the size of the visible part. The natural way to do this would be to make the ratio thumbSize:troughSize equal to the ratio visibleSize:viewSize. These sizes are numbers, since we are only dealing with one dimension.

• As a technical point, the mac uses floating point arithmentic for graphics but the parameters min, max, value, viewSize used by HIToolbox for drawing a scrollbar are integers. But we are free to rescale the visiblesize and the viewsize by any value since we only use the ratio. So, for accuracy, we can use a fixed large integer for the viewSize.

• The thumb can travel through a distance equal to troughSize - thumbSize. To parametrize the position of the thumb we can pick any point in the thumb and use its position to represent the position of the thumb. If we pick the first point, then the positions of the thumb range from 0 to troughSize - thumbSize. Similarly we can use the first point of the visible portion of the view to represent its position. So the possible positions of the visible portion range from 0 to viewSize - visibleSize. With these assumptions, the parameters that we should supply to HITools to get a thumb of length L at position p in the trough are:

       min = 0
       max = viewSize - visibleSize, where visibleSize = viewSize * (L / troughSize)
       value = (p / (troughSize - L) * max
       <visible>
  
  As I said, this does not predict the actual size that HIToolbox will use for
  the thumb.  But it is the best I could do.  This is the algorithm used for the
  tk::scrollbar.  It is also used when drawing a ttk::scrollbar on OSX up to
  10.8, which was when Apple removed the buttons from their scrollbar.
  </p>
  

I agree with your points.

I didn't mention the paned window as it appears it acts the same in 8.6.8.
This would also be a separate project.

The pane sash is there, but appears to be very narrow as it is difficult
to locate the position where the cursor changes.  The sash color could
certainly be improved.

@bll: Many, many, many thanks for the script! Thanks also for taking the time to test this code.

Here is what I think I can do:

• I will try to deal with the borders on the entry and spinbox widgets.

• I will try to write a custom Dark Mode drawing procedure for the listbox headers. (I was hoping to sneak that one through without anyone noticing.)

The other two points that you mention, while certainly valid, are beyond the scope of this project, in my opinion.

• The HITools library ignores the accent color preference setting. It always uses blue. Since almost all of the Aqua widgets are being drawn by HITools, honoring the accent color preferences basically requires writing custom drawing procedures for essentially all widgets.

• Apple stopped using size grips many years ago. So there is no "native" size grip to use as a model for the ttk size grip. The best one could do would be to invent a custom ttk size grip for the Mac. That seems like a good project. It is an opportunity to be creative. But, as I said, it seems to be beyond the scope of this project.

Thanks for the explanation about the scrollbar.

The branch bae2464975 works better for the demo script.
Lots of weirdness is gone.

- dark mode: The border color around the spinbox/entry appears to be wrong.
  compare against : system preferences / notifications
  The border color for the disabled entry/spinbox definitely needs to be 
  changed.
- it appears that mojave uses the accent color for everything rather than
  the blue (currentControlTint?).
- size grip coloring.
  Don't know where to find one of these on the mac if it even exists.
  I find these are very difficult to see in all the themes.  If it has to
  be generated, some contrast and visibility would be nice.
- treeview headings may be the wrong color in dark mode.

Some explanation about the scrollbar: outside of the bug-0d63621b6c branch there is no such thing as a ttk::scrollbar for Aqua. In core-8-6-branch the script library/ttk/scrollbar.tcl tests for the windowingsystem and in the case of "aqua" it replaces the ttk::scrollbar constructor with the tk::scrollbar constructor unless you specify -class or -style options. If you include those options you get the default non-native scrollbar.

The problem with the tk::scrollbar is simple to explain, but very frustrating to deal with. The scrollbar is drawn with the HIToolbox. When you do that you cannot directly control the size of the thumb. You end up in a situation where the widget thinks the thumb is a different size than what appears on the screen. The result is that when a user clicks on a location that looks like it is in the thumb, the click will be interpreted as being in the trough and that causes the widget to jump by a page instead of activating the thumb for scrolling.

When you ask HIToolbox to draw a scrollbar you give it 4 parameters: min, max, value and viewSize. You would expect that the ratio value : (max - min) would be equal to the ratio (thumb length) : (track length). But that is not at all the case. I spent a day trying to reverse engineer the algorithm that HIToolbox uses to determine the thumb size from those 4 parameters. I failed. In fact it did not seem to depend only on those parameters, but also on some other components of the environment. So really it is impossible to synchronize the widget's notion of the thumb size with the actual size on the screen.

For the new ttk::scrollbar I completely rewrote everything. I added graphics routines that draw the thumb directly, at the exact size and location which the ttk scrollbar widget requests. Consequently, when you think you are clicking on the thumb, the widget thinks so too and behaves rationally. Also, since the ttk widget tracks when the mouse enters the track, it is possible to make the scrollbar become active whenever that happens. With the HITools version, it would usually only activate when the mouse is over the thumb.

@bll - Thank you for testing!

Your screenshots look very serious, but I suspect that they were caused by the serious bug that I just found and fixed in the latest commit. There was an unmatched CGContextSaveGState that sneaked into the code a day or two ago.

Can you please try with commit bae2464975?

Also, can you please attach your demottk.tcl script? That looks very useful for testing and if it really is generating the kind of garbage that your screenshot is showing then I really need to know the details. Thanks.

Is there a branch that has all the dark mode fixes combined?

Using the bug-0d63621b6c branch, there are many problems (I will attach
a pic).

The ttk::scrollbar seems to be ok.  Apparently more fixes have been
applied since the prior scrollbar tickets that supposedly fixed the
scrollbar.

super !!
I'm using ttk::scrollbar in darkMode and it's very well integrated with the theme...
thank you.

++

@nab The last commit needed more work.  You may have better luck now.

There are no style options available for the ttk::scrollbar.

@bll it does not prevent anything, at least not intentionally.  The tk scrollbar
is still available and the other themes besides aqua still have their own
ttk::scrollbar.  You really should try the new ttk::scrollbar in the aqua theme,
though. Just build the latest commit in the bugfix branch and run the demo.
I think you will find that it works exactly like the unix ones.  (Except it
changes color in Dark Mode unless you disable that.)

Is the new mac ttk::scrollbar code going to prevent the use
of the unix ttk::scrollbar code?

I do not use the mac aqua scrollbar as I find it completely unusable.
The unix ttk::scrollbar code works very well.

Hi Marc,
about the new ttk::scrollbar, here's a pict:
https://paste.pics/8ca11f41da69f62e2e5caa937e3017f6

can you point me the ttk::style option I can use?

best regards,
nicolas

it's the way my app is working on windows and on macOS using clam theme and XQuartz.
at the first stage ttk::frame are gray33 (for example), and later when user select a bg color, I update all of them using ttk::style map command.

now I can live with that and change my code to handle frame.

also, ::tk::unsupported::MacWindowStyle appearance yourwindow darkaqua is very cool and BevelButton is also very cool.

++

The behavior is the same on core-8-6-branch as in the bugfix branch: you cannot override the background color of a TFrame. And that is the correct behavior. If a TFrame were given a different background color then every ttk widget in the frame would be inside of a rectangle which has a different color from the frame. This would break the Aqua theme (not to mention violating the Apple Human Interface Guidelines). If you need frames with non-standard background colors then you should probably use a different theme.

Also, as far as I can see this behavior has been in place for a very long time. Perhaps you were remembering something that happens with XQuartz?

yes,
black.TFrame lead to a black frame

++

After looking at the code, it seems that on the Macintosh the ttk::frame
widget always ignored the -background option.  The current version always
sets the background to either kThemeBrushModelessDialogBackgroundInactive
or kThemeBrushModelessDialogBackgroundActive.  The bugfix branch is using
the semantic NSColor called windowBackgroundColor.

Are you sure you used to get a black window on a mac?

Of course, if you use a normal frame, not a ttk::frame, you can get any
background color you like.

That appears to be a bug.  I have no idea what is causing it at this point.

also, there's something I don't understand about ttk::frame

I used to do something like that:
    ttk::style configure black.TFrame -background black -highlightbackground black -padding {0 0} -relief flat -bd 1;\
    ttk::style map black.TFrame -background [list {active !disabled}  black];\

but this doesn't work anymore...
is it because at the very first stage the ttk::frame is packed inside a frame? (and not a ttk::frame)

best regards,
Nicolas

thank you Marc, I guess you latest checkin will fix the bottom border wider than the upper one

+=

ttk::button .b -image myicon -style Toolbutton -padding {-2 -2 -2 -2}

Hi Marc,
thank you for pointing me the BevelButton, it's not that bad to handle my images.
do you now how to tweak the Toolbutton style to reduce space between borders of images and borders of the button?
-text in buttons are now centered, thanks.

best regards,
nicolas

Nicolas,

One more comment. I think that the problem you are having with your ttk image buttons is that on the mac all PushButtons have the same height, which is big enough for one line of text. Tk will let you put an image into a ttk::button but what happens with a large image is that the image just overlays the button. The mac has a different kind of button, a BevelButton, which can be arbitrarily high. That might be what you should be using. One way to do that is to add the option -style Toolbutton when you create your ttk::button. That should give you a rectangular button with rounded corners which changes the background and text color when you go into dark mode. That may not be what you want, though, since your gun image is black. Another choice is to use a standard Tk button. If the height is too big to be contained in a normal PushButton then the button will be drawn as a BevelButton with square corners. You will not be able to change the face color, though, and you will need to set the highlightbackground. A third option is to use a label with bindings to mouse events.

The text layout bug was fixed in the bugfix branch. Ttk buttons now center their text.

Nicolas,

Thanks for testing!

The comment posted below is relevant to your situation. It appears that you want your window to always be displayed in "Dark Mode". You can ensure that by calling:

::tk::unsupported::MacWindowStyle appearance yourwindow darkaqua

Some other comments about your window:

- Ttk widgets are designed to be displayed inside of a ttk::frame which has a fixed non-configurable background color that matches the fill color of the button's bounding rectangle. You are using a normal tk frame and setting the background to black. The ttk buttons will not match if you do that.

- You can use normal widgets inside of a ttk::frame if you set the fill color to systemTtkBackground. In this case of a button, that means setting the -highlightbackground option to systemTtkBackground

- On the mac you cannot change the color of a button face, even for a normal Tk button. This is documented behavior. The -background option is accepted but ignored. For Ttk buttons the -background option is not available for any theme, including aqua. There is no such thing as a blue native button on a mac. But you could probably fake it by using a normal label with a blue background and adding your own bindings.

- You are right that the text is not being centered in the ttk::button. That is a bug, since the aquaTheme.tcl file specifies -anchor center. I will look into that. Thanks for noticing!

I forgot to include one new feature in my list:

• A new command tk::unsupported::MacWindowStyle appearance window ?name? can be used to control which appearance is used to display a given window. Allowed values for the name are "aqua", "darkaqua", and "auto". If set to "aqua" or "darkaqua" the window will always be displayed with that appearance, regardless of the user's preferences settings. If set to "auto" the appearance will be controlled by the preferences.

Hi Marc,
I've tested your bug fix branch:
here you'll find 3 screenshot, first is with clam theme (which i use generally), 
https://paste.pics/f9fe22830e94b9acc7d1c999b02668eb

others are with ttk::setTheme aqua (light mode and dark mode)
https://paste.pics/1f1c70f20f5cad854cf964858d9b6525
https://paste.pics/d772b662193521d7a12a89cb051e09d1

first I should say that everything was made for clam theme and no doubt I have to work to adapt to aquaTheme....

-close to the RPN button (top left) it's a ttk::label which sould be lightblue (see clamTheme). I can live with that but I would like to know if it's expected
-image in ttk::button are not great (see the gun for example)
-text in ttk::button are not centered

hope this helps...
++
Nicolas

Here is a list of the changes in the current bugfix branch. Kevin has reviewed and approved these. He had some suggestions which have now been implemented along with several other small improvements. I would really appreciate any comments from others.

• Ttk LabelFrames and Notebook panes now have contrasting backgrounds, even when nested and even in dark mode. Eight levels of background color were added to the system color list: TtkBackground, TtkBackground1, ...

• Three of Apple's "semantic" NSColors have been added to Tk's system color palette: systemLabelColor, systemControlTextColor, and systemDisabledControlTextColor.

• All Ttk widgets are usable in Dark Mode, and most are close replicas of the native widgets when drawn in Dark Mode.

• Many anomalies and inconsistencies in the Aqua Ttk layouts have been fixed.

The widgets which do not completely match, but are usable, include Ttk Entry, Combobox and Scrollbar. These still have white backgrounds, but font colors have been chosen to make them usable. At present there is no implementation for a Ttk scrollbar in Aqua, and one would need to be written before a dark scrollbar could be added. These issues could be corrected separately and later.

As many people who lurk around these pages know, the Apple port of Tk was rendered completely useless, unable to draw anything at all into its windows, by the changes introduced in OSX 10.14 (Mojave) in order to support the new "Dark Mode".

While we have now gotten past that, there are still lots of issues related to Dark Mode. One of the more bizarre aspects of this is the mysterious story of kThemeBrushDocumentWindowBackground. That is the name of a color used by the HIToolbox library. The HIToolbox is really part of the ancient Carbon technology, which was abandoned by Apple early in the development of OSX, long before it became macOS. However, the HIToolbox is used very heavily by Tk because it allows drawing widgets that look like native widgets without having to actually instantiate a native widget, which would be useless to Tk. By some miracle, Apple continues to ship the library with new releases of the operating system and to update the appearance of the widgets that it draws so they continue to look correct on the new OS.

Unfortunately, however, Apple apparently decided not to update the HIToolbox to allow drawing widgets that would change their appearance when drawn in Dark Mode. When the wxwidgets project contacted Apple they were told:

"Unfortunately the HITheme API has not been, and will not be, updated to be cognizant of dark mode. Instead, we recommend using NSColor, which obeys the current appearance."

That brings me to the mystery of kThemeBrushDocumentWindowBackground. In spite of Apple's claim, it turns out that kThemeBrushDocumentWindowBackground is "cognizant of Dark Mode". When Dark Mode is enabled, that color becomes black instead of light gray. The consequences for Ttk were significant, because that color was being used as the default background color for Ttk Frames and Labels. What this meant was that switching to Dark Mode made Ttk windows unreadable. Labels drawn with a black font on a black background look black.

Since I already had been editing tkMacOSXColors.c to add the background colors needed for Ttk LabelFrames, I decided that I should add some of Apple's recommended NSColors to Tk's system color palette. I added LabelColor, ControlTextColor, and DisabledControlTextColor. Changing the default foreground color to systemLabelColor in aquaTheme.tcl then had a magical effect. Suddenly Ttk Labels were readable in Dark Mode. When the background color turned to black the foreground color would turn to white.

So maybe Ttk could be made to work in Dark Mode after all! Alas, this small change did not fix the many Ttk widgets which were being drawn with the HIToolbox. So that launched another painful project of figuring out how to draw dark versions of those widgets. Carrying out that project necessitated looking at the current widgets very closely, which revealed many small inconsistencies in the geometry and behavior of the existing Ttk widgets. The inconsistencies were being generated by many opaque layers of byzantine code that had been built up over the ages. Fixing them required simplifying the code to the point where it could be understood.

I am posting this ticket to announce that I have now finished that project (I think). The result is in the bugfix branch. I will post another ticket itemizing the changes.

I have started a bugfix branch 0d63621b6c for this ticket.

The commit a90a32fdf4 contains a fix. It also adds 8 new system colors which correspond to the background colors for a ttk window and for seven layers of nested notebook or ttk::labelFrame widgets.

I will attach screenshots showing the new appearance.