Here’s a visual of where I am so far, after resizing the PowerPlant buttons to be 20 pixels in height: http://pbrd.co/1tvlIKI
The default PowerPlant button is now blue on Yosemite, but the text is very hard to read. Tab controls in PowerPlant have a similar appearance on Yosemite: the selected tab is blue, but the text is hard to read. (Although on Mavericks, the selected tab is a darker grey, which is fine, but the text is hard to read there as well.) Tab controls in wxWidgets or other frameworks look fine on both (even in Carbon). Is this just an issue of selecting a different font? Or is there some kind of DrawSelf function I need to override in PowerPlant? Thanks, Dan On Nov 3, 2014, at 6:50 PM, Dan Korn <dk...@pti.com> wrote: > I finally got to the bottom of this, and figured out why some of my buttons > have the square corners (and also appear greyed out on Yosemite when marked > as default/OK), while other buttons have rounded corners (and work fine on > Yosemite as well as older versions of OS X). > > It is indeed a resource issue, but it has nothing at all to do with CDEFs or > ProcIDs. Those were all blind alleys. > > tl;dr: It’s the button height that makes all the difference. Not that > there’s any documentation at all from Apple which lets you know this, or even > what the height is supposed to be. > > If a button is 22 pixels or less in height, then it has rounded corners, and, > if it’s marked as default, it has the correct appearance, where it’s blue and > pulsing on Mavericks and older, and solid blue on Yosemite (although the text > is hard to read). If the button is 23 pixels or more in height, then it has > squared corners, and if it’s marked as default, then it looks exactly the > same as a non-default button on Mavericks and older, but it appears > greyed-out on Yosemite. > > So I would say there are two bugs in OS X here: One, the button shouldn’t > radically change its appearance just because its height varies a bit. And > two: a default button that’s over 22 pixels tall shouldn’t appear greyed-out > on Yosemite. > > I’m glad I finally figured this out, but frankly, it’s extremely frustrating > to have spent so much time on this, especially since it's delayed our release > of a Yosemite-compatible version of our software. I’m also a bit frustrated > that nobody, even Eric, was able to give me any kind of hint about what > turned out to be such a simple issue. Nobody else has ever run into this? > Really? I’m also kind of upset that Apple seems to have changed the > appearance of the larger default buttons so radically in Yosemite (and only > in the public release, not in any of the dev previews). > > Actually, this doesn’t seem to be a Carbon-specific issue at all. I’ll bet > it’s the same for Cocoa buttons, although it seems that Interface Builder and > Xcode don’t let you change the height of a push button in a nib/xib file > (either a Carbon or a Cocoa one). > > I found this text in the OS X Human Interface Guidelines: > https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/ControlsAll.html#//apple_ref/doc/uid/20000957-CH46-SW1 > "In general, avoid resizing controls vertically. Many controls can be resized > horizontally, but most controls are fixed vertically for each available size. > If you vertically resize some controls, you might trigger unexpected results, > such as a change in control style.” > > No kidding! Though, given this caveat, one would also expect that the HIG > would specify exactly what the recommended height of these “fixed vertically” > buttons is. But all I could find was this: > https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/ControlsButtons.html#//apple_ref/doc/uid/20000957-CH48-SW1 > “Resize a button’s width to accommodate the title. If you don’t make a button > wide enough, the end caps clip the text. Note that the height of a push > button is fixed for each size." > > Yeah, sure it is. Maybe the height is fixed in a nib/xib file. But it sure > ain’t in Constructor, nor in a call to a Carbon function such as NewControl() > which takes a Rect for the control size, which is what PowerPlant is doing in > LAMControlImp::MakeMacControl(). It’s not like you can’t modify the height > of a button in Cocoa after creating it either. > > So what is the recommended height of a push button??? > > I seem to remember that, at some point in ancient history, the Human > Interface Guidelines had the actual recommended sizes for controls explicitly > listed. I guess I can’t blame Apple for no longer targeting the > documentation to those of us who are still fighting a war that ended years > ago, but would it be so hard just to make a note of what the recommended > button height is? Or at least give us a way to access the older version of > the HIG documentation which has the information we need? > > To reproduce this issue, all you need to do is this: Open up Constructor, > create a dialog, drag in an LPushButton control from the Catalog, hit > Command-I, check the “Is Default Button” box in the Property Inspector, and > then change the height to 23. The button will magically transform its > appearance to have square corners, and if you’re on Mavericks, it will also > lose its default appearance, but on Yosemite, it will be greyed out. > > So, I’m making a change to our code which uses PowerPlant to limit the height > of push buttons to 22 pixels. Now the default buttons don’t appear > greyed-out on Yosemite. > > However, I’m not quite out of the woods yet. The default button on Yosemite > is now blue, instead of being greyed-out, but the button text is hard to > read, since it’s still black, whereas other dialogs show white text over the > default button. Maybe that’s a third bug in Yosemite. Any ideas on that? > > Thanks, > Dan > > On Oct 31, 2014, at 4:01 PM, Dan Korn <dk...@pti.com> wrote: > >> I have some new data. It turns out that I already did have another app >> built with PowerPlant that does show the default buttons correctly on >> Yosemite. >> >> In fact, taking a closer look, in the app where the default buttons appear >> correctly on Yosemite, all the buttons have rounded corners, even on >> Mavericks and older, while in my other app where the default buttons appear >> greyed out, all the buttons have square corners, and the default buttons >> appear exactly the same as non-default buttons, again, even on Mavericks and >> older. >> >> They even show up differently in Constructor. Here’s a picture of what two >> very similar dialogs from the PPOB files for these two apps look like in >> Constructor on my Mavericks machine: >> http://pbrd.co/1ue8gyo >> >> So, I’m thinking this is a resource issue. But I can’t see what’s different >> in the two resource files that would cause all the buttons to look >> different. I think it has something to do with a CDEF, as mentioned in this >> old thread: >> http://lists.apple.com/archives/carbon-development/2001/Feb/msg00077.html >> >> But I have to admit that I have no idea how to change the CDEF or ProcID of >> a button. Perhaps I used to know but forgot. Maybe I need to dig out my >> old PowerPC Mac and use Resorcerer? I guess that would go along with my >> Halloween costume, where I’m dressed as a Mac developer from 2003. ;^p >> >> Does this ring a bell for anyone? Can someone point me in the right >> direction here? I think that there’s just some bit I need to toggle >> somewhere to make everything work. >> >> Thanks, >> Dan > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Carbon-dev mailing list (Carbon-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/carbon-dev/dan%40dankorn.com > > This email sent to d...@dankorn.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Carbon-dev mailing list (Carbon-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/carbon-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
