Tk Source Code

On the MS-Win platform, the top menu of a toplevel does ignore eventual color and font settings.

menu .m -bg black -fg white
menu .m2 -bg black -fg white
.m add cascade -menu .m2 -label Sub
.m2 add command -label Cmd
. configure -menu .m

This has always been like that and was accepted.

Nevertheless, with dark mode on, this gets visually unplesant, see ticket [a2125a1b].

Here are two pointers how to fix this:

• https://github.com/tauri-apps/muda/issues/97
• https://stackoverflow.com/questions/77985210/how-to-set-menu-bar-color-in-win32
• https://github.com/adzm/win32-custom-menubar-aero-theme

It is complicated but doable.

Thanks for all, Harald

Great!

Merged branch win-menubar-colors-uah to main by [a07f27dd].

Bug closed.

Thanks Sergey and Csaba!

Take care, Harald

IMHO, Serhiy's solution implemented in the branch win-menubar-colors-uah is simply brilliant. And Harald's screenshot win- menubar-colors-uah.png is absolutely convincing.

I, too, am strongly in favor of adding this great improvement to the forthcoming Tk 9.1.1 release.

The example for Tk9.1.0 is attached as a picture.

Here is a message by Marc on the core list:

I see that the fix involves using Windows functions which are "undocumented". With macOS we got into trouble for using "private APIs", which I think may be the same as "undocumented". As I recall, the main sort of trouble we got into was that Apple would reject any app submitted to the App Store which used a "private API". I don't know if there is an analogous way in which Microsoft could try to punish us for using "undocumented" functions. Of course there is also the risk that an "undocumented" function can get changed or removed at any time , breaking our code without any warning. I don't know how serious these risks are. But they are probably worth thinking about.

And here is my answer:

thanks for commenting on this. I don't see any risk in punishment by Microsoft.

Those undocumented messages are sent by the Windows operating system to any application when a menu bar should be drawn. If one returns "1", then the application takes care.

The implementation is really smart. It only answers "1" if the script uses non-standard parameters. So, a menu bar without -font, -background and -foreground will use the standard Windows routines.

For me, the win is so big, that the con is totally acceptable.

Compared to the Mac, Windows is very very stable. Basically, the API is the same since Windows 95 and it still behaves like Windows NT (difference of 95/NT is the use of cooperative multitasking compared to time slice multi tasking).

Great! My test case:

wm attribute . -appearance dark
wm attribute . -appearance dark
menu .m -bg black -fg white -font {Arial 24}
menu .m2 -bg black -fg white -font {Arial 24}
.m add cascade -menu .m2 -label Sub
.m2 add command -label Cmd1
.m2 add command -label Cmd2
. configure -menu .m
pack [label .l -bg black -fg white -text Text  -font {Arial 24}]\
        -fill both -expand true 

The results of the two branches are attached by images with the branch name.

IMHO, the win-menubar-colors-uah branch should be merged yesterday. I would really love to have it.

Are there any other opinions on this?

I would love to merge it at least in 9.1.1.

Thanks for all and take care, Harald

Serhiy, thanks for the light speed solution branches.

For me personally, the font size of the menu is a critical feature. So, the undocumented version would be great for me. The tk scaling factor should be respected independently of any MS-Win system settings.

I will test and come back and attach some images.

And yes, the dark mode has to be configured. This is intentional, as menus are not themed. Nevertheless, this may also be changed. Or a standard utility function like "tk::syncmenustyle <menu>" may synchronize a menu with dark/light and the current scaling factor.

Thanks for all again, Harald

Thank you for the challenge, Harald. I already looked at this ticket, but held back, because it looked rather like a complex feature request. There are two alternative proposed fixes. In both, a menu bar with non-default colors or fonts of the menu or its entries is drawn by Tk, including the active and disabled entries and images; otherwise it is drawn by the system as before.

• Branch win-menubar-colors-ownerdraw uses only documented API: owner-drawn menu bar items and the menu background. Limitations: the system ignores the height of owner-drawn menu bar items, so a larger font or image is cut to the standard height. It changes more of the existing menu code, including WM_MENUCHAR and the accessibility text for all menus.
• Branch win-menubar-colors-uah handles the undocumented WM_UAHDRAWMENU, WM_UAHDRAWMENUITEM and WM_UAHMEASUREMENUITEM messages (as Notepad++ and the projects you linked). The menu bar becomes higher for a larger font. Limitations: the messages are undocumented and can change in future Windows versions; if they are not sent (e.g. Wine), the system draws the menu bar as before.

Common limitations: the dark mode is not followed automatically, the application has to set the colors; the custom colors override the high contrast mode; on a monitor with a different scale the fonts are not scaled, as in all Tk widgets. The right-to-left layout works. Tested on Windows 11, and under Wine.

Both variants are pretty complex, they add about 250 lines of code. I think this is a feature for 9.2, and do not recommend to backport it.

Serhiy, if you are looking for a challenge, this is be my favorite ;-) (as all other challenges like text eliding performance has been solved).

Thanks for all, Harald