I have a window in AS Studio (sorry, I’m not comfortable with ASS as an acronym…)
that I want to be able to show at the user’s descretion as either textured or regular. I can change the button style through AS, but can’t find any way to do the same for the window. If it’s not implemented in AS, is there a call method that will accomplish this?
Thanks!
I don’t know if this is possible in AppleScript–I know how to do it programmatically in Cocoa, but I don’t know if the required parts of NSWindow can be touched with Studio–but really, you shouldn’t do this.
Yes, that’s right, I’m saying that user choice is bad in this situation.
The developer designs the interface, not the user; you simply need to provide functional settings controls for the user. Rarely, RARELY does an app’s UI keep the same cleanliness when you switch UI styles. Your app changes drastically from a “visual mechanics” perspective, meaning that the user’s eyes scan the window differently when the most significant UI element changes. This alters the flow you create with the other UI style, and that’s not good for the user.
Well, yes and no. Personally, I have had apps that allowed you to turn off the textured (brushed metal) look and as a user, liked having that option. If I had my way, the Finder would still have white windows, not those (to my eye) ugly silver things.
And while I agree that it’s part of the programmer’s job to design a usable interface, by cleverly altering the size of buttons and perhaps even the placement of objects, it is possible to translate a window from one style to the other.
While you’re certainly entitled to your opinion, I disagree with the philosophy of “I won’t answer the question because I don’t agree with its premise.” While what you deem incorrect or even nonsensical may be necessary for another developer. It depends on the situation.
I had an English teacher once who pointed out that not all great writers follow the rules of grammar. In fact, many of them break the rules with regularity. The difference, she said, was in knowing that you were breaking the rules, that you knew why you were doing it (for effect, character, or mood), and not just being ignorant and stupidly breaking the rules for no good reason.
Please do not get upset because my answer wasn’t what you wanted to hear. Trust that it indeed was an answer, just not the one you expected. Often, the correct answer doesn’t answer the question asked; people who post here often want a specific question asked, but I am typically more interested in solving the problem, the two of which are not always the same thing. I could’ve just said “here are the methods”, but how does that help you create better software? (And heck, I pointed straight to NSWindow, which is where everything you want can be found. It’s not like you can’t command-? in Xcode to find the things you need there.)
Understanding why I wrote what I wrote is the difference between making programs and designing truly great human interfaces. Everything about an interface is connected, from the colour of the background to the amount of pixels between elements. Remember that even though some apps stray, there are clear contexts within which brushed metal is appropriate; there is no reason that two users should have different overall UI experiences with a single piece of software.
If you really, really want to do it, you’ll be doing a bunch of work for zero gain (and I posit that it’s actually negative gain). You’re going to have to get rid of the current window, then create a new window programmatically with the NSTexturedBackgroundWindowMask constant in your backing arguments and assign the window’s view to a pre-constructed instance of NSView. (The metal attribute is set during window initialization.) I am not sure if you can track objects to release them properly when you use “call method” to use the Cocoa -init* methods, either. You’ll probably want to create custom Cocoa convenience methods to handle the switchover so you can make this clean, and not hacked-up in AppleScript code.
See what I mean? All that work for an app with less direction than you’re capable of designing.
Now that’s a compelling argument, and something that I doubt I would have found, even though you said, “It’s not like you can’t command-? in Xcode to find the things you need there.” (For the record, I use the AS docs a lot, but honestly don’t know enough ObjC yet to make much of the Cocoa docs. I strongly suspected {since it wasn’t documented in the AS docs} that what I was after was a call method solution, if there was one, which is why I posted originally.)
Please don’t misunderstand me either–I see your point (and said as much in “And while I agree that it’s part of the programmer’s job to design a usable interface…”), but I think there are two camps in the “the user should have control” arena and we happen to be on opposite sides of that divide.
Years ago (geez, it really was, I’m getting old…:/) we had Appearance Manager and were able to control lots of UI elements: sounds, scrollbars, desktop pic, highlight colors etc. Then there were different system fonts (Gadget, Sand, Techno, etc.) and the alternate window frames (that escaped from the Apple Lab, apparently, as they weren’t officially released but were available on the 'net if you knew where to look: I think Gizmo was one of them, if I remember correctly…).
Steve Jobs effectively killed all of that with OS X, and I understand that he wants a Mac to look like a Mac, but at the same time, it’s been seen time and again that users LIKE customizing things. I see this as no different than skinning your MP3 player app, putting a custom icon on a file or folder, or similar customization. Yes, it’s possible, even LIKELY, that some users will create ugly interfaces. But ultimately it’s their computer, not mine, and if they like it, more power to them. I was just offering the choice.
In the end, for reasons of the program I’m writing, I decided on a single theme for the main control window and a separate one for the documents, and that makes sense for what I’m doing (Which brings us back to your original point!).
They’re both compelling arguments. Believe me.
Years ago, we used to have the ability to talk directly to hardware. Users could also adjust executables’ memory allocation values. Just because we used to have something doesn’t mean it was a good thing. Additionally, Appearance Manager as shipped did not change the basic texture and visual function (brushed metal itself conveys information, whether you believe it does or not); it only let the user change some colour highlighting. It was, essentially, the difference between “Graphite” and “Aqua Blue”, because even though it had the ability to change more, there were never any officially released themes from Apple. (There were two leaked themes, but the key word here is “leaked”, which means “not released”.)
Then let them write their own programs or hack an nib file or something. Your job as a designer is to design usability to use, not usability to create something bad; it’s not about eliminating the user’s ability to use something, but rather eliminating the user’s ability to make bad decisions. This is a crucial usability concept that many, many developers miss. You’re the designer. Make the good decisions; don’t facilitate bad ones.
MP3 player skins are not good examples for your position. Support nightmare (been there, done that), 99% of skin makers can’t even spell “colour theory”, and it effectively eliminates your ability to design a solid and consistent application flow. Another goal of design is to eliminate support queries and usability/accessibility issues. Skinning creates more issues than it solves. You might find a couple of nice skins out there, but the ten UI abortions that XxHaloKilla69xX made last week and uploaded to ResExcellence will outweigh that and break the previously mentioned application flow. Even if you don’t allow UI element size and layout changes in a third-party skin, most skin makers just don’t understand that colour and texture are just as important as anything else. It’s all tied together.
Form customization (UI flow and layout) is bad overall; function customization (home page, mp3 encoding settings, etc) is good overall.
Hi all 
Except the possibility of considering a Cocoa solution (with the “call method”), you could possibly make two identical windows, a normal, and the other with the metal texture.
It is just enough to change the name of each window, and to keep exactly same the names for the objects in each window. Of course, if you have many objects in your windows, handling is likely to be very tiresome.
You can also duplicate the resource “nib” and to make the modifications in your choice in one of them, then, in the implementation code, it is enough to load the resource which you wish to display and use.
This is, for all intents and purposes, a hack. Hacks are bad software design. Additionally, it’s a hack to faciltate a weak design decision. Analogy:
Instead of training to perform better on 4 bottles of oxygen during an Everest summit attempt, you bring 8. Now you have to cope with double the O2, which means either additional sherpas (more oxygen and gear to support them), or you haul it yourself (ditto). The best solution ends up being additional acclimatization and high altitude training.
And that’s where we part company, you see. Because I don’t believe that my design decisions are right for every user. Example: I’m red/green color blind (along with 7% of the male population) and the design decision to use red and green as traffic lights (and close and zoom boxes) isn’t a wise one, and I’d change them to blue and orange if I could. For that reason, I stay away from color choices (and silver/white is a color choice, in it’s simplest form…).
I learned years ago (sorry there’s that phrase again) that a program designed for the programmer is often pleasing ONLY to the programmer. User options and user input in the design phase are crucial to creating an app that actually gets used. Otherwise, the user decides to drag their feet, not adopt, throw up roadblocks to implementation, etc., etc. The entire Apple story has been an attempt to get away from the old IBM mainframe tradition of the programming staff as a set of high priests who knew what was good for you.
We must just come from different generations. Woz’s “hacks” allowed the Apple I to be created, and his further hacks improved it into the Apple II. A “hack” is good or bad in it’s innovativeness, elegance, and their ability to solve a problem; they aren’t inherently bad in themselves.
And this is what I’m talking about: It’s simple, elegant, and gets the job done with the least amount of hassle. Thanks, Fredo!
“Hack” in this case does not mean “we’re tinkering with inventions”; here, “hack” means “bad software design”. I’m not talking out of my other side here, man. I do this for a living. [1]
Do whatever you like. I mean, I can’t twist yer arm or anything. But this is how a lot of really bad shareware gets written, you realize, with these kinds of design choices, both from a UI theory perspective and a software architecture perspective.
I’m honestly disappointed in how this thread ended. The admins can ban me for saying that, but I stand by the statement.
REALLY IMPORTANT EDIT:
[1] Since I mentioned it, the statements expressed in this post and ALL PREVIOUS POSTS, do not reflect the thoughts, feelings, or positions of my employers or fellow employees. They are my own and I own and am responsible for them entirely, no one else.
Though I’m retired, I have done this for 20 years (since the mid 80’s), so I, too, know what I’m talking about. Writing software for in-house users and paying clients is an entirely different thing than writing software for sale, where you (as the programmer) are largely insulated from the user base. When working on a deadline and facing a (seeming) impossible task, hacks are often the magic bullet that saves your life and allows you to “do what can’t be done.” I remember many times that my boss (who knew just enough about computers to be dangerous) would ask for something and I would try to explain that it couldn’t happen the way he described. But, often, it could be done, just not through standard methods. So we come from different backgrounds.
And “hack” means (from Dictionary.com):
Thanks for the vote of confidence. As I said earlier, I opted not to do this a while back, but for reasons that make sense, not because I thought one style was better than the other.
I remember having the system font set to sand using the Appearance Manager. Ah, the memories. 
Pity it was so horrid to read things with, though.
I’ve always used something like this, which does indeed use ‘call method’:
on setWindowTexture(theWindow, toMetal)
call method "_setTexturedBackground:" of theWindow with parameter toMetal
end setWindowTexture
One software example I can think of that offers a customizable window texture is Butler, and this works fine (with the exception of the ‘lovely’ option :P).
Mikey-San, your standpoint is sometimes surprising.
When we develop an application, we have the possibility of choosing how to equip the interface, between a traditional appearance Cocoa and one other with a texture.
If we wish to propose the same choice with the user, where is the problem?
It is not a question here to propose interface completely different, eccentric or incoherent, there is just a question of proposing, with the same interface, a choice of preparing on two what exists by default in the system. it is not what to be alarmed.
In addition, let us not forget that nobody is obliged to follow to the letter the rules of interface dictated by Apple, it is well to make it to ensure a good coherence with the whole of the system, but nothing prohibits with one programmer to do what he wants, he is completely free, and it is not with us to judge its choices. don’t you believe?
We can completely have a role of council near him, as you do it so well, but afterwards, it is with him to make its own choices, and even if they are contrary to those recommended by others, they are its choices after all, and we must respect them.
Lastly, do not mistake, I just tried to propose a solution with the problem arising from Kevin, but I never claimed that it was most practical, most judicious or the best. with him maintaining if the solution is appropriate to him.
_setTexturedBackground: is a private, undocumented method. It shouldn’t be relied upon for anything. You don’t know what support calls it needs, and you don’t know when it, its internals, or its support calls are going to change. The official, more reliable methodology is to use one of the initWithContentRect:* methods.
Additionally, at least at one point in the method’s history, it did not recalculate the drop shadow on the window object, which means it would stay square after altering the corners to round (metal window corners, for example). It also used to have weird Quartz glitches and toolbar problems under some circumstances. I don’t know if those are gone, but it is a clear demonstration that the method shouldn’t be used when there is a public methodology that accomplishes the task.
Because the user isn’t a designer. Have you ever done support before?
I’m not talking about the HIG; I am discussing basic cognitive design theory.
You guys have made up your minds. There is NOTHING I can say that will change it. Therefore, we’re ALL wasting our time. Good luck with whatever you guys do.
I was a Techno guy, myself. I much preferred it to Chicago (UGH) and had a roommate that insisted on using Chicago to type LETTERS. OH!:o In large type sizes! ESSSHHH!:rolleyes:
As for this (much too long) design debate, I say, as has been attributed (erroneously, see this) to Voltaire, “I disapprove of what you say, but I will defend to the death your right to say it.”
And that’s my “final answer.”
Ugh; We’re we’re quoting dictionary entries already?
In the future, I would strongly discourage statements such as the one above. I (personally) have no problem with you stating your opinion; I just don’t want opposing opinions to turn into attacks.
This works fine for me… Thank-you
A small detail however, normally one of characteristics of the windows with metal texture, it that they can be moved by any place, like is specified by Apple: “Users can move metal windows by dragging anywhere on the brushed metal surface (not just the title bar).” (Window Appearance)…
To do this, here one suggestion:
on setWindowTexture(theWindow, toMetal)
-- "theWindow" is a reference of window object
-- "toMetal" is a boolean variable
-- To change the texture of window
call method "_setTexturedBackground:" of theWindow with parameter toMetal
-- To change the dragging window property
call method "setMovableByWindowBackground:" of theWindow with parameter toMetal
end setWindowTexture
Personally, it was absolutely not my intention.
We exchanged just opinions, and that of Mikey-San is quite as sizeable as that of the other participants.
However, some is our conviction on the choices made by other programmers, we must accept that those differ as of ours, which Mikey-San seems to have a little evil to agree, this is why the dialogue can sometimes take a less cordial tone…
In any case, Mikey-San seems to have great experience as programmer, which returns these interventions very interesting. And even if sometimes I do not agree entirely with his opinions, its approach and its vision of the things are often very instructive.
Lastly, if in spite of my precautions, it could feel offended by my remarks, I present my sincere apologies to him.
Ordinarily, I’d agree with you on this one, Bruce. But “hack” and “hacker” have gotten such bad connotations, and I happen to be of the generation (as you know from a chat we had a while back about the video game craze of the 80’s) that revered the word(s) and used them as a good thing. I hate to see the original (subculture) meaning get lost (especially within the subculture it came from).
Ultimately, I think we (Mikey and I) agreed to disagree. Which is fine, I have no problem with that. I realize that there is a fine line sometimes between a “lively debate” and a “flame war” and always strive to keep within the boundaries of what is a) polite discussion, b) enlightening or though-provoking for other readers and c) relevant (at least in some sense) to the original post.
The irony thing of the whole discussion is that I opted to NOT do what I originally posted for, mostly for my own reasons. But the discussion itself helped me re-think my design decisions and decide on a direction, which, in the finaly analysis, got the job done. So the discussion served a purpose, and I hope there were no hard feelings on anyone’s part.