Re: DnD improvements

[Willem Rein Oudshoorn]

Adam Fedor <fedor@doc.com> writes:

> Willem Rein Oudshoorn wrote:
> 
> > 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. 

Yes you are right, but I was a little confused when I noticed,
what at first glance, seemed a degradation of the cursor handling.

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

Well, it seems a complicated way to go about it.  Might be the best way, 
but I got the following naive idea:

* We have a list of all windows of the application, right?
* If we set the cursor, why not set them for all windows at the same time.
* Keep a global variable, currentCursor.
* When creating a cursor set the cursor for this window to the current cursor.

Seems somewhat simpler. 
(Note that this not solve the problem when application A changes the cursor
and the cursor is hovering application B, but neither thus the current
approach)
 
> 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.

Should work because the drag window is just an ordinary window.  
So any generic mechanism ought to work.

> 
> 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).

You are right, I should probably not have submitted code without some
caching in place.
 

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

I think this is caused by the same problem that caused the irregular
cursor updated during the drag session.   But of course you'r workaround
is better than the buggy behaviour.

Besides that, I was wondering if it would not be better to have 
different cursors for the green and black cursors, instead of
coloring them with the DPSsetcursor function.   
Than we can leave all the cursor setting etc. to the NSCursor class
(whose job it is anyway).  On the other hand, the DPS functions
should be implemented anyway.


Wim Oudshoorn.