[patch] cursor

[Jehan]

Harold Hunt wrote:
> As I thought, the documentation for WM_NCMOUSEMOVE does say that you are
> supposed to return 0 if you process that message.  However, they fail to
> mention that things such as button highlighting are handled by
> DefWindowProc, which you still need to call if you want to preserve that
> default behavior.  This document gave me some indications that this was the
> case:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui
> /windowsuserinterface/userinput/mouseinput/aboutmouseinput.asp

Yes, that's where I saw it ("Nonclient area mouse messages" section)


> One thing that is not entirely clear is whether we should call
> DefWindowProc, then return 0, or if we should just 'break' after our
> processing of the message and return whatever DefWindowProc returns.  I've
> opted for the latter, for now.

I think this way is better too. We are adding a functionality not 
replacing it so it's better to let Windows do whatever it would have 
done if we didn't catch this message, i.e. return what DefWindowProc 
returns.


>>    - Moreover, the cursor state is global to the application, not to
>>each window. So I made fCursor a global variable, which simplifies the
>>code more (doesn't care about ScreenPrivLast anymore). Potentially, we
>>could get rid of fCursor  altogether by using GetCursorInfo instead
>>(don't know about performance issues though).
> 
> 
> Making the cursor state a global variable is probably a good idea; or, we
> could at least make it a static inside winWindowProc if it is not accessed
> elsewhere.  This would take care of the cursor hiding/showing problems that
> happen when we have multiple screens.  (e.g. XWin -screen 0 640 480 -screen
> 1 1024 768)
> 
> I'll go ahead and switch the cursor state variable to a global.

A static would do the job but, by personnally, I don't like static in a 
function. It's easy to miss the "static" keyword when reading the code 
which then make it hard to understand (or at least, I missed it. Several 
times already I spent a few hours to try to understand why the code was 
working just because I missed it :p).
And it has to be initialized by a constant. However, I already got on a 
couple occasions the pointer visible with no way to hide it. Is it 
possible for the window to recieve a WM_MOUSEMOVE before initializing 
the variable (I haven't check the code for that yet)? Because I would 
think the reference count on ShowMouse has gotten screwed. So we may 
have to use GetMouseInfo to initialize the value (which I think is 
better than assuming that the mouse is visible when an application 
starts anyway).


>>    - It maybe just a matter of preferences but for me, I prefer if the
>>windows cursor is hidden in the client area of X if it isn't active. I
>>personnally find it ugly to have two mouse cursors on top of each other
>>:p. It's then not necessary to show/hide the mouse upon (de)activation.
>>This simplifies the code a bit.
> 
> 
> This is really a matter of preference.  I originally coded it this way, but
> I got enough complaints that I switched to the current system of not hiding
> the cursor when we don't have the focus.  Maybe we can make this a
> configuration option?  As it is it just reverts to previous functionality,
> so I'll skip it for now.

Do you remember why would people want to have two cursors? To me, that 
doesn't make sense. I can see one case where it /might/ make sense: it's 
if an X app hides its own cursor, but then, it's the X app's 
reponsability, not XWin.
Well, it's not a big deal, it's just ugly :)

	Jehan