To get many of these types of controls, I believe that in the Flash or web world world, this was referred to 9 slice scaling or 3 slice scaling.
If you're going to have buttons that are are Macish, and you will source your own graphics, you don't want to focus on anything that's not compatible with 3 slice scaling if the button will have a variable width. This means that you have a graphic that consists of a button's caps, or left and right ends and a middle pixel column that can be stretched as wide as needed to be the middle fill for a button. For that scroll bar thumb, you're simply doing the same thing the other way. So, pardon me on this, but I only have experience drawing buttons in iOS in code and the storyboard, using Xcode 4.x so I'm not sure what the approach on Mac OS would be but... I do know that on iOS, when you specify a graphic for a button, it will be stretched out and will look bad in the storyboard, but the button drawing code will act as if the graphic supplied is 3 slice compatible and it will render out perfectly, without you having to write any code at all. That in itself is really nice. Unless there already is a formal process I don't know about to tint the GUI laid out in an XIB in code, you'll want to focus on graphics that meet the 3 slice scaling requirements and if you're going to product them yourself, doing them as vector graphics in Illustrator or Photoshop and then exported to Photoshop and trimmed using Image: Trim, then saved out as PNGs is the way to go. These can then be applied to the button for tis various graphic states, so make sure you have consistent graphic looks for each state that you want to use. I'm sure you can find many samples on the web to play with as an experiment, but I have a few sample PNG and AI files that show the 3 slice concept if you want them. The rest of this gets a little long, but it might be nice to read if you want to visualize how you could implement this yourself and just how many graphics you might need to do it. In the past, for the simplest button case, I've used these following states in button logic, each requiring its own 3 slice graphic and a hit map graphic to indicate when to change the button graphic. The hit map is a 2 bit image taken off of the Active graphic's button's shape boundary, but you won't need one of these for Mac OS. Active state - clickable, visible and not disabled and in the mouse up/finger up state. Over state - mouse or interaction area (finger blob) is over the hit map of the button. Triggered off intersection of the mouse/finger with the hit map graphic. Down state - finger or mouse is pressed down when the over state condition is satisfied. Disabled state - not clickable, visible and disabled. Selected state - when a button has an other property such as being part of a tab bar often you'll want to show graphically that "I'm enabled and selected". Other times, you want it to show that it's selected, but don't want it to be clickable. This can present challenges and if the button's never going to be disabled, you can simply repurpose that graphic for the disabled case. "I've been clicked, show I'm selected but not clickable". Or selected and clickable can be another state for an enabled button, it's up to you. When I had to build my own UI foundation classes a long long time ago, doing things like button groups and radio buttons involved the logic for the following four standard button states: - Active - Rollover - Down - Disabled in both the toggled on and toggled off state. To allow this toggled on/off feature, the logic for "am I toggled on or not" was simply another class that could be added to the inheritance chain to enable this functionality. This added a meta state called Toggled to the four button states seen above and naturally required graphics for those states as well, resulting in up to 8 button graphics - which is not always desirable. These 8 states are perfect for checkboxes since the all those 4 states will be able to exist in the toggled and untoggled state. The thing was that sometimes in radio button groups, you can have a group that is all disabled, but with one of the buttons in the toggled on state. Also, in radio button groups, you'll never want a radio button that appears with the Toggled, active, mouse up state to respond to clicks, mouseover or mouseDown. So this almost breaks the model and creates too much graphic overhead. What was introduced to handle this was simply to allow graphic files to be also be a 1 variable class that simply pointed to the identifier for the graphic file you really wanted to use in its place. For radio buttons, the Toggled On files for Rollover and Down states can simply point to the Active graphic and the user will only see the Toggled Active graphic if they try to interact with it. You'll only end up with the need for 6 state graphic files instead of 8 and there are no logic hacks in the code required to get there except what's built in to support using a graphic or a class as the graphic state base. With the above base cases for buttons and button groups and clean foundation classes supporting them, I was able to handle every basic non text clickable control that was standard on the Mac and Windows back in the day and even well into the early days of Mac OS X. It's quite primitive compared what we have now, but with event based messaging to "entities", it worked just like sending @selectors to objects today in does in Objective C. in any case, let me know if you need some Illustrator or Photoshop files to help get you going with 3 slice button graphics. Cheers. - Alex On Aug 17, 2012, at 4:43 PM, Gary L. Wade wrote: > While I cannot say Aperture does this, when it comes to drawing a uniquely > themed UI, you might find these draw functions in AppKit to be useful: > > https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Appl > icationKit/Miscellaneous/AppKit_Functions/Reference/reference.html > > Look in particular at NSDrawThreePartImage and NSDrawNinePartImage. > -- > Gary L. Wade > http://www.garywade.com/ > > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > This email sent to z...@mac.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
