Re: Window managers

[Christopher Armstrong]

Hi

> I am not sure if capturing the mouse is a great idea. I understand that
> we have the problem with Windows of not getting a mouse up event when
> the mouse leaves the current window. But this should be handled on
> another level. In most cases we are not interested in a mouse up, so why
> always capture it? This could disturb the interaction with other
> applications.
>   
I believe we are interested in the mouse up event. The key problem is 
that mouse up events are expected to be sent when the mouse is released 
outside of  the window it went down in i.e.

1. mouse goes down in our window
2. user holds button down and moves the mouse outside one of our windows
3. user releases the same mouse button

This particular scenario is used for popupbuttons at least. IMHO 
capturing the mouse for this scenario is reasonably safe; every windows 
application does it for menus in order to determine if the user clicks 
outside their window. We need it to track this particular set of events 
as it is expected by our UI.

If you read the Cocoa docs carefully, you will notice that mouse up 
events only get sent when a mouse button goes down in one of your 
windows (it doesn't get sent in other scenarios). Capturing the mouse in 
this way emulates the appropriate event handling. The only other way is 
to install a hook DLL, which is too extreme.

> As for the change in windowbacking:, I could prove to you that it is not
> needed. But if you feel more comfortable with explicit code, it is fine
> for me.
>   
> I feel a bit uncomfortable with the change to invalidateWindow(). This
> looks like a potential recursion problem. The back end here asks the
> front end to do some drawing and this of course will ask the back end to
> do it. I think it wont loop, but still it looks a bit dangerous. Perhaps
> some simplification and documentation of the code would help here.
> It looks like invalidateWindow is now only used in
> decodeWM_PAINTParams:::. So why not move the code to here?
>   
The main reason for forcing a redraw is that the window has been 
resized, and the frontend thinks it can hold off redrawing until the 
resize event loop is over, which is correct on many other platforms, but 
incorrect on Windows when full redraw during resize is sent. During 
WM_PAINT, the window is expected to redraw itself, so that's why I 
forced it here. The reason for keeping track of whether the backing 
store is empty is that we don't want to blit a blank backing store onto 
a window that has just been invalidated anyway. OTOH could you explain 
how a recursive loop may occur? Is it possible that the frontend would 
try re-enter the runloop whilst it is redrawing?

Regards
Chris