|
From: | Christopher Armstrong |
Subject: | Re: Window managers |
Date: | Tue, 10 Apr 2007 09:19:29 +1000 |
User-agent: | Thunderbird 1.5.0.10 (Windows/20070221) |
Hi
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.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.
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 buttonThis 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.
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?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(). Thislooks 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?
Regards Chris
[Prev in Thread] | Current Thread | [Next in Thread] |