Re: [MACTCL] tk::unsupported::MacWindowStyle and Tk-Cocoa

[Daniel A. S. <da...@us...>]

Hi Kevin,

On Sep 20, 2010, at 7:45 PM, Kevin Walzer wrote:

> On 9/20/10 11:22 AM, Kevin Walzer wrote:
>> On a related note...
>> 
>> Looking at the MacWindowStyle command has caused me to revisit SF Bug
>> 2824538, in which windows with the "metal" flag set flicker on redraw.
>> This has proved to be a hard bug to fix because Tk-Cocoa does not at
>> present have a way to set the opacity of individual widgets.
>> 
> 
> Answering my own question here:
> 
> 1. Daniel noted in the comments thread at the SF bug tracker 
> (http://sourceforge.net/tracker/index.php?func=detail&aid=2824538&group_id=12997&atid=112997) 
> that textured (metal) windows set the Cocoa view (TKContentView) to 
> transparent as transparent.

there are two concepts of opacity at play here, one is drawing with alpha, the other is NSView hierarchy opacity (which determines things like areas where the textured window should be draggable).
the bug above is about the latter, not the redrawing flicker that you mention. Is there already a bug for that? otherwise please file one with an example script that reproduces this.

> The relevant code is in 
> tkMacOSXWindowEvent.c, around line 874:
> 
> - (BOOL)isOpaque {
>     NSWindow *w = [self window];
> 
>         return (w && (([w styleMask] & NSTexturedBackgroundWindowMask) ||
>     	    ![w isOpaque]) ? NO : YES);
> }
> 
> Patching this to return YES for opacity (i.e. textured windows are also 
> opaque like standard Tk windows) has no ill effects on standard Tk 
> displays, as far as I can tell. However, it has some beneficial effects 
> for textured windows, in that it eliminates the annoying flicker.

this does not seem right, the content view needs to be marked non-opaque for the underlying textured or non-opaque background to be drawn in the first place, otherwise the content view will appear black (before any Tk content is drawn on top, note toplevel background is Tk content)

have you tried this with toplevels/widgets/canvas etc that have systemTransparent background (and highlightbackground if applicable)?
textured/non-opaque windows were not intended to work with any other backgrounds (Tk does not known anything about alpha and will erase to the background color before drawing anything else and only draw the topmost "layer").

> 2. Applying another patch to tkMacOSXWm.c, around line 5353, to set the 
> background color of a textured window to gray ( [NSColor 
> lightGrayColor], which corresponds to Tk color gray67), allows Tk 
> widgets to blend in seamlessly with the window background. This will 
> make it possible to implement the now-standard  "unified toolbar" Cocoa 
> toolbar layout in a Tk app with Tk widgets. This is one of the few areas 
> where Tk lags behind other cross-platform toolkits even with the Cocoa 
> implementation. Qt, wxWidgets, Mozilla, even Java apps have access to 
> the unified toolbar, either by wrapping the native API or with their own 
> implementations. (The gray67 is pretty close to the gradient texture in 
> the native textured/metal windows. It's a small compromise for the big 
> win in being able to make use of it with Tk.)

there are other window types that fall into this case that don't have a grey-ish background (e.g. hud windows, which are partially transparent). Also, the background of textured windows is non-uniform, and the exact pattern/gradient used is system-defined and has changed in the past and may well change agai (we don't want to have to rev Tk everytime the OS appearance changes)...

It seem like the best solution might be to make the opacity of the content view configurable, e.g. via a ::tk::unsupported::MacWindowStyle attribute?
in any case, textured/non-opaque windows are never going to work very well with Tk until all the innards of Tk itself are taught about alpha and redrawing in z-order etc...

Cheers,

Daniel