Re: Window managers

[Christopher Armstrong]

Hi

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.

Regards
Chris