Re: Window managers

[Fred Kiefer]

Christopher Armstrong wrote:
> 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.
> 

I did understand all this when writing my mail :-)
Still I think it is dangerous to steal mouse events that are not meant
for our application. Perhaps it would be better to move the capture into
the trackMouse:inRect:ofView:untilMouseUp: method on NSCell (if the falg
is YES). This seems to be the only place where this is valid. On the
other hand, if you have a proof that your code will never have any
negative outside effect then share it with me.

>> 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?
> 

No, I don't think so. I was just not sure, what may cause a WM_PAINT
message. If this never gets triggered by our code, only by a resize,
then the code is valid.

Cheers,
Fred