Re: Mouse cursor issues Beta 3.0-1 #Windows #beta

Adam Richards

The deal is we have to pick between some imperfect solutions as we navigate between platforms and windowing systems. The situation of cursors and their behavior as they move between what are actually two separate widgets/windows (hotbar and drawing area) on Unix&Mac/Windows is not fully under our control.  We are building on some divergent underlying technology stacks. As a result, the implementation is a compromise between competing user interests/requests. On the one side is precision and clarity of effect. On the other is ubiquity of the system cursor in spite of the misleading impression.

In V5.2 we did not originally suppress the system cursor (cross-hairs) at all. This led to having two "cursors" (system cursor and the specialized prompt/anchor which could be in a different place due to magnetic snapping) and was complained about by users in some bug tickets and feature requests because (on Windows at least) different system cursor "effects" could be set in such a way that it inverted colors or otherwise got in the way of the XtrkCAD prompt/anchor and didn't show precisely where the action would take place.  The suggestion that users could disable that type of behaviour in the Windows preferences was not deemed adequate.  So then we added code that (imperfectly in a couple of cases, see below) suppressed the system cursor if the specialized cursor was drawn on the drawing surface.  You'll see that in most cases, this ensures only one cursor shown at a time, so the effect of what a user will do if they click is clear. 

There were some clear cases where the cursor was being suppressed too long (all ones we have found so far have been fixed and will be included the upcoming Beta V3.1 version). I also added some "belt and suspenders" code to always reset cursor state when a new command is run as well as after Esc.

However, there is still the issue that (on Windows and not UNIX) there seems to be a "buffer-zone" where the system does not  signal us that we have moved into the other window even though we have moved a long way into the hotbar and so doesn't allow us to turn the cursor on again. I imagine that may be related to not setting the focus to be on that hotbar window (doing so has negative effects the other way round when moving off it and back to the surface as you would have to click twice (once to gain focus, once to do the action). To cope with the system buffering, I have added some more code that keeps/restores the system cursor when within 20px of the drawing window edge (in-spite of the cries of pain from the overlay crowd, no doubt). 

The price of fixing the "but you left part of an XTrackCAD cursor stranded on the edge of the drawing area" complaint, would be that we suppress drawing that cursor when close to the edges as well (swap cursors). This would reduce the knowledge and precision of any specialized cursors/snapping in that buffer zone, however.  

I am not inclined to move back to V5.1, since that would remove a large amount of the usability gains of showing the user what will happen and where.

What we could do is to have an option that says (don't suppress system cursor). I suspect that those who requested the change to suppress the cursor are among those that now dislike the suppressed cursor...  But it would be relatively easy to give the option.  

This is not, of course, an excuse to not fix any remaining suppression circumstances as they occur.




Join to automatically receive all group messages.