[The Evener]

Sorry if this common knowledge, but once in a while I get thrown performing the simple task of minimizing a window. The problem seems to be that Cocoa and Carbon apps behave differently.

Try this for starters: Run OmniWeb and IE 5.1 side by side (or the Finder and TextEdit, as an alternative). First, the Cocoa app -- move your mouse cursor slowly towards the minimize button until the symbols appear within the buttons. It should display the symbol when the cursor is still several pixels away from actually crossing the edge of the button. Click your mouse button once.

Now try the exact same thing with the Carbon app. For whatever reason, the Carbon app won't respond. In fact, the function won't work until you're several pixels within the button itself. Granted, this difference isn't the end of the world, but I can tell you that I've become "conditioned" to the Cocoa app response to the point where I'm clicking several times to minimize in Carbon apps until I remember that I have to get right over the button (I know you can double-click the title bar, but leave that aside for the moment). When I'm working really fast, this is a minor pain since you get used to working one way, but then you have to work differently with another set of apps.

Of course, I could "train" myself to always click in the center of the button for all apps, but is there any reason why the "Cocoa way" can't be implemented in Carbon apps?

[This message has been edited by The Evener (edited 04-15-2001).]

[Lord Kronos]

I see what you mean, and I find it disturbing, especially in the Finder. Closing windows for instance is painful, I have to click twice to do so sometimes.

------------------
"Ein kleiner Mensch stirbt - nur zum Schein"

[barbarian]

This difference is because Carbon and Cocoa use different APIs. Interface widgets are made up of picture parts called pxm#'s. These pictures have an alpha and a mask. Carbon seems to ignore both the alpha and the mask when it comes to determining a mouse hit and just looks at the edges of the particular part. So if a particular widget is 16x16 but the frame is 20x20, you can click anywhere within that 20x20 frame. Carbon only looks at what is masked. So if the widget has a 16x16 mask, that is the hit area. If you change the mask and make it 20x20, that will be the hit area.

This is the simplified explanation, because in reality there are some special cases where a more complicated interaction takes place. Also in some cases, carbon and cocoa use different sets of widgets that are slightly different sizes (this is so that legacy apps will look normal).

If this discrepancy bothers you, it could be easily changed so that both carbon and cocoa match most of the time by filling in the masks of particular widget parts. You will be able to do this once a resource editor is available to handle pxm#s.

Originally posted by barbarian:
This difference is because Carbon and Cocoa use different APIs. Interface widgets are made up of picture parts called pxm#'s. These pictures have an alpha and a mask. Carbon seems to ignore both the alpha and the mask when it comes to determining a mouse hit and just looks at the edges of the particular part. So if a particular widget is 16x16 but the frame is 20x20, you can click anywhere within that 20x20 frame. Carbon only looks at what is masked. So if the widget has a 16x16 mask, that is the hit area. If you change the mask and make it 20x20, that will be the hit area.

This was interesting enough to reboot to OS X and check out.

The Cocoa behavior is (IMO) a bug because you can do a potentially dangerous action (such as closing a window) without actually clicking on the widget.

The Carbon behavior is also (IMO) a bug because it uses only the non-alpha mask as it's active region (and since Aqua uses the alpha mask to give everything soft edges, that means your active region is actually *inside* the target).

In short, Apple needs to make the target region for an object the alpha mask rather than the 1-bit mask or bounds rect of the part.

There is also the fact that the Cocoa API was designed to be higher performance on OS X. The Carbon API was originally supposed to be a Quick Hack, so developers could quickly port old code. Carbon would have been slowly phased out. The Carbon API was never even formalized or finished.

[SillyMonk]

Thanks for clearing that up! I was wondering why I had to click twice for some apps...it was driving me nuts! Now if I can just figure out why my Apple Pro keyboard shift key doesn't always work fthe first time....

[The Evener]

Thanks for everyone's contributions -- it certainly clears things up a lot for me.

However, to pick up on Jethro's point, I prefer the "bug" of the Cocoa only because it is more response -- perhaps too responsive, given your good point about accidently closing a window. I have noticed, however, that due to the spacing of the widgets you're unlikely to close a window if you're attempting to minimize despite the larger frame. At the same time, I prefer the Cocoa behavior because the moment the widgets display their X - + functions, my expectation is that the action I am seeking is "active" -- and Cocoa apps behave accordingly, but not Carbon ones.

As a footnote, I'm using Railhead's Aqua III theme, and the author must have used a larger region for widget action, since the widgets in OS 9 respond like they do with Cocoa apps.

I certainly hope for more uniformity in the coming update, preferrably towards a larger region than the Carbon one since I almost have to hit the center of the widget to get it to respond.

[barbarian]

Do not think the Carbon behavior is a bug because the mask doesn't affect what is viewable (doesn't work like 9 masks/alphas). The mask is there to determine what is clickable and what is not...at least in my understanding of how it works. Whatever is masked will be clickable, whatever is not masked won't be. Only the alpha affects what is viewable. In fact the alpha is not really an alpha in the traditional sense, but simply a multi-bit mask. (If I am wrong please correct me with proof. Someone with access to pxm editing tools could test this by simply removing a mask and seeing if the object was still visible.)

I agree the Cocoa behavior should be fixed, but I wouldn't call the behavior dangerous. as none of the parts overlap (with the exception of scrollbars which are special cased). Most people are sloppy with their clicking. One or two pixels or flex shouldn't be a big deal and might be considered fault tolerant (or as the original poster said, more responsive).

What I do have a problem with the the widget placement. I'd prefer close box away from the others...but that's another topic.

[This message has been edited by barbarian (edited 04-15-2001).]

Originally posted by barbarian:
Do not think the Carbon behavior is a bug because the mask doesn't affect what is viewable (doesn't work like 9 masks/alphas). The mask is there to determine what is clickable and what is not...at least in my understanding of how it works. Whatever is masked will be clickable, whatever is not masked won't be. Only the alpha affects what is viewable. In fact the alpha is not really an alpha in the traditional sense, but simply a multi-bit mask. (If I am wrong please correct me with proof. Someone with access to pxm editing tools could test this by simply removing a mask and seeing if the object was still visible.)

No, that's pretty much it. If the 1-bit mask is used to determine the active hit area of the object though that is a bug - the active hit region should be the entire visible area of the object in question. With Aqua using soft edges for as many objects as it does, this is a fairly big usability problem. It could be as simple as changing the 1-bit mask to correspond with the 8-bit mask's region. Someone would have to test that to make sure it didn't compromise the image.

I agree the Cocoa behavior should be fixed, but I wouldn't call the behavior dangerous. as none of the parts overlap (with the exception of scrollbars which are special cased). Most people are sloppy with their clicking. One or two pixels or flex shouldn't be a big deal and might be considered fault tolerant (or as the original poster said, more responsive).

Applications are supposed to warn a user if their action is going to cause a loss of data (such as hitting the close widget) but not everyone plays well with others. There is a 1-2 pixel space between the close & minimize widget on the titlebar, as all of the widgets display their rollover state when you move the mouse in their general vicinity you have to be more careful which one you're clicking when using a Cocoa app. They do highlight properly though, so that's one last bit of feedback you can use to make sure you're doing the right thing.

I'd prefer to see both implementations use what's proper - the visible area of the widget - rather than an approximation. But you know, that's just me: Crazy Ole Jethro .

[barbarian]

A couple of things:

-a properly written app should never lose data without warning when a window is closed (so this should be a non-issue). The bigger issue in my mind was putting the buttons right next to each other....

-more investigation has shown that these are almost certainly special cased... checkboxes, radio buttons, and tool bar buttons have wide hit tolerance and push buttons have almost none (you have to hit inside the pushbutton).

As someone who often labors of HI details, I think the tolerance is actually a feature (again note the first poster who felt that cocoa was "more responsive"), but good HI would dictate that both Carbon and Cocoa work in exactly the same way and they do not (try clicking around on the toolbar in omniweb and then try the same thing in the finder...Cocoa looks at toolbar icons as big squares, Carbon doesn't).
The problem is that there are 3 different APIs each with their own HI features and sins. Apple complicates this by having similar but subtly different behaviors. Apple, post the NeXT merge, hasn't been paying much attention to HI engineers this much is obvious (just analyze at the monstrosity known as Sherlock)...but that's a different rant.