Since I'm busy working on multiple window support an annoying issue finally percolated upwards in how the carbon os-x VM works with mouse clicks.
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.
However a side effect of how we are processing mouse events means the mouse event is passed into squeak on a window activate. An example would be to startup squeak, startup another application in the foreground, then click on the squeak desktop area when squeak is the background application. This then brings the squeak and the squeak window to the foreground, and also then triggers the display of the desktop menu.
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.
PS if anyone used the carbon mac os-x- squeak feature to make the squeak window into a floating window they might want to check their application very carefully once I submit a 3.8 VM for testing.
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
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.
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, could you clarify.
Does the windows VM bring the window to the foreground, then process the click, so clicking on the squeak desktop when squeak is a background window will cause the window to come to the foreground, then cause the squeak desktop menu to appear?
On Jul 28, 2004, at 3:31 PM, Ned Konz wrote:
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.
-- Ned Konz http://bike-nomad.com
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
On Wednesday 28 July 2004 11:53 pm, John M McIntosh wrote:
Does the windows VM bring the window to the foreground, then process the click, so clicking on the squeak desktop when squeak is a background window will cause the window to come to the foreground, then cause the squeak desktop menu to appear?
Yes.
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
You should see the fun I have for RISC OS, where the convention is that the left mouse button click passes focus (if the app accepts it) but the menu & adjust buttons do not move focus. You can menu, choose options etc in one window without it being raised to the front and whilst typing goes to another window entirely. Oh and moving focus doesn't raise the window either.
It sounds pretty odd written down but it works amazingly well, mostly. It's a bit of a pain in Squeak that the left-mouse-click also opens a menu sometimes though.
tim
On Jul 29, 2004, at 11:24 AM, Doug Way wrote:
... 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 :) )
Minor update: I happened to test Netscape 7.1 (on OS X 10.3), which supports native OS X widgets (scrollbars etc), and it ignores the passed click, unlike 7.0. So that definitely seems to be the convention.
- Doug
Ned Konz wrote:
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.
Ned Konz http://bike-nomad.com
In the Mac world, you can't define that behavior. That's the way it's supposed to work.
Ned,
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.
No, it isn't. You are misinterpreting GetFocus() and SetFocus() API calls:
The GetFocus function retrieves the handle to the window that has the keyboard focus, if the window is attached to the calling thread's message queue.
The SetFocus function sets the keyboard focus to the specified window. The window must be attached to the calling thread's message queue.
That is, all we do is ensure that we have the keyboard focus after you clicked on Squeak and the only reason we do this is because the console window at the bottom of Squeak might grab it (if you have a VM log message and click in it). This has absolutely nothing to do with focus policy decisions.
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.
Unfortunately, there is absolutely nothing I can do - this decision isn't made by the VM at all.
Please let me know if you have any concerns with this change.
Only that it is impossible to implement ;-)
Cheers, - Andreas
On Thursday 29 July 2004 1:31 pm, Andreas Raab wrote:
Ned wrote:
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.
No, it isn't. You are misinterpreting GetFocus() and SetFocus() API calls:
Ah, right. It's been a while since I spent time doing Windows programming.
Note that it was John's proposed FIX to the Mac VM and not mine.
John McIntosh had said:
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.
Unfortunately, there is absolutely nothing I can do - this decision isn't made by the VM at all.
Please let me know if you have any concerns with this change.
Only that it is impossible to implement ;-)
Actually, couldn't we process WM_MOUSEACTIVATE and return MA_ACTIVATEANDEAT to get the policy that John's suggesting?
I was at Tim's place today and fiddled a bit with squeak on windows, also with some other applications.
It seems Windows prefers to raise the window and pass on the click to the application. If this is the accepted Windows behavior I don't see a need to change it.
What I was confirming is the behavor on os-x should match the expectations set by the UI and followed by other application. That results in less confusion and ensures Squeak isn't behaving weirdly as compared to all the other applications someone might be using on a mac.
On Jul 29, 2004, at 2:15 PM, Ned Konz wrote:
John McIntosh had said:
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.
Unfortunately, there is absolutely nothing I can do - this decision isn't made by the VM at all.
Please let me know if you have any concerns with this change.
Only that it is impossible to implement ;-)
Actually, couldn't we process WM_MOUSEACTIVATE and return MA_ACTIVATEANDEAT to get the policy that John's suggesting?
-- Ned Konz http://bike-nomad.com
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
On Friday 30 July 2004 12:41 am, John M McIntosh wrote:
It seems Windows prefers to raise the window and pass on the click to the application. If this is the accepted Windows behavior I don't see a need to change it.
That seems to be what (at least some) other apps do, as well.
What I was confirming is the behavor on os-x should match the expectations set by the UI and followed by other application. That results in less confusion and ensures Squeak isn't behaving weirdly as compared to all the other applications someone might be using on a mac.
I understand. It's reasonable to make Squeak work the same, I think.
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.
However a side effect of how we are processing mouse events means the mouse event is passed into squeak on a window activate. An example would be to startup squeak, startup another application in the foreground, then click on the squeak desktop area when squeak is the background application. This then brings the squeak and the squeak window to the foreground, and also then triggers the display of the desktop menu.
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.
That's exactly how it should act.
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Doug Way -
John M McIntosh -
John Pfersich -
Ned Konz -
tim Rowledge