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
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev