Snap controls bar, implicit checking (Wishlist)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Inkscape |
New
|
Wishlist
|
Unassigned |
Bug Description
Wishlist
(Based on behavior of trunk from Feb 29, 2012).
On the snap controls toolbar there are four identical icons (blue square to black arrow to green square).
Top to bottom, these are:
A Enable snapping (%)
B Snap bounding boxes
C Snap nodes paths and handles
D Snap other points
Even though all of these icons are identical this is actually a hierarchical menu, just presented in 1D. "A" enables/disables everything, B, C, D enable/disable their respective options, and those options in turn need to be enabled or disabled. If a user, while icon A is not selected clicks on the "snap to paths" icon nothing happens even though the intent is to enable "snap to paths' (obviously!) This is because Icons A and C must be enabled before the "snap to paths" icon may be made active by clicking on it.
I do not see any reason for this restriction.
Clearly if a user clicks on a snapping mode they want to enable it, and doing so should automatically enable the icons above it, here C and A. Similarly, if a user clicks on "A" then "C", no snapping is actually enabled until they then click on one of the options under "C" - the state with A & C on but nothing selected under C makes no sense.
Additionally, I would suggest changing the labels on those icons to:
A Toggle Snap (all)
B Toggle Snap bounding boxes
C Toggle Snap nodes paths and handles
D Toggle Snap other points
This is because those icons do not just Enable, they also also disable. (If the label changed from Enable -> Disable with the state that would be even better, if the GUI supports that.)
Also icons A,B,C,D should be some variant of a "0/1", or "on/off", icon, as the "snap" part is implied by their location in this menu, and is redundant with their sub-icons. That is, the icon shape is not consistent with their function (toggling the logic) but with the function of the menu (so redundant).
Here is an example of the desired interaction, starting with everything off.
User clicks on "Snap bounding box corners" icon -> icons A and B are set, as is the clicked icon
User clicks on A -> all icons are unset
User clicks on "snap to paths" -> icons A, B, and C are set, as are "snap bounding box corners' and "snap to paths"
The logic is that this sets C, C sets A, and once A is set all icons which were disabled by A are also set again.
User clicks on B -> icons B and "snap bounding box corners" are unset
User clicks on B again -> icons B and "snap bounding box corners" are set
User clicks on D -> icon D and the two ions under it are set.
Logic - neither of the icons under it was set initially, but having D set with none of its suboptions set does
not change the behavior of the program, even though one of the icons has changed from unset to set.
So redefine from the current behavior: clicking on B,C,D when these are off and none of the subentries were previously set will now set the clicked icon and all of its subentries.
By the same logic clicking on A when none of the other would set would set everything. That, I think, is undesirable, since that is unlikely to be the users intent. If A is off there is no way for the user to know what the state of the other icons is. It might be best in the case (all disabled) and the user clicks on A that it put up an error message, suggesting that something further down the list should be selected, and that the state of A not change. Again, if the GUI supports this sort of thing, the label for "A", might change to "no snap options are enabled", to distinguish this eventuality from
the other operating modes.
Changed in inkscape: | |
importance: | Undecided → Wishlist |
tags: | added: snapping ui |
Hi David,
Thank you for taking the time to report this. Let me explain how we have arrived at this solution:
- It's indeed hierarchical, in 1D. To communicate this to the user, the dependent buttons are being greyed out as soon as the button they depend on is being toggled off. I believe that this is a good way to let the users discover the hierarchy, in the least awkward way. Of course more advanced users might feel this is a restriction, but still I believe that this is not that bad of a compromise.
- By grouping the various snap options liek we have done, it's quite easy to quickly turn off a large set of snapping solutions using a single button. For example, this allows you to quickly switch from snapping bounding boxes to snapping nodes to paths, or vice versa. There's less need in such a case to think about which buttons need to be toggled.
You're right about the labels, these should be improved. However, I don't like the idea of changing the state of multiple toggles, when clicking on one of them only. Although this can work, I don't believe that this makes things more intuitive, maybe only more efficient. Do you have any examples of others programs that work like this?