#2664 Need to track opaque content in textured windows


A toplevel Mac window with the "metal" style applied (via tk::unsupported::MacWindowStyle) should be not be dragabble from a widget with an opaque background, just a transparent background. However, it is draggable from any region on the window. Here is a sample script:

toplevel .f

tk::unsupported::MacWindowStyle style .f document { metal toolbarButton closeBox collapseBox resizable standardDocument}

label .f.t -text "Should be able to drag here" -bg systemTransparent
pack .f.t -side top -fill both -expand yes

label .f.b -text "Should not be able to drag here" -bg white
pack .f.b -side bottom -fill both -expand yes


  • Kevin Walzer

    Kevin Walzer - 2009-08-13
    • summary: Metal window can be dragged from opaque widget --> Cocoa metal window can be dragged from opaque widget
  • Kevin Walzer

    Kevin Walzer - 2009-08-13

    The attached patch appears to solve the problem. The metal toplevel now is draggable only in the titlebar, which is the expected behavior.

  • Daniel A. Steffen

    While this is an ok short-term workaround (that I am happy to apply for now), I don't think this is the right fix ultimately, as the correct behaviour for textured windows is that they are draggable by any area that shows the textured (metal) background, which requires setMovableByWindowBackground:YES.
    The problem is that we are not communicating properly to AppKit which areas obscure the window background and should thus not be draggable. We are currently marking the whole content view as transparent when a window is textured (c.f. TKContentView -isOpaque) and don't have a full NSView hierarchy contained in the content view that would alllow marking subareas as opaque. I don't know of a good way to fix this yet.

  • Kevin Walzer

    Kevin Walzer - 2009-08-14

    I understand your point. Unfortunately, the architectural issues you refer to are a bit out of my depth. I'm glad you agree that the patch is an improvement over the current state of affairs, in which the "metal" window flag is not really usable. This will allow a much more modern Tk UI on Leopard and later, i.e. the "unified" look.

  • Daniel A. Steffen

    • priority: 5 --> 3
    • summary: Cocoa metal window can be dragged from opaque widget --> Need to track opaque content in textured windows
    • status: open --> open-postponed
  • Daniel A. Steffen

    workaround applied to cvs HEAD and git de-carbon-8-5

    leaving open at low prio to remind me about the longer-term issue of needing to track opaque content.

  • Kevin Walzer

    Kevin Walzer - 2009-09-05

    Additional patch works around issues of opacity & systemTransparent color in Tk frames by changing the textured background to a solid color, [NSColor lightGrayColor]. This corresponds to a Tk color of "gray 67." As a result, a toplevel metal window can now have a truly "unified"-looking toolbar without a dividing line between the title bar and frames; all one has to do is set label, frame, etc. backgrounds to gray 67. I realize the lack of a true gradient in the background isn't fully compliant with the HIG, but the color value does fit in well with other Mac apps. And this works around all previous issues with the systemTransparent background that caused flashing and jerky behavior in resizing. I think this is a good compromise.

    Test script:

    tk::unsupported::MacWindowStyle style .f document { metal toolbarButton
    closeBox collapseBox resizable standardDocument}

    label .f.t -text "This is a unified frame with gray67" -bg gray67
    pack .f.t -side top -fill both -expand yes

  • Kevin Walzer

    Kevin Walzer - 2009-09-05
    • priority: 3 --> 7
    • status: open-postponed --> open-remind
  • Kevin Walzer

    Kevin Walzer - 2009-09-17

    After testing this patch more extensively in an shipping application, I now have serious reservations about it. Even switching to a solid, Tk-compatible color to allow Tk backgrounds to blend in does not sufficiently eliminate the "flash" that occurs when redraw occurs, i.e. when images are scrolled, when a message box pops up in front of the window, etc. It seems to me that the textured window is fundamentally incompatible with Tk widgets. I don't know what in Tk's internals would need to be reworked to eliminate the flicker/flash that occurs with the textured window, but I no longer have confidence in using this patch. Thus, I have no objection if the patch is rejected.

  • Kevin Walzer

    Kevin Walzer - 2010-08-31


    I've been thinking about this some more--it sounds like individually tracking the view hierarchy from within Tk's core would be a lot of work to do. I'm wondering if an extension that allows one to set the opacity of individual widgets would be a simpler solution here. For instance:

    Drawable d = Tk_WindowId(tkwin);
    NSView *view = TkMacOSXGetRootControl(d);
    [view isOpaque] = YES;

    If this code could be wrapped into a Tk command, it might then make sense to patch tkMacOSXWm.c to change the background of a metal window from a gradient to a color that corresponds to a Tk color, cf:

    /* addition for [Bug 2824538]: Change textured background to single gray to avoid incompatability with Tk colors; lightGrayColor corresponds to gray67. */
    [window setBackgroundColor: [NSColor lightGrayColor]];

    This would provide an easy hook for drawing buttons or labels into a "unified toolbar" because the background would match. Thoughts?


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks