From: Kevin W. <kw...@co...> - 2010-09-20 01:00:17
|
I've been delving into the MacWindowStyle flags on Tk-Cocoa and notice that some do not appear to function the same way as they do under Tk-Carbon. For instance, under Tk-Carbon, this command: ::tk::unsupported::MacWindowStyle style $w floating {closeBox resizable} produces a floating utility-style window with a small close-box and a window title in a small font. Very useful for toolbar windows, etc. In Tk-Cocoa, the same command produces a regular toplevel with a regular-size close-box. There is nothing to distinguish it from other toplevel windows. I'm not clear why this is the case. As I understand it, some of the window flags in tkMacOSXWm.c are implemented as NSPanels under Tk-Cocoa, which (if the "utitlity" flag and perhaps the "floating" flag) are set, function as utility-style windows, at least in Interface Builder. Why is this not supported in Tk-Cocoa? It's the one area where Tk-Cocoa, in my view, isn't as good as Tk-Carbon. Looking around at some general Cocoa and other code, it appears that I could drop to a lower level and implement some of the Carbon-style window flags with the HITheme API, but I'd rather not go that route unless it's obvious that there's no way to do this in Tk-Cocoa. If anyone has advice, or has managed to implement floating utility windows in Tk-Cocoa, I'd love to hear it. Thanks, Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Daniel A. S. <da...@us...> - 2010-09-20 07:21:49
|
On Sep 19, 2010, at 5:40 PM, Kevin Walzer wrote: > I've been delving into the MacWindowStyle flags on Tk-Cocoa and notice > that some do not appear to function the same way as they do under > Tk-Carbon. For instance, under Tk-Carbon, this command: > > ::tk::unsupported::MacWindowStyle style $w floating {closeBox resizable} > > produces a floating utility-style window with a small close-box and a > window title in a small font. Very useful for toolbar windows, etc. > > In Tk-Cocoa, the same command produces a regular toplevel with a > regular-size close-box. There is nothing to distinguish it from other > toplevel windows. [toplevel .t; ::tk::unsupported::MacWindowStyle style .t floating] works just fine for me in Tk-Cocoa and produces a floating window. maybe you are running into the fact that once a window has been created, its style can no longer be changed? Carbon had slightly fewer restrictions w.r.t changes after creation (but Carbon on later OS X versions already restricted this more than on earlier ones). > I'm not clear why this is the case. As I understand it, some of the > window flags in tkMacOSXWm.c are implemented as NSPanels under Tk-Cocoa, > which (if the "utitlity" flag and perhaps the "floating" flag) are set, > function as utility-style windows, at least in Interface Builder. Why is > this not supported in Tk-Cocoa? It's the one area where Tk-Cocoa, in my > view, isn't as good as Tk-Carbon. the differences between TkCocoa and TkCarbon in this area are purely down to what the underlying API supports, some window features that were supported by HIToolbox are not available in Appkit and conversely. > Looking around at some general Cocoa and other code, it appears that I > could drop to a lower level and implement some of the Carbon-style > window flags with the HITheme API, but I'd rather not go that route > unless it's obvious that there's no way to do this in Tk-Cocoa. I would advise against trying to go down that route, almost everything in TkCocoa relies on the fact that a toplevel is based on an NSWindow subclass. Cheers, Daniel |
From: Kevin W. <kw...@co...> - 2010-09-20 14:34:58
|
On 9/20/10 3:21 AM, Daniel A. Steffen wrote: > > > [toplevel .t; ::tk::unsupported::MacWindowStyle style .t floating] works just fine for me in Tk-Cocoa and produces a floating window. > > maybe you are running into the fact that once a window has been created, its style can no longer be changed? Carbon had slightly fewer restrictions w.r.t changes after creation (but Carbon on later OS X versions already restricted this more than on earlier ones). Ah, looks like that was the problem. I was trying to play with these window flags interactively and forgot that they can only be set once under Cocoa. I can confirm that Daniel's example works as expected. I've also discovered some other goodies, such as a real-life "hud" window (the cool black semi-transparent window). Here's a snippet of code: toplevel .t; ::tk::unsupported::MacWindowStyle style .t utility {hud closeBox resizable} pack [label .t.f -text "Hudwindow" -bg systemTransparent] -fill both -expand yes And here's what it produces: http://www.codebykevin.com/hudwindow.png Beautiful! Daniel, thanks for clarifying this. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Kevin W. <kw...@co...> - 2010-09-20 15:22:52
|
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. I've written a small Tk extension that adds a custom Cocoa subview to a Tk widget with its opacity set to TRUE, which should, in theory, mask/hide the redraw flickering. I used a similar strategy with TkDND to make a Tk widget accept drags/drops. However, while this works with TkDND, it appears to have no effect with metal windows--the custom subviews are added but they do not prevent flicker on screen redraw with metal windows. I'm not clear, therefore, if there is any way to solve the issue with screen flicker and metal windows. Any suggestions are appareciated. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Kevin W. <kw...@co...> - 2010-09-21 02:47:03
|
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. 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. 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.) Daniel, what do you think? Should I submit my patches to the SF tracker, attached to this particular bug report? Thanks, Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Damon C. <da...@tc...> - 2010-09-21 03:21:01
|
> 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. 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. > > 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.) This is something I have wanted for a long time, but it didn't seem possible with the way Tk expects things. Got a screenshot? 0-] Damon |
From: Kevin W. <kw...@co...> - 2010-09-21 13:25:07
|
On 9/20/10 10:54 PM, Damon Courtney wrote: > > This is something I have wanted for a long time, but it didn't seem possible with the way Tk expects things. Got a screenshot? 0-] Here's one, based on my efforts last year to get this working: http://www.codebykevin.com/blosxom/software/tk-cocoa-unified.png This particular app was unusable because of issues with flickering and screen redraw, but it does look much more modern than other Tk apps (at least WRT the toolbar). Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Daniel A. S. <da...@us...> - 2010-09-21 03:30:53
|
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 |
From: Kevin W. <kw...@co...> - 2010-09-21 14:37:14
|
Hi Daniel, On 9/20/10 11:30 PM, Daniel A. Steffen wrote: > > 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. You're right, I've conflated these two issues. More below on that. > > 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) That's one reason why I also propose to remove the native textured background and replace it with a Tk-compatible NSColor. > > 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"). My primary intent here is cosmetic--to be able to get the "unified toolbar" appearance in Tk without writing a wrapper for NSToolbar. Attempting the unified toolbar with the native textured background and the systemTransparent background is problematic, which I'll discuss in a moment. As part of my playing with various changes, here's what I've observed with widget behavior, based on using a simple text widget with lots of text, packed on top of a metal window: 1. Opacity of textured windows set to NO, and native textured background used: Textured background flickers through whenever widget is scrolled (if text widget has -bg white); bad flickering and blurry redraw in scrolling (if text widget has -bg systemTransparent background). 2. Opacity of textured windows set to YES, and native textured background used: No flickering background hrough whenever widget is scrolled (if text widget has -bg white); blurry redraw in scrolling and black blocks appear if widget is resized (if text widget has -bg systemTransparent background). 3. Opacity of textured windows set to NO, and textured background placed with [NSColor lightGrayColor]: Gray background flickers through whenever widget is scrolled (if text widget has -bg white); bad flickering and blurry redraw in scrolling (if text widget has -bg systemTransparent background). 4. Opacity of textured windows set to YES, and textured background placed with [NSColor lightGrayColor]: No flickering when scrolled (if text widget has -bg white); bad flickering and blurry redraw in scrolling (if text widget has -bg systemTransparent background). In brief, there are two issues here: A. Setting the opacity of textured windows to NO will cause the textured background to flicker through during redraw. B. Using systemTransparent as a widget background will also cause significant redraw issues, independent of the opacity of the window's underlyling NSView. My patches, when I get them cleaned up for submission, are designed to address issue A. Issue B appears to be a much more complicated matter, and I'm not going to address it. > > 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)... My patches do appear to remove the built-in transparency from the hud window, but that can be solved by setting the wm attributes -alpha bit. I understand you don't want to change Tk's internals just to accommodate changes in the UI appearance, but it's also obvious that Tk at present doesn't have the capability to adapt seamlessly to such changes, and that it's an extremely knotty problem to solve. My patches are a "good enough" compromise, as opposed to a perfect solution that may or may not come, given the investment of time that's required. > > 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? I've tried to do this with an extension that adds a custom NS subview to a Tk widget with its opacity set to TRUE. That seems to have no effect. I'm not sure why, as adding the subview was integral to getting TkDND to work, as well as my TclServices extension. The other issue here is that configuring the opacity of a content view won't make it easier to create a unified toolbar, which is the problem I'm trying to solve here. For the textured background to work at all, the systemTransparent background background must be used as the -bg in Tk widgets, and we've seen that this doesn't work well at present. > 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... Understood. My patches basically defer this question. I'd rather have a Tk-based unified toolbar that looks "close enough" than nothing at all. (See http://www.codebykevin.com/blosxom/software/tk-cocoa-unified.png for an example.) I could write a Tk wrapper for NSToolbar (George Petasis has done something similar with the Windows ribbon) but I really don't want to take on another big extension project. If you'd like to see these patches, let me know and I'll upload them to the SF tracker. If you don't think this is a good idea, which I understand, I'll simply apply them to my own builds of Tk and proceed (and perhaps post them somewhere for others to use if they want). Thanks, Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Daniel A. S. <da...@us...> - 2010-09-21 20:07:16
|
On Sep 21, 2010, at 7:37 AM, Kevin Walzer wrote: > On 9/20/10 11:30 PM, Daniel A. Steffen wrote: >> 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) > > That's one reason why I also propose to remove the native textured background and replace it with a Tk-compatible NSColor. That's the part I don't understand. Remove how? it's part of the window... the layering is: NSWindow -> TKContentView -> NSView (for the toplevel Tk_Frame, which is where the Tk background color lives). To set the background color behind all widgets to gray, is [$w configure -bg tkcolor] not sufficient ? >> 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"). > > My primary intent here is cosmetic--to be able to get the "unified toolbar" appearance in Tk without writing a wrapper for NSToolbar. Attempting the unified toolbar with the native textured background and the systemTransparent background is problematic, which I'll discuss in a moment. As part of my playing with various changes, here's what I've observed with widget behavior, based on using a simple text widget with lots of text, packed on top of a metal window: > > 1. Opacity of textured windows set to NO, and native textured background used: Textured background flickers through whenever widget is scrolled (if text widget has -bg white); bad flickering and blurry redraw in scrolling (if text widget has -bg systemTransparent background). > > 2. Opacity of textured windows set to YES, and native textured background used: No flickering background hrough whenever widget is scrolled (if text widget has -bg white); blurry redraw in scrolling and black blocks appear if widget is resized (if text widget has -bg systemTransparent background). > > > 3. Opacity of textured windows set to NO, and textured background placed with [NSColor lightGrayColor]: Gray background flickers through whenever widget is scrolled (if text widget has -bg white); bad flickering and blurry redraw in scrolling (if text widget has -bg systemTransparent background). > > 4. Opacity of textured windows set to YES, and textured background placed with [NSColor lightGrayColor]: No flickering when scrolled (if text widget has -bg white); bad flickering and blurry redraw in scrolling (if text widget has -bg systemTransparent background). As stated previously, the systemTransparent background does not work correctly for anything that needs partial redrawing (Tk uses filling with the background color to "erase" before redrawing on top, and filling with transparent color is obviously a NOP) > In brief, there are two issues here: > > A. Setting the opacity of textured windows to NO will cause the textured background to flicker through during redraw. > > B. Using systemTransparent as a widget background will also cause significant redraw issues, independent of the opacity of the window's underlyling NSView. systemTransparent background works fine for things like native buttons or solid unmoving widgets that are not partially redrawn (e.g. it works great for a splash screen containing a canvas with systemTransparent background) > My patches, when I get them cleaned up for submission, are designed to address issue A. Issue B appears to be a much more complicated matter, and I'm not going to address it. > >> >> 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)... > > My patches do appear to remove the built-in transparency from the hud window, but that can be solved by setting the wm attributes -alpha bit. > > I understand you don't want to change Tk's internals just to accommodate changes in the UI appearance, but it's also obvious that Tk at present doesn't have the capability to adapt seamlessly to such changes, and that it's an extremely knotty problem to solve. My patches are a "good enough" compromise, as opposed to a perfect solution that may or may not come, given the investment of time that's required. my concern is that while your changes will address the problems in your usage, they will break existing usage that works fine; hence my proposal/request to make your change configurable >> 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? > > I've tried to do this with an extension that adds a custom NS subview to a Tk widget with its opacity set to TRUE. That seems to have no effect. I'm not sure why, as adding the subview was integral to getting TkDND to work, as well as my TclServices extension. I think you misunderstood my proposal, all I suggested was a new [::tk::unsupported::MacWindowStyle] flag that would forcibly set a toplevel's TKContentView to be opaque even if it has textured background. AFAIU that is exactly equivalent to your proposed changed, except that it is opt-in > The other issue here is that configuring the opacity of a content view won't make it easier to create a unified toolbar, which is the problem I'm trying to solve here. For the textured background to work at all, the systemTransparent background background must be used as the -bg in Tk widgets, and we've seen that this doesn't work well at present. it works in a limited subset of cases, and I'm concerned with a unconditional global change that would affect those cases. >> 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... > > Understood. My patches basically defer this question. I'd rather have a Tk-based unified toolbar that looks "close enough" than nothing at all. (See http://www.codebykevin.com/blosxom/software/tk-cocoa-unified.png for an example.) I could write a Tk wrapper for NSToolbar (George Petasis has done something similar with the Windows ribbon) but I really don't want to take on another big extension project. > > If you'd like to see these patches, let me know and I'll upload them to the SF tracker. If you don't think this is a good idea, which I understand, I'll simply apply them to my own builds of Tk and proceed (and perhaps post them somewhere for others to use if they want). definitely upload your patches to the corresponding (or new) bug on the tracker. I don't have any issues with a "good-enough" change in this area, I'm just wary about breaking somebody's existing usage. Daniel |
From: Kevin W. <kw...@co...> - 2010-09-21 22:03:49
|
On 9/21/10 4:06 PM, Daniel A. Steffen wrote: > > That's the part I don't understand. Remove how? it's part of the window... > the layering is: NSWindow -> TKContentView -> NSView (for the toplevel Tk_Frame, which is where the Tk background color lives). > > To set the background color behind all widgets to gray, is [$w configure -bg tkcolor] not sufficient ? That won't set the color of the titlebar, hence the "unified toolbar" can't be achieved. Setting the color of the NSView also changes the titlebar color to the Tk-compatible shade, and allows the titlebar to blend in seamlessly with the window. This must be part of any patch I submit. > > my concern is that while your changes will address the problems in your usage, they will break existing usage that works fine; hence my proposal/request to make your change configurable I have no problem with this approach and will focus my efforts in this direction. > > > I think you misunderstood my proposal, all I suggested was a new [::tk::unsupported::MacWindowStyle] flag that would forcibly set a toplevel's TKContentView to be opaque even if it has textured background. AFAIU that is exactly equivalent to your proposed changed, except that it is opt-in I'll probably submit two patches--one to configure the opacity and one to set the background of the NSView. Both are needed for my use case. I > definitely upload your patches to the corresponding (or new) bug on the tracker. > I don't have any issues with a "good-enough" change in this area, I'm just wary about breaking somebody's existing usage. Sounds good! I'll get to work. Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Kevin W. <kw...@co...> - 2010-09-23 22:20:15
|
Hi Daniel, Trying to make some progress on my patch, I've added the appropriate bits to tkMacOSXInit.c, tkMacOSXPrivate.h, and tkMacOSXWm.c to define a new command: tk::mac::setWindowBackground that takes a window path, and RGBA values as arguments. Tk builds fine with the package, but I get a bus error when I try to actually run the command. Here's the error: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000014 0x0b0cff1e in TkWmStackorderToplevel () Here's the function that I've implemented: int TkMacOSXSetBackgroundObjCmd( TkWindow *winPtr, int red, int green, int blue, int alpha) { NSWindow *macWindow = TkMacOSXDrawableWindow(winPtr->window); if (!macWindow) { return; } NSColor *backgroundColor = [NSColor colorWithRed:&red green:&green blue:&blue alpha:&alpha]; [macWindow setOpaque:YES]; [macWindow setBackgroundColor:backgroundColor]; return TCL_OK; } This is very simple: it takes a TkWindow as a main argument, defines an NSColor based on the RGB values, gets the corresponding NSWindow from the TkWindow, and sets the opacity and background of the window. I'm not sure where TkWmStackorderToplevel () is being called--I assume that Wish is trying to get the stacking order on the windows. Based on NSLog statements (removed from this sample), Wish crashes at the NSWindow *macWindow = TkMacOSXDrawableWindow(winPtr->window) statement. Any suggestions? Do I need to allocate memory somewhere? --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com |
From: Adrian R. <adr...@gm...> - 2010-09-24 06:55:23
|
Kevin Walzer kirjoitti Sep 24, 2010 kello 1:20 AM: > ... > NSColor *backgroundColor = [NSColor colorWithRed:&red green:&green > blue:&blue alpha:&alpha]; This part looks suspicious, as there is no such method on NSColor, and I don't see it being added by any category in the Tk-Cocoa source. http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSColor_Class/Reference/Reference.html Probably you get a null back, then you are setting it on the macWindow, and it's blowing up later. -Adrian |
From: Revar D. <rev...@gm...> - 2010-09-24 18:26:26
|
The colorWithRed:green:blue:alpha: call appears to be supported by UIColor (on the iPhone) and CIColor under OS X. I can see where this confusion may have occurred. NSColor doesn't have it. - Revar On Sep 23, 2010, at 11:55 PM, Adrian Robert wrote: > > Kevin Walzer kirjoitti Sep 24, 2010 kello 1:20 AM: > >> ... >> NSColor *backgroundColor = [NSColor colorWithRed:&red green:&green >> blue:&blue alpha:&alpha]; > > This part looks suspicious, as there is no such method on NSColor, and I don't see it being added by any category in the Tk-Cocoa source. > > http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSColor_Class/Reference/Reference.html > > Probably you get a null back, then you are setting it on the macWindow, and it's blowing up later. > > > -Adrian > > > ------------------------------------------------------------------------------ > Nokia and AT&T present the 2010 Calling All Innovators-North America contest > Create new apps & games for the Nokia N8 for consumers in U.S. and Canada > $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing > Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store > http://p.sf.net/sfu/nokia-dev2dev > _______________________________________________ > Tcl-mac mailing list > tc...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-mac |
From: Kevin W. <kw...@co...> - 2010-09-24 18:31:12
|
On 9/24/10 2:26 PM, Revar Desmera wrote: > The colorWithRed:green:blue:alpha: call appears to be supported by UIColor (on the iPhone) and CIColor under OS X. I can see where this confusion may have occurred. NSColor doesn't have it. > > - Revar > I've figure out the correct call: colorWithCalibratedRed. However, it appears no have no effect because once the style flags on a window are set, they can't be changed under Tk-Cocoa. I'm going to re-work my approach into some additions to the tk::unsupported::MacWindowStyle command instead. Initial testing there is more promising. :-) -- Kevin Walzer Code by Kevin http://www.codebykevin.com |