setting "has texture" attribute of a window from an applescript

Is there a way to set the “has texture” attribute of a window programmatically?

NSWindow Class Reference

bummer :frowning:

More completely, you can set the textured attribute programmatically, but it’s done during window initialization, and once the window is initialized, that setting cannot be changed.

NSWindow *aWindow = [[NSWindow alloc] initWithContentRect:aRect styleMask:NSTexturedBackgroundWindowMask backing:NSBackingStoreBuffered defer:YES];

Okay so I could put a check box for that in preferences saying changes will take effect after next restart?

Also where would I put that could to catch it before it’s initialized? On awake from nib? on launched?

not forget to mention - it’s not absolutely impossible - it was possible by calling a private method:

call method “_setTexturedBackground:” of myWindow with parameter yes – to set textured and no for the opposite direction

Note: depending on what you want to do, using private methods is probably not a good idea since they might not be supported any longer in future OS X releases (btw: the metallic look is told to be dead with 10.5) …

Not suprising. It never was very popular. That’s why I want it to be optional in my app. I liked it.

I tried putting call method “_setTexturedBackground:” of theObject with parameter yes

in the awake from nib handler like…

[code]property HasTexture : true

on awake from nib theObject
if name of theObject is MyWindowsApplescriptName then
if HasTexture then
call method “_setTexturedBackground:” of theObject with parameter yes
call method “_setTexturedBackground:” of theObject with parameter no
end if
end if
end awake from nib[/code]
and with that in there the app quits on launch.

What did I do wrong?

Hi PolarBear,

no idea what’s wrong with your above script - I tried it and it worked for me. But I recommend using a window subclass instead - it handles both: trying to set the background instantly by using the private method and setting/reading a default entry that is used for the stylemask when the window is initialized. It might look like this:

[code]#import <Cocoa/Cocoa.h>

@interface SwitchTexturedWindow : NSWindow{

@implementation SwitchTexturedWindow

  • (id)initWithContentRect:(NSRect)contentRect styleMask:(unsigned int)styleMask backing:(NSBackingStoreType)bufferingType defer:(BOOL)deferCreation{
    BOOL windowtextured = [[NSUserDefaults standardUserDefaults] boolForKey:@“windowTextured”];
    if (windowtextured) {
    styleMask = styleMask | NSTexturedBackgroundWindowMask;
    } else if ( styleMask & NSTexturedBackgroundWindowMask) {
    styleMask -= NSTexturedBackgroundWindowMask;
    return ([super initWithContentRect:contentRect styleMask:styleMask backing:bufferingType defer:deferCreation]);

[[NSUserDefaults standardUserDefaults] setBool:hasTexture forKey:@“windowTextured”];
if ([self respondsToSelector:@selector(_setTexturedBackground:)]) {
[self _setTexturedBackground:hasTexture];
return YES;
} else {
return NO;


and your call from applescript:

set success to (call method "tryToSetTexturedBackground:" of (window of theObject) with parameter yes)

success should return if the ‘_setTexturedBackground:’ method exists so you can decide for further steps in your script …

Note: the line where the private method is called generates a compiler warning - ignore it :wink:


You should not be using private methods in your code. They’re undocumented, and as such their behaviour is not guaranteed.

  • They may contain bugs or implementation details that you don’t know about that can’t be worked around.
  • They may contain bugs or implementation details you don’t know about with workarounds or necessary considerations you don’t know about.
  • They may be changed at any time without changes being documented.
  • They may be removed at any time without their removal being documented.

Using private methods is bad development practice.


we already had this problem - you write without reading thorroughly … sigh :frowning:

But PolarBear seems to want to try it anyway so I wrote the subclass example for him. The class does exactly what you suggested and additionaly tries to switch the background instantly by using the private stuff. Feel free to write an improved version/other solution instead of always telling other members ‘yours is bad’


I’m thinking of trying it with an environment check so that if the app finds it’s self running in 10.5 it will disable this feature of the app defaulting to the non textured windows.

I’ll post again after I’ve tried it and see how it works out.

You have this problem where you assume I don’t read, and then write rants directed toward me as though I have no idea what I’m talking about. I’m not contradicting anything, now am I? I’m giving my advice as someone who’s done a lot of this. There is absolutely, positively, unequivocally zero reason why I should not say what I said, and I challenge you to show me why I shouldn’t have made that post.

If you don’t like that, please stop responding to things I say.

  1. He shouldn’t be doing it, for exactly the reasons I stated.

  2. Stop encouraging newbies to use private methods. Teaching bad things leads to bad habits and bad software.

Stop encouraging people to use private methods.

I don’t think there’s a good reason to allow the user to switch the textured look at all. Aqua and Textured require separate design philosophies, and as such they aren’t designed to be switched back and forth by users.

The fact that you’re considering disabling a feature because someone has a newer version of the OS signals to me that the feature itself is flawed in some way. Metal and Aqua windows have different design philosophies–reconsider allowing the user to change it at will, since he/she cannot alter the rest of the application’s design.

that’s the difference between you, Mickey and me. I showed a solution and gave my recomendation and explanation why it is probably not a really good solution and let the reader decide. (Don’t think this can be called ‘encouraging someone using it’).
You? You posted a single line of code without further help and let the (as you said) ‘newbie’ alone. Nice. That’s what makes me feel a little bit angry about your posts and it made me a little bit touchy for your statement as direct response to what I wrote.



Well 10.5 is here and they haven’t killed the metallic look yet.

Maybe I’ll just release the app in two flavors so that if it is killed the non-textured flavor of the app still runs fine and only the textured flavor is at risk.