mouse clicks in os-x

Doug Way dway at mailcan.com
Thu Jul 29 15:24:02 UTC 2004


On Wednesday, July 28, 2004, at 06:31 PM, Ned Konz wrote:

> On Wednesday 28 July 2004 2:03 pm, John M McIntosh wrote:
>> I believe the standard behavior should be that clicking on an 
>> inactive  
>> window brings that window to the foreground and does not process the  
>> action of clicking on the contents of the window.
>
> That sounds to me like the kind of thing that is properly the policy 
> of the
> window manager, not of the application.

Well, if the window manager in this case (OS X) doesn't keep track of 
the policy, there's not much you can do about it. :)

At least I'm pretty sure there is no setting anywhere in OS X which 
lets you change the policy... it always seems to be "Activate & Raise". 
  Well, technically I guess it is "Activate, Raise & Pass Click", but 
nearly all applications ignore the passed click by convention.  So I 
think John is right to have Squeak follow the convention and ignore the 
passed click. (so that the World menu in Squeak doesn't pop up)

Hm, I just tested this on a bunch of applications, and they all ignore 
the passed click, except for Netscape 7.0 (which I happen to have lying 
around), oddly enough.  But Netscape doesn't seem to follow the OS X ui 
conventions that well anyway... it has its own widgets, etc. (kind of 
like Squeak, I guess :) )

But anyway, I would say yes, change the behavior in the Carbon VM so 
that Squeak does not process the passed click.

- Doug


>
> At least my window manager (kwm) allows me to specify that policy. 
> That is, I
> can choose between "Activate, Raise & Pass Click", "Activate & Pass 
> Click",
> "Activate & Raise", etc. for the action of each of the buttons on an 
> inactive
> inner window (and separately on an active or inactive titlebar or 
> frame).
>
> In the Unix X11 display module, we tell the window manager that we 
> expect
> input but never explicitly set focus to any of our subwindows.
>
> However, in the Windows VM we ensure that we have focus on a 
> WM_?BUTTONDOWN
> (OR BUTTONUP) message, then go ahead and process it as normal (in 
> fact, we
> check the focus twice on a buttonUP message, just to make sure!). So 
> the
> behavior is the same as kwm's "Activate and pass click". But this is a 
> focus
> policy decision on the part of Squeak.
>
>> What I'm proposing here is to "FIX" that issue and revert to standard 
>>  
>> click processing on window activation. Squeak and the squeak window  
>> should come to the foreground, but we shouldn't pass on that mouse  
>> click to cause the desktop menu to be displayed.
>>
>> Please let me know if you have any concerns with this change.
>
> -- 
> Ned Konz
> http://bike-nomad.com
>
>




More information about the Squeak-dev mailing list