[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Window managers

From: Christopher Armstrong
Subject: Re: Window managers
Date: Tue, 10 Apr 2007 09:19:29 +1000
User-agent: Thunderbird (Windows/20070221)


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]