[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 10:52:10 +1000
User-agent: Thunderbird (Windows/20070221)


Fred Kiefer wrote:
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.
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 mouse down.

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 opinion) * 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 interaction easier.

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.

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.


reply via email to

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