bug-gnustep
[Top][All Lists]
Advanced

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

Re: DnD improvements


From: Adam Fedor
Subject: Re: DnD improvements
Date: Sat, 08 Dec 2001 22:36:39 -0700
User-agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:0.9.4) Gecko/20010915

Willem Rein Oudshoorn wrote:

A cursory debugging session of _DPSsetcursor: showed that
        generic.currentMouseWindow;
is None almost all of the time. (That is not GOOD) You know probably better than I do how cursor are supposed to work,
and I would like to fix the code.  But I do not understand at all
what the idea is behind the current code.


Well I did qualify my last statement about tha cursor patch :-). I think it is better than it was, even if it doesn't look like it. The problem is that OpenStep assumes cursors are global and work everywhere, while X cursors are only valid in the window it was set in. Trying to mesh the two is very difficult - particularly in DnD sessions when X events seem to be very counterintuitive, almost counterproductive.

What's supposed to be happening is that when you set an NScursor, the backend should get the window that the mouse is currently in and set the X cursor in that window. Every time you move the mouse to a different window, you should get an EnterNotify event, and the backend should make sure the current cursor is set in that window as well.

Drag events are a particular problem since the mouse is over the drag window most of the time, but occationally gets EnterNotify events when it crosses into another window. I'm still not sure how to make this more reliable.


Next question is about the caching of the cursors.
When I implemented the code I briefly thought about caching
them.  I did not make a cache, because in my opninion caching
the cursors is a job of the NSCursor class. Looking at the documentation of the NSCursor class did not reveal any method that makes this impossible.


That's probably a good idea. As the code was, almost every drag event created a new X cursor (I'm not sure how much of a drain on X resources that was).


Besides that, why do you create a new `ArrowCursor'?
The says that it is done because we color it.  But
the coloring is done in the call

        DPSsetcursorcolor (....., [newCursor _cid]);

So I don't see the reason for the duplicate.


Well that's the problem with caching cursors. When I cached the default arrow cursor in NSCursor, and its colored in the drag session, there's no cooresponding code to uncolor the arrow at the end, so often the default arrow cursor ends up being green for the rest of the time.

--
Adam Fedor, Digital Optics            | Fudd's law of opposition: Push
fedor@doc.com  http://www.doc.com     | something hard enough, and it
fedor@gnu.org  http://www.gnustep.org | will fall over.




reply via email to

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