Matthew Skala commented on issue #5311 at KiCad / KiCad Source Code / kicad

Matthew Skala
2020-08-25T13:45:10Z

The button tooltip is "Change cursor shape" ("Switch display of full-window crosshairs" in 6.0), and the icon shows a small dark crosshair on a lighter full window crosshair.

I haven't been able to recompile version 4.0 for testing because it's no longer compatible with the current versions of a bunch of libraries, but from screenshots on the Web it's clear that 4.0 used the same icon; and I think that the change in the button's behaviour, removing the function of being able to turn the crosshairs on and off, did not happen until 5.0. Both tooltip texts mentioned are compatible with having the button be able to turn the crosshairs on and off: the button should be changing the cursor shape between crosshairs and a typical mouse cursor, and it should allow switching the display of the crosshairs on and off, not only between large and small.

Even if the tooltip or icon had to be changed, which is not the case, then the right thing to do would be to go ahead and make such changes. The button ought to do whatever is best, and then the tooltip and icon should accurately describe it; tooltip or icon should never be an excuse for leaving the behaviour broken.

The button does not enable/disable crosshair visibility.

Yes, that is the issue I am reporting.

From what you write, it seems it is working as-designed.

If so, then the design ought to be changed, because the way this button used to work was better than the way it works now, and the way it currently works (especially, the fact that it has only an invisible effect when clicked during arrow mode while "Always show crosshairs" is in the default state) is far enough away from reasonable user expectation that it can't rightly be called a good design.

Crosshair cursor acts as a visual indication a tool is activated. I.e. it is state dependant.

I don't need a large and intrusive graphical indication following my mouse just to tell me when I am not in the arrow tool, and I do need the ability to line things up horizontally and vertically when using the arrow tool. It is not reasonable to sacrifice the utility of crosshairs in the arrow tool just so that their absence can serve as an indication of whether I am in the arrow tool.

Some would see this as a regression since you're loosing [sic] the state dependant visual indication of the selected tool.

That is no excuse for leaving the software broken.

On the contrary, the fact that it used to work the way I think it should is strong evidence that the old behaviour:

is possible;

is probably easy to go back to; and

was considered acceptable by the maintainers when they released it.

You've used the phrase "state dependent" several times as if that's supposed to be a good thing. It is not. From a UX perspective, having a feature be "state dependent" means the feature is harder to control and comes across as the software overriding the user's preference - especially when there's a clearly visible button for expressing the preference and clicking that button has no effect, which describes the current user-visible behaviour when in the arrow tool with "Always show crosshairs" at its default setting of off. The fact that the button may be invisibly changing the hidden state of what size the crosshairs would be if they were visible, does not make the do-nothing button better; that makes it worse. Hidden state is a bad thing that should be avoided wherever possible; not a good excuse for leaving the software broken.

Lack of crosshairs in the arrow tool is especially annoying in combination with features like DRC and "cross-probing" that cause a window to jump to a specific component or net.

This is exactly what the aforementioned "Always show crosshairs" setting is supposed to solve, people who always want a crosshair.

I don't always want a crosshair, but having a crosshair in all tools, although worse than the original behaviour, is better than having it be missing in the arrow tool in particular. As I said:

But it's not desirable to really have them turned on all the time, because they can get in the way during tasks like component placement. Letting the user control it with a button in the main UI to turn the crosshairs on and off easily in all tools/modes was the right way to handle this.

What is the rationale for having DRC click-to-view-the-error, and cross-probing between schematic and PCB, without crosshairs? These features depend on indicating a point in a window when the mouse cursor is not in that window, so if the mouse cursor is the only way of indicating the current focus location, DRC's ability to focus on flag locations, and cross-probing between eeschema and pcbnew, lose very much of their value. It's hard to see that as anything but a bug - and it's a bug that was introduced by the removal of crosshairs from the arrow tool.

What is the rationale for not being able to turn off crosshairs in any tool other than the arrow?