Assmetrics
I'd like to coin a new technical term: Assmetrics. As you might imagine, an assmetric is exactly what you think it is. Programs are full of them but my favourite these days is from the slash and burn Mac cocoa port. If you don't resize a combo box to be exactly 26 pixels high, you get this message at runtime:
2007-11-20 10:17:26.452 java[4523:10b] This application is trying to draw a very large combo box, 100 points tall. Vertically resizable combo boxes are not supported, but it happens that 10.4 and previous drew something that looked kind of sort of okay. The art in 10.5 does not break up in a way that supports that drawing. To avoid breaking existing apps, NSComboBox in 10.5 will use the 10.4 art for large combo boxes, but it won't exactly match the rest of the system. This application should be revised to stop using large combo boxes. This warning will appear once per app launch.
By the time the guy who implemented NSComboBox typed all this in, he could have just centered the thing.
Steve
2007-11-20 10:17:26.452 java[4523:10b] This application is trying to draw a very large combo box, 100 points tall. Vertically resizable combo boxes are not supported, but it happens that 10.4 and previous drew something that looked kind of sort of okay. The art in 10.5 does not break up in a way that supports that drawing. To avoid breaking existing apps, NSComboBox in 10.5 will use the 10.4 art for large combo boxes, but it won't exactly match the rest of the system. This application should be revised to stop using large combo boxes. This warning will appear once per app launch.
By the time the guy who implemented NSComboBox typed all this in, he could have just centered the thing.
Steve
posted by Steve at
9:57 AM
7 Comments:
Hehe, thats awesome.
By
Benjamin Pasero, at 11:30 AM
I often use the metric of "Which takes more time? Documenting the bug or fixing the bug?" to determine whether to write a TODO marker, open a bug, add it to the wiki, or just fix the problem.
Is this a Mac implementation thing? If so, why do they seem to out of their way to discourage ease of use for developers when touting it for their products?
By
nickb, at 3:47 PM
It's a Mac cocoa thing but no more silly that other assmetrics found on Windows and the other platforms.
By
Steve, at 11:03 AM
I suppose we could have said 'not considered part of a good mac os x application'. :-)
Oversized combo boxes aren't supported because human interface doesn't want to see them in mac apps.
Also, recall that you aren't seeing the problem, you're seeing the compatibility art from 10.4. In the real 10.5 art, the indicator button to the right and the left part of the text area are the same piece of art. This means that the text area cannot be vertically stretched out - it can only fit one line of text. This is what broke some apps on 10.5. It's an accident that this did anything semi-sane in the first place. It was certainly ugly - it was the same as what you see in 10.5, and centering that indicator would not make it look better. Also, you'll see that the entire area below the indicator behaves as if it is the indicator button.
Basically, if someone gets this log, we _want_ them to change their app. They are using something that is not part of the current aqua spec.
By
Anonymous, at 12:16 AM
But Ken, just leave all the artwork the same and center or top align the darn thing within the rectangle.
Here's the issue: People ask controls to be odd sizes. Heck, sometimes they want to change the font and that almost always means a size change.
In any case, printing a great long error message at runtime can't be a good answer.
Finally, Mac's do what Mac's do. If you guys at Apple think that this is the right thing to do, then by God, you are right, by definition. I'm just having a little fun with the error message.
By
Steve, at 8:43 AM
I don't think you're understanding..
In the real 10.5 art, a combo box cannot accommodate vertical stretching to contain more than one line of text, as described above.
In what you see on the screen in 10.5 now (which uses 10.4 art as a compat workaround), note that the text area for an oversized combo box can contain multiple lines of text. No amount of alignment is going to be able to adjust for text bleeding out over combo box background art.
On Mac OS X, people do not generally ask for odd sized controls. They want to match the aqua guidelines and look like a mac app.
Further, it's in everyone's best interest that Apple be able to transparently change OS components in such a way that all apps get the new stuff without apps breaking. This is much easier to do when apps use controls in ways that are understood - we don't particularly want to try to do something reasonable and end up with people relying on edge case behaviors that we don't necessarily understand.
-Ken
By
Anonymous, at 4:17 PM
Ken,
Other platforms have combo boxes that can grow and draw differently, for example when the font changes. People sometimes want to customize the appearance of a their application by setting a font.
The combo boxes I describe are not oversize. They either align their arwork somewhere within the bounds and fill the rest of the pixels or snap the height to the correct value. They do not accomodate more than one line of text, so that might be a deal breaker for the Mac.
In any case, having a control that must be a certain hard coded pixel height that must be guessed by the programmer or discovered by fighting through the documentation makes no sense to me, especially in these days of super high resolution monitors.
You are obviously the guy who is responsible for this error message. Don't take it personally. You know more than I do about Apple and their GUI because you work their and write the code.
Let's agree to disagree, let me have my little joke and move on.
By
Steve, at 1:41 AM
Post a Comment
<< Home