Bug #125049 for Tcl-pTk: [macOS] black text/graphics for menu items

Mon Apr 09 03:10:52 2018 CAC [...] cpan.org - Ticket created

Subject:

[macOS] black text/graphics for menu items

When using the native menubar on macOS, the text and/or graphics of some menu items might always be rendered black when it should sometimes render as white, which is either: (1) when the mouse pointer is over the menu item (making the highlighted item hard to read), or (2) when the user has enabled the dark menu bar in System Preferences > General (making un-highlighted items unreadable). This issue only occurs depending on whether or not the menu was constructed using `-menuitems`. Using the Tcl::pTk widget demo, for the `menus` example, the toplevel cascades behave correctly but submenus do not. For the `menus2` example (which uses `-menuitems`), nearly the opposite is observed: toplevel cascades do not behave correctly, but submenus do. Screenshot of `menus` example: https://user-images.githubusercontent.com/7941193/37901465-e33f2f5a-30b6-11e8-8d22-dff8bfdea0f2.png Screenshot of `menus2` example: https://user-images.githubusercontent.com/7941193/37901456-dede130e-30b6-11e8-85c4-1539471fd5a0.png Screenshot of an affected program (cf. https://github.com/hotwolf/HSW12/issues/16#issuecomment-376131642) when dark menu bar is enabled: https://user-images.githubusercontent.com/7941193/37900580-40ae47d2-30b4-11e8-8e8e-4e7296c4925f.png This issue does not appear to affect e.g. Windows or Linux.

Mon Apr 09 12:10:11 2018 CAC [...] cpan.org - Correspondence added

Subject:

[macOS] color of text/graphics for menu items not changing

I need to rephrase this issue somewhat already. I've noticed this or a similar issue can still happen for standalone Menubuttons, and with the menu items' text being rendered white. For example, the bouncing ball simulator in the widget demo program (which uses the pre-Tk 8 technique of creating a menubar using packed Menubuttons*), the menuitems are rendered with text always white, so they are unreadable unless highlighted; see attached screenshot. * (I'm willing to submit a patch to either Tcl::pTk or directly to Perl/Tk that updates this demo to use the Tk 8 menubar, so that the native menubar is used on Mac aqua, and to avoid an unusual-looking menu rendered as pulldown lists.)

Subject:

tcl_ptk_white_menu_text.png

Download tcl_ptk_white_menu_text.png
image/png 100.4k

Tue Jul 10 03:37:42 2018 CAC [...] cpan.org - Correspondence added

Subject:

[macOS] color of text/graphics for menu items not changing

This issue might not be specific to Tcl::pTk after all. I have reproduced a similar issue with Gitk 2.18.0, which is a pure Tcl/Tk app. I have not yet located an upstream bug report for this.

Subject:

Screen Shot 2018-07-10 at 2.34.57 AM.png

Download Screen Shot 2018-07-10 at 2.34.57 AM.png
image/png 39.5k

Sat Jul 28 11:40:56 2018 CAC [...] cpan.org - Correspondence added

On Mon Apr 09 11:10:11 2018, CAC wrote:
Show quoted text

> I need to rephrase this issue somewhat already. I've noticed this or a
> similar issue can still happen for standalone Menubuttons, and with
> the menu items' text being rendered white.
>
> For example, the bouncing ball simulator in the widget demo program
> (which uses the pre-Tk 8 technique of creating a menubar using packed
> Menubuttons*), the menuitems are rendered with text always white, so
> they are unreadable unless highlighted; see attached screenshot.

For the bouncing ball example, the cause of the white text is simply because that's how it's coded in bounce.pl:

my $mb_list;

foreach $mb_list (@{$mb_list_ref}) {

$mb->command(

-label => $mb_list->[0],

-command => $mb_list->[1] ,

-underline => $mb_list->[2],

-background => 'DarkGreen',

-foreground => 'White',

);

}

But simply removing the -foreground and -background options doesn't guarantee the Menubutton behaves as desired; the text might still appear black (rather than white) when hovered over (see attached screenshot). Yet menbut.pl uses similar Menubutton syntax and doesn't have this issue.

Subject:

Screen Shot 2018-07-28 at 10.39.10 AM.png

Download Screen Shot 2018-07-28 at 10.39.10 AM.png
image/png 19.3k

Wed Aug 01 13:03:50 2018 CAC [...] cpan.org - Correspondence added

I've opened a ticket for Tcl/Tk regarding this issue: https://core.tcl.tk/tk/tktview/9fcef965a54fea446d1cb99324a56047a343970a

Mon Aug 13 06:40:55 2018 CAC [...] cpan.org - Correspondence added

According to cget -foreground and cget -background there isn't any color set for both the correctly and incorrectly behaving entries, unless I had set ones manually. In which cases, both -foreground and -background have the same effect (though both act like -foreground does on other windowingsystems) for correctly behaving entries, and only -foreground has an effect on the incorrectly behaving ones.

Attached is a screenshots of the -foreground being set for both a correctly and incorrectly behaving entry, and then the screenshot of -background being set for both.

Subject:

Screen Shot 2018-08-13 at 5.28.53 AM.png

Download Screen Shot 2018-08-13 at 5.28.53 AM.png
image/png 53.6k

Subject:

Screen Shot 2018-08-13 at 5.30.07 AM.png

Download Screen Shot 2018-08-13 at 5.30.07 AM.png
image/png 53.4k

Wed Nov 21 07:07:25 2018 CAC [...] cpan.org - Correspondence added

Yet another clue: in t/ptk-compat2.t, the File menu (which is created using Menubutton) works, whereas in the File-Cascade menu, the accelerators appear correctly but not the entry labels.

Fri Mar 01 07:46:12 2019 chrischavez [...] gmx.us - Correspondence added

Subject:	[rt.cpan.org #125049] [macOS] black text/graphics for menu items
Date:	Fri, 1 Mar 2019 06:39:33 -0600
To:	Bugs in Tcl-pTk via RT <bug-Tcl-pTk [...] rt.cpan.org>
From:	Christopher Chavez <chrischavez [...] gmx.us>

Tcl::pTk doesn't have something like $Tkx::TRACE, and doesn't exclusively use Tcl::call(). So after playing with Hook::LexWrap and Data::Dump to examine the firehose of input going into e.g. Tcl::invoke(), I was able to spot where it indeed looks like Tcl::pTk is setting "default" colors when not explicitly specified by programs/scripts. I also neglected to check cget() on the menus rather than just the entries, as Perl/Tk and Tcl/Tk documentation both say that's where entries will inherit colors from. cget() indicated that non-default colors were set on affected menus. The particular colors being set are #d9d9d9 for background and BLACK for foreground, which quickly pointed to Derived.pm line 354 <https://github.com/chrstphrchvz/perl-tcl-ptk/blob/57c5ec60bfc9f628cd55e73924e9b398d3ab46c3/lib/Tcl/pTk/Derived.pm#L354> as being responsible for this issue. I have not yet figured out how to resolve this. The comments for the section of code responsible admit the approach might not have been fully thought through. I wonder why default colors are being set by Tcl::pTk anyways rather than relying more on Tcl/Tk to decide proper defaults for each widget on each platform. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Fri Mar 01 07:46:16 2019 The RT System itself - Status changed from 'new' to 'open'

Sat Mar 02 01:38:19 2019 CAC [...] cpan.org - Correspondence added

On Fri Mar 01 06:46:12 2019, chrischavez@gmx.us wrote:
Show quoted text

> The particular colors
> being set are #d9d9d9 for background and BLACK for foreground, which
> quickly pointed to Derived.pm line 354
> <https://github.com/chrstphrchvz/perl-tcl-
> ptk/blob/57c5ec60bfc9f628cd55e73924e9b398d3ab46c3/lib/Tcl/pTk/Derived.pm#L354>
> as being responsible for this issue.

Also, that code comes from Perl/Tk (and seems to be as old as Perl/Tk is); I guess Perl/Tk would have this issue were it to support aqua. The POD for Tk::ConfigSpecs § CAVEATS might explain its motivation.

Tcl::Tk doesn't have this behavior because it doesn't have Derived widgets. Could the whole behavior be removed from Tcl::pTk without pulling the plug on Derived, or should menus on aqua be treated as an edge case? I don't know how often Perl/Tk programs assume/depend on -foreground and -background being propagated this way.

Tue Mar 19 20:56:35 2019 CAC [...] cpan.org - Status changed from 'open' to 'stalled'

Fri May 10 03:56:30 2019 welleozean [...] googlemail.com - Ticket #129505: Ticket created

Subject:	macOS Acqua Dark wrong colours in popup menus
Date:	Fri, 10 May 2019 09:56:05 +0200
To:	bug-Tcl-pTk [...] rt.cpan.org
From:	welle ozean <welleozean [...] googlemail.com>

Hello, on macOS Mojave set to Dark mode, popup menus have a wrong colour (dark background and dark font) which prevents popup menus to be readable. Note that this happens only if the application is run as an executable (inside an application bundle for example). Different to the case when it is run as a script, the macOS turns the main window and popups to dark. Popup created with: sub PupupEnterField{ my ($mw, $obj) = @_; my $menu = $mw->Menu(-tearoff=>0, -menuitems=>[ [command=>"MY LABEL", -command=>[sub {StartSub()}, $obj,]], ]); $obj->menu($menu); $obj->bind($RightClicBind, ['PostPopupMenu', Ev('X'), Ev('Y'), ]); return $obj; } On top of this there seems to be no method to get the theme currently used by the OS (in order to take some actions if it is dark), so this is quite a big issue. Thank you Welle

Fri May 10 04:15:42 2019 welleozean [...] googlemail.com - Ticket #129505: Correspondence added

Subject:	Re: [rt.cpan.org #129505] AutoReply: macOS Acqua Dark wrong colours in popup menus
Date:	Fri, 10 May 2019 10:14:37 +0200
To:	bug-Tcl-pTk [...] rt.cpan.org
From:	welle ozean <welleozean [...] googlemail.com>

Addendum: with "taking actions" I meant to set, for example, -foreground=>'white' for each menu item. This will make the menu readable in Dark mode. PS: the same problem applies to the menu bar, however, quite strangely, only for menu items of the second level (for items of the first level, -foreground is automatically switched to white) Am Fr., 10. Mai 2019 um 09:56 Uhr schrieb Bugs in Tcl-pTk via RT < bug-Tcl-pTk@rt.cpan.org>: Show quoted text

> > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "macOS Acqua Dark wrong colours in popup menus", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [rt.cpan.org #129505]. Your ticket is accessible > on the web at: > > https://rt.cpan.org/Ticket/Display.html?id=129505 > > Please include the string: > > [rt.cpan.org #129505] > > in the subject line of all future correspondence about this issue. To do > so, > you may reply to this message. > > Thank you, > bug-Tcl-pTk@rt.cpan.org > > ------------------------------------------------------------------------- > Hello, > > on macOS Mojave set to Dark mode, popup menus have a wrong colour (dark > background and dark font) which prevents popup menus to be readable. Note > that this happens only if the application is run as an executable (inside > an application bundle for example). Different to the case when it is run as > a script, the macOS turns the main window and popups to dark. > > Popup created with: > > sub PupupEnterField{ > my ($mw, $obj) = @_; > my $menu = $mw->Menu(-tearoff=>0, -menuitems=>[ > [command=>"MY LABEL", -command=>[sub {StartSub()}, $obj,]], > ]); > $obj->menu($menu); > $obj->bind($RightClicBind, ['PostPopupMenu', Ev('X'), Ev('Y'), ]); > return $obj; > } > > On top of this there seems to be no method to get the theme currently used > by the OS (in order to take some actions if it is dark), so this is quite a > big issue. > > Thank you > Welle >

Fri May 10 05:29:34 2019 CAC [...] cpan.org - Ticket #129505: Correspondence added

This strongly resembles the issue in #125049, however I never suspected that issue to only appear depending on whether the program is run from a script or an app. I've only ever run Tcl::pTk from a script, and am not familiar with packaging in an app bundle or why that would partially affect the appearance. I am likely confused on what exact difference is happening in each case; if you could provide screenshots, that would be handy. I'm aware it's possible for an app bundle to force enable/disable dark mode (Info.plist?), but am not aware that that is something you have done for your app. Setting light mode in System Preferences may make the issue not noticeable; but if the menu entry's text is dark when highlighted/hovered over, then the issue is technically still present.

I use dark mode, but I am not caught up on the changes recently made by Tk to support it. The macosx/README file in Tk 8.6.9 says that two new virtual events <<LightAqua>> and <<DarkAqua>> were added to allow handling changes in appearance. It is also possible to query the current appearance via AppleScript (e.g. using the osascript system command), but I would not be surprised if there is now an even easier way via Tk.

But from what I have investigated for #125049, I don't believe knowing the current light/dark mode is what should be used to resolve this issue. The cause, as I currently understand, is that some of the code Tcl::pTk had borrowed from Perl/Tk sets default colors for child widgets. But this code, which predates Tk Aqua, uses hardcoded colors, and results in some menu widgets always having entries with black text, which become illegible for the dark-background menus in recent macOS versions. Ideally, the colors should be unset by default; that way, macOS' window manager automatically picks the appropriate, legible color. Unfortunately I still have not figured out how to fix this issue, even though it was one of the first issues I identified when I began using Tcl::pTk over a year ago.

Fri May 10 05:29:35 2019 The RT System itself - Ticket #129505: Status changed from 'new' to 'open'

Fri May 10 05:29:35 2019 CAC [...] cpan.org - Ticket #129505: Taken

Fri May 10 05:30:30 2019 CAC [...] cpan.org - Ticket #129505: Reference to ticket #125049 added

Fri May 10 05:30:30 2019 CAC [...] cpan.org - Reference by ticket #125049 added

Fri May 10 05:34:10 2019 CAC [...] cpan.org - Correspondence added

To further rephrase this issue, this also affects some popup menus (e.g. from menubuttons or right-click context menus) in macOS 10.14 Mojave, since those now have dark backgrounds when dark mode is enabled.

Fri May 10 05:34:11 2019 The RT System itself - Status changed from 'stalled' to 'open'

Fri May 10 05:34:11 2019 CAC [...] cpan.org - Taken

Sun May 12 04:32:44 2019 welleozean [...] googlemail.com - Ticket #129505: Correspondence added

Subject:	Re: [rt.cpan.org #129505] macOS Acqua Dark wrong colours in popup menus
Date:	Sun, 12 May 2019 10:32:12 +0200
To:	bug-Tcl-pTk [...] rt.cpan.org
From:	welle ozean <welleozean [...] googlemail.com>

Hi Christopher, thank you, as always, for your insights. Here are the two screenshots: script [image: script.png] executable launched from the Terminal (not inside an App) [image: executable.png] Both generated with the following script: use Tcl::pTk; my $mw = MainWindow->new(); my $TextWidget = $mw->Scrolled('Text', -scrollbars=> 'ose', -height=> 3, -wrap=>'word')->pack(-side=>'top', -expand => '1',-fill => 'both', -padx=>6); PupupEnterField($mw, $TextWidget); MainLoop; sub PupupEnterField{ my ($mw, $obj) = @_; my $menu = $mw->Menu(-tearoff=>0, -menuitems=>[ [command=>"MY LABEL", -command=>[sub {StartSub()}, $obj,]], ]); $obj->menu($menu); $obj->bind('<2>', ['PostPopupMenu', Ev('X'), Ev('Y'), ]); return $obj; } I solved my problem with the following workaround: my $foregroundColorMenu='black'; #reading macOS setting eval{ our $tk_dark = $int->Eval('exec defaults read -g AppleInterfaceStyle'); }; #adapting font of menu/popups depending on Dark/Light UI if ($tk_dark eq 'Dark'){ $foregroundColorMenu='white'; } #then adding "-foreground=>$foregroundColorMenu" to all my menus presenting the color problem PS: note the use of eval, as the returned state of the function to read the Dark/Light mode can return "Dark" or die if no value can be read (which means it is Light) Not elegant, but at least my application works fine in Dark mode. Best, Welle Am Fr., 10. Mai 2019 um 11:29 Uhr schrieb Christopher Alexander Chavez via RT <bug-Tcl-pTk@rt.cpan.org>: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=129505 > > > This strongly resembles the issue in #125049, however I never suspected > that > issue to only appear depending on whether the program is run from a script > or > an app. I've only ever run Tcl::pTk from a script, and am not familiar with > packaging in an app bundle or why that would partially affect the > appearance. I > am likely confused on what exact difference is happening in each case; if > you > could provide screenshots, that would be handy. I'm aware it's possible > for an > app bundle to force enable/disable dark mode (Info.plist?), but am not > aware > that that is something you have done for your app. Setting light mode in > System > Preferences may make the issue not noticeable; but if the menu entry's > text is > dark when highlighted/hovered over, then the issue is technically still > present. > > I use dark mode, but I am not caught up on the changes recently made by Tk > to > support it. The macosx/README file in Tk 8.6.9 says that two new virtual > events > <<LightAqua>> and <<DarkAqua>> were added to allow handling changes in > appearance. It is also possible to query the current appearance via > AppleScript > (e.g. using the osascript system command), but I would not be surprised if > there is now an even easier way via Tk. > > But from what I have investigated for #125049, I don't believe knowing the > current light/dark mode is what should be used to resolve this issue. The > cause, as I currently understand, is that some of the code Tcl::pTk had > borrowed from Perl/Tk sets default colors for child widgets. But this code, > which predates Tk Aqua, uses hardcoded colors, and results in some menu > widgets > always having entries with black text, which become illegible for the > dark-background menus in recent macOS versions. Ideally, the colors should > be > unset by default; that way, macOS' window manager automatically picks the > appropriate, legible color. Unfortunately I still have not figured out how > to > fix this issue, even though it was one of the first issues I identified > when I > began using Tcl::pTk over a year ago. > >

Download script.png
image/png 27.3k

Download executable.png
image/png 27.1k

Sun May 12 04:53:05 2019 CAC [...] cpan.org - Ticket #129505: Correspondence added

On Sun May 12 03:32:44 2019, welleozean@googlemail.com wrote:
> #reading macOS setting
Show quoted text

> eval{
> our $tk_dark = $int->Eval('exec defaults read -g
> AppleInterfaceStyle');
> };

Note that defaults is a macOS system command. Here's one Perl equivalent I can think of:

our $tk_dark = (`defaults read -g AppleInterfaceStyle 2>/dev/null` =~ m/Dark/);

Sun May 12 04:58:18 2019 CAC [...] cpan.org - Ticket #129505: Correspondence added

On Sun May 12 03:53:05 2019, CAC wrote:
Show quoted text

> our $tk_dark = (`defaults read -g AppleInterfaceStyle 2>/dev/null` =~ m/Dark/);

Oops, that sets $tk_dark to 1 if Dark is returned. Sorry…

Sun May 12 05:40:52 2019 welleozean [...] googlemail.com - Ticket #129505: Correspondence added

Subject:	Re: [rt.cpan.org #129505] macOS Acqua Dark wrong colours in popup menus
Date:	Sun, 12 May 2019 11:40:32 +0200
To:	bug-Tcl-pTk [...] rt.cpan.org
From:	welle ozean <welleozean [...] googlemail.com>

Still nice! Am So., 12. Mai 2019 um 10:58 Uhr schrieb Christopher Alexander Chavez via RT <bug-Tcl-pTk@rt.cpan.org>: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=129505 > > > On Sun May 12 03:53:05 2019, CAC wrote:

> > our $tk_dark = (`defaults read -g AppleInterfaceStyle 2>/dev/null` =~

> m/Dark/); > > Oops, that sets $tk_dark to 1 if Dark is returned. Sorry… > >

Sun May 12 05:50:29 2019 CAC [...] cpan.org - Ticket #129505: Correspondence added

Thank you for the screenshots and example code, I think that clears up any confusion I had. I still can't explain why running as a script prevents dark mode from being used; when I run Tcl::pTk as a script with prerelease Tcl/Tk built with MacPorts' help, it uses dark mode. I would want to double check, is the script example running the same Tk version (via Tcl.pm) as what your app bundle contains, or is it different, e.g. a Tcl/Tk distribution? I understand that might indeed not be the case; I'm just not sure what else to check.

Now for the update I wanted to provide on the issue itself…

In the past I had tried various combinations of commenting out lines in the responsible code, or tweaking what defaults were being set, and would usually end up with fatal errors. But I may have finally found something that works:

diff --git a/lib/Tcl/pTk/Derived.pm b/lib/Tcl/pTk/Derived.pm
index dc2e006..75840fa 100644
--- a/lib/Tcl/pTk/Derived.pm
+++ b/lib/Tcl/pTk/Derived.pm

@@ -343,15 +343,14 @@ sub ConfigDefault

Tcl::pTk::catch { $cw->Tcl::pTk::Widget::cget('-background') };

my (@bg) = $@ ? ('PASSIVE') : ('SELF');

push(@bg,'CHILDREN') if $child;

- my $NORMAL_BG = $^O eq 'MSWin32' ? "SystemButtonFace" : '#d9d9d9'; # normal background for different platforms

- $specs->{'-background'} = [\@bg,'background','Background',$NORMAL_BG];

+ $specs->{'-background'} = [\@bg,'background','Background',undef];

}

unless (exists($specs->{'-foreground'}))

{

Tcl::pTk::catch { $cw->Tcl::pTk::Widget::cget('-foreground') };

my (@fg) = $@ ? ('PASSIVE') : ('SELF');

push(@fg,'CHILDREN') if $child;

- $specs->{'-foreground'} = [\@fg,'foreground','Foreground','BLACK'];

+ $specs->{'-foreground'} = [\@fg,'foreground','Foreground',undef];

}

$cw->ConfigAlias(-fg => '-foreground', -bg => '-background');

In addition to fixing the menu text color issue, it seems to avoid setting colors on any UI handled by Derived, allowing it to be consistent with any other UI using default (unset) colors, including what prerelease Tk uses for dark mode. I would appreciate others testing this to see if anything doesn't look right or gives errors. (I notice that the widgetTclpTk demo uses some text colors and graphics that assume light background colors, and are difficult to read or don't look right with dark backgrounds.)

I don't know yet if this can be considered a proper fix. For example, I don't know exactly whether existing programs should be able to depend on hardcoded default colors being set by Derived.pm; I want to see if Slaven (Perl/Tk maintainer) is familiar enough with that code to know. I think the bigger problem is that existing programs might specify colors assuming they'll appear with dark text and light backgrounds, and won't look very good if that's not the case. So I would probably suggest that, in general, if a specific color isn't needed, then it should be left unset.

Sun May 12 06:17:34 2019 welleozean [...] googlemail.com - Ticket #129505: Correspondence added

Subject:	Re: [rt.cpan.org #129505] macOS Acqua Dark wrong colours in popup menus
Date:	Sun, 12 May 2019 12:17:03 +0200
To:	bug-Tcl-pTk [...] rt.cpan.org
From:	welle ozean <welleozean [...] googlemail.com>

Would you please pass me the final version of your patch (just the snippet)? For some reason I can not reconstruct the change from the above. I will test it. Am So., 12. Mai 2019 um 11:50 Uhr schrieb Christopher Alexander Chavez via RT <bug-Tcl-pTk@rt.cpan.org>: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=129505 > > > Thank you for the screenshots and example code, I think that clears up any > confusion I had. I still can't explain why running as a script prevents > dark > mode from being used; when I run Tcl::pTk as a script with prerelease > Tcl/Tk > built with MacPorts' help, it uses dark mode. I would want to double > check, is > the script example running the same Tk version (via Tcl.pm) as what your > app > bundle contains, or is it different, e.g. a Tcl/Tk distribution? I > understand > that might indeed not be the case; I'm just not sure what else to check. > > Now for the update I wanted to provide on the issue itself… > > In the past I had tried various combinations of commenting out lines in the > responsible code, or tweaking what defaults were being set, and would > usually > end up with fatal errors. But I may have finally found something that > works: > > diff --git a/lib/Tcl/pTk/Derived.pm b/lib/Tcl/pTk/Derived.pm > index dc2e006..75840fa 100644 > --- a/lib/Tcl/pTk/Derived.pm > +++ b/lib/Tcl/pTk/Derived.pm@@ -343,15 +343,14 @@ sub ConfigDefault > Tcl::pTk::catch { $cw->Tcl::pTk::Widget::cget('-background') }; my (@bg) = > $@ ? > ('PASSIVE') : ('SELF'); push(@bg,'CHILDREN') if $child;- my $NORMAL_BG = > $^O eq > 'MSWin32' ? "SystemButtonFace" : '#d9d9d9'; # normal background for > different > platforms- $specs->{'-background'} = > [\@bg,'background','Background',$NORMAL_BG];+ > $specs->{'-background'} = [\@bg,'background','Background',undef]; } unless > (exists($specs->{'-foreground'})) { Tcl::pTk::catch { > $cw->Tcl::pTk::Widget::cget('-foreground') }; my (@fg) = $@ ? ('PASSIVE') : > ('SELF'); push(@fg,'CHILDREN') if $child;- $specs->{'-foreground'} = > [\@fg,'foreground','Foreground','BLACK'];+ $specs->{'-foreground'} = > [\@fg,'foreground','Foreground',undef]; } $cw->ConfigAlias(-fg => > '-foreground', -bg => '-background'); > In addition to fixing the menu text color issue, it seems to avoid setting > colors on any UI handled by Derived, allowing it to be consistent with any > other UI using default (unset) colors, including what prerelease Tk uses > for > dark mode. I would appreciate others testing this to see if anything > doesn't > look right or gives errors. (I notice that the widgetTclpTk demo uses some > text > colors and graphics that assume light background colors, and are difficult > to > read or don't look right with dark backgrounds.) > > I don't know yet if this can be considered a proper fix. For example, I > don't > know exactly whether existing programs should be able to depend on > hardcoded > default colors being set by Derived.pm; I want to see if Slaven (Perl/Tk > maintainer) is familiar enough with that code to know. I think the bigger > problem is that existing programs might specify colors assuming they'll > appear > with dark text and light backgrounds, and won't look very good if that's > not > the case. So I would probably suggest that, in general, if a specific color > isn't needed, then it should be left unset. > >

Sun May 12 06:22:13 2019 welleozean [...] googlemail.com - Ticket #129505: Correspondence added

Subject:	Re: [rt.cpan.org #129505] macOS Acqua Dark wrong colours in popup menus
Date:	Sun, 12 May 2019 12:21:46 +0200
To:	bug-Tcl-pTk [...] rt.cpan.org
From:	welle ozean <welleozean [...] googlemail.com>

PS: yes, executable and script use the very same Tcl.frameworks and Tk.frameworks. I set them at the beginning of my script (this is the only solution I found to make Tcl.pm link to a given installation). Am So., 12. Mai 2019 um 12:17 Uhr schrieb welle ozean < welleozean@googlemail.com>: Show quoted text

> Would you please pass me the final version of your patch (just the > snippet)? For some reason I can not reconstruct the change from the above. > I will test it. > > Am So., 12. Mai 2019 um 11:50 Uhr schrieb Christopher Alexander Chavez via > RT <bug-Tcl-pTk@rt.cpan.org>: >

>> <URL: https://rt.cpan.org/Ticket/Display.html?id=129505 > >> >> Thank you for the screenshots and example code, I think that clears up any >> confusion I had. I still can't explain why running as a script prevents >> dark >> mode from being used; when I run Tcl::pTk as a script with prerelease >> Tcl/Tk >> built with MacPorts' help, it uses dark mode. I would want to double >> check, is >> the script example running the same Tk version (via Tcl.pm) as what your >> app >> bundle contains, or is it different, e.g. a Tcl/Tk distribution? I >> understand >> that might indeed not be the case; I'm just not sure what else to check. >> >> Now for the update I wanted to provide on the issue itself… >> >> In the past I had tried various combinations of commenting out lines in >> the >> responsible code, or tweaking what defaults were being set, and would >> usually >> end up with fatal errors. But I may have finally found something that >> works: >> >> diff --git a/lib/Tcl/pTk/Derived.pm b/lib/Tcl/pTk/Derived.pm >> index dc2e006..75840fa 100644 >> --- a/lib/Tcl/pTk/Derived.pm >> +++ b/lib/Tcl/pTk/Derived.pm@@ -343,15 +343,14 @@ sub ConfigDefault >> Tcl::pTk::catch { $cw->Tcl::pTk::Widget::cget('-background') }; my (@bg) >> = $@ ? >> ('PASSIVE') : ('SELF'); push(@bg,'CHILDREN') if $child;- my $NORMAL_BG = >> $^O eq >> 'MSWin32' ? "SystemButtonFace" : '#d9d9d9'; # normal background for >> different >> platforms- $specs->{'-background'} = >> [\@bg,'background','Background',$NORMAL_BG];+ >> $specs->{'-background'} = [\@bg,'background','Background',undef]; } unless >> (exists($specs->{'-foreground'})) { Tcl::pTk::catch { >> $cw->Tcl::pTk::Widget::cget('-foreground') }; my (@fg) = $@ ? ('PASSIVE') >> : >> ('SELF'); push(@fg,'CHILDREN') if $child;- $specs->{'-foreground'} = >> [\@fg,'foreground','Foreground','BLACK'];+ $specs->{'-foreground'} = >> [\@fg,'foreground','Foreground',undef]; } $cw->ConfigAlias(-fg => >> '-foreground', -bg => '-background'); >> In addition to fixing the menu text color issue, it seems to avoid setting >> colors on any UI handled by Derived, allowing it to be consistent with any >> other UI using default (unset) colors, including what prerelease Tk uses >> for >> dark mode. I would appreciate others testing this to see if anything >> doesn't >> look right or gives errors. (I notice that the widgetTclpTk demo uses >> some text >> colors and graphics that assume light background colors, and are >> difficult to >> read or don't look right with dark backgrounds.) >> >> I don't know yet if this can be considered a proper fix. For example, I >> don't >> know exactly whether existing programs should be able to depend on >> hardcoded >> default colors being set by Derived.pm; I want to see if Slaven (Perl/Tk >> maintainer) is familiar enough with that code to know. I think the bigger >> problem is that existing programs might specify colors assuming they'll >> appear >> with dark text and light backgrounds, and won't look very good if that's >> not >> the case. So I would probably suggest that, in general, if a specific >> color >> isn't needed, then it should be left unset. >> >>

Sun May 12 06:29:32 2019 CAC [...] cpan.org - Ticket #129505: Correspondence added

On Sun May 12 05:17:34 2019, welleozean@googlemail.com wrote:
Show quoted text

> Would you please pass me the final version of your patch (just the
> snippet)? For some reason I can not reconstruct the change from the
> above.
> I will test it.

I have added a patch based off release-0.96 it as an attachment. I have also pushed it to a temporary branch "rt-125049" on GitHub: https://github.com/chrstphrchvz/perl-tcl-ptk/commit/0b8191e

Just a heads up, the change in appearance may seem quite drastic!

Subject:

rt125049.diff

diff --git lib/Tcl/pTk/Derived.pm lib/Tcl/pTk/Derived.pm index dc2e006..75840fa 100644 --- lib/Tcl/pTk/Derived.pm +++ lib/Tcl/pTk/Derived.pm @@ -332,7 +332,7 @@ sub ConfigDefault # # $specs->{'-cursor'} = ['SELF',undef,undef,undef] unless (exists $specs->{'-cursor'}); - # Now some hacks that cause colours to propogate down a composite widget + # Now some hacks that cause colours to propagate down a composite widget # tree - really needs more thought, other options adding such as active # colours too and maybe fonts @@ -343,15 +343,14 @@ sub ConfigDefault Tcl::pTk::catch { $cw->Tcl::pTk::Widget::cget('-background') }; my (@bg) = $@ ? ('PASSIVE') : ('SELF'); push(@bg,'CHILDREN') if $child; - my $NORMAL_BG = $^O eq 'MSWin32' ? "SystemButtonFace" : '#d9d9d9'; # normal background for different platforms - $specs->{'-background'} = [\@bg,'background','Background',$NORMAL_BG]; + $specs->{'-background'} = [\@bg,'background','Background',undef]; } unless (exists($specs->{'-foreground'})) { Tcl::pTk::catch { $cw->Tcl::pTk::Widget::cget('-foreground') }; my (@fg) = $@ ? ('PASSIVE') : ('SELF'); push(@fg,'CHILDREN') if $child; - $specs->{'-foreground'} = [\@fg,'foreground','Foreground','BLACK']; + $specs->{'-foreground'} = [\@fg,'foreground','Foreground',undef]; } $cw->ConfigAlias(-fg => '-foreground', -bg => '-background');

Sun May 12 09:45:34 2019 welleozean [...] googlemail.com - Ticket #129505: Correspondence added

Subject:	Re: [rt.cpan.org #129505] macOS Acqua Dark wrong colours in popup menus
Date:	Sun, 12 May 2019 15:45:14 +0200
To:	bug-Tcl-pTk [...] rt.cpan.org
From:	welle ozean <welleozean [...] googlemail.com>

Your fix seems to work fine, at least in my application everything is rendered properly. Am So., 12. Mai 2019 um 12:29 Uhr schrieb Christopher Alexander Chavez via RT <bug-Tcl-pTk@rt.cpan.org>: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=129505 > > > On Sun May 12 05:17:34 2019, welleozean@googlemail.com wrote:

> > Would you please pass me the final version of your patch (just the > > snippet)? For some reason I can not reconstruct the change from the > > above. > > I will test it.

> > I have added a patch based off release-0.96 it as an attachment. I have > also > pushed it to a temporary branch "rt-125049" on GitHub: > https://github.com/chrstphrchvz/perl-tcl-ptk/commit/0b8191e > > Just a heads up, the change in appearance may seem quite drastic! > >

Thu Jun 20 01:44:57 2019 CAC [...] cpan.org - Ticket #129505: Merged into ticket #125049

Thu Jun 20 01:44:57 2019 CAC [...] cpan.org - Merged into ticket #125049

Thu Jun 20 02:01:29 2019 CAC [...] cpan.org - Correspondence added

Welle, thank you for testing the fix I proposed. I have incorporated it into Tcl::pTk 1.00, but I still don't know if there's any issues introduced by it. I have opened a pull request to try incorporating the change back into Perl/Tk for consistency: https://github.com/eserte/perl-tk/pull/52

As I wrote on comp.lang.tcl, there is a more "official" solution for determining if dark mode is in use (as well as forcing dark or light mode to be used) using Tcl syntax, available in recent core-9-6-branch, and should appear in Tk 8.6.10; it is described in the macosx/README.

To get the current appearance of a window as a boolean value:

tk::unsupported::MacWindowStyle isdark window

To get/set the appearance as aqua/darkaqua/auto:

tk::unsupported::MacWindowStyle appearance window ?newAppearance?

I would prefer these commands over the defaults read -g AppleInterfaceStyle shell command, because it actually reflects the appearance of a running Tk application rather than merely what is set in System Preferences.

Thu Jun 20 02:01:30 2019 CAC [...] cpan.org - Status changed from 'open' to 'resolved'

Sat Mar 07 03:46:07 2020 CAC [...] cpan.org - Fixed in 1.00 added