Mouse cursor issues Beta 3.0-1 #Windows #beta

Joost van der Waa

I installed the latest beta 3.0-1 (which shows as 3.0 without -1, but that's just a detail) and I have some serious issues with the mouse cursor.

After placing a track element the mouse cursor changes into the 4-arrowhead mouse cursor.
1. When moving your mouse back to the hotbar, a part of the cursor stays behind on the drawing area, see the attached screenshot.
2. When not on any one of the icons on the hotbar, the mouse cursor is hidden, like in the area next to the layout levels in the attached screenshot. Basically you have no idea where your mouse cursor is....

I guess this is caused by a different treatment of the mouse cursor in 3.0.

I am sorry to repeat my request, but I would strongly suggest to move back to the 5.1.2 way of showing and handling the mouse cursor and get rid of the arrowhead cursor. The way Xtrackcad is handling the mouse under Windows is very confusing and unintuitive...

Peter Borcherds

Yes, I experienced the same issue last night (Windows 10). Haven’t tested it on my Mac yet.

Peter Borcherds

BNSF Chicago Sub in N Scale
N Scale Commuter, Freight & Switching Layout



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.




Joost van der Waa

Hi Adam,

Given you explanation I would say: add the option, if that is relatively easy.

My personal preference would still be to get rid of the arrowhead cursor, for me it does not really add precision. Would it be an option to give the user the choice between cursor shapes to solve the issues? With the system cursor you don't have to hide/show anything...



I can confirm the same occurrences on Ubuntu 20.04. Curser is hidden on the canvas.