[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Window managers
Re: Window managers
Tue, 10 Apr 2007 10:52:10 +1000
Thunderbird 188.8.131.52 (Windows/20070221)
Fred Kiefer wrote:
Yep I think this would be a better solution, only reason I didn't pursue
it is that it is platform dependant (although we can still call
capturemouse/releasemouse from the frontend on X anyway). I only
advocate capturing the mouse as it best replicates the functionality the
frontend is expecting i.e. mouse up events outside a window, AFTER a
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.
The other solution I had thought of was in fact something from the
frontend that used such services in the backend. With the
backend/frontend interaction in general, I think there are points where
we need more fine-grained interaction than what is currently possible,
e.g. in terms of events . I also think that there are also points where
we should shift responsiblity to the backend i.e. (and this is just my
* mouse tracking is currently in the frontend, when the window servers
we are targeting have this functionality in them.
* window resize events need to be more coordinated with the frontend.
Considering we are really only targeting win32 and X, this shouldn't be
too difficult. Whilst we may wish to target other servers in future, I
think its fairly safe to assume that most of our users rely on either X
or win32. This should at least make the job of fixing display server
I think there are also some bugs related to the use of nonretained
windows in the frontend. If you switch to a non-retained window in Gorm,
it doesn't update in response to normal interaction, only when a repaint
is forced. Have you observed this? I've been unable to solve this issue
from the backend, I may need to look into the frontend as well.
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.