Snap controls bar, implicit checking (Wishlist)

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?

This sort of explicit check of levels above is common in installers for complex software. The custom install menu might look like this:

0 Level1 Option 1
0 Level2 Option 1
0 Level2 Option 2
0 Level3 Option 1
0 Level3 Option 2
0 Level2 Option 3
0 Level1 Option 2

and then when you select "Level3 option2" (this might install help files in one nonstandard language) the whole thing converts to

1 Level1 Option 1
0 Level2 Option 1
1 Level2 Option 2
0 Level3 Option 1
1 Level3 Option 2
0 Level2 Option 3
0 Level1 Option 2

Usually in these installers the menu is nested and expands and contracts. So after closing up "level1 option1" we can still tell that something in it will be installed, even though we can no longer see what. The Inkscape snap menu is different in that it is always expanded. And that is the confusing part - it is possible to click on buttons and nothing happens, or to click on an enable button, with none of the suboptions enabled, and then the display changes but the program is effectively still in the same state. (Options below here enabled if selected (but none selected)).

I generally only have a couple of "snaps" enabled at a time - if there are too many then it becomes hard to control object movement.

The other way to go about something like this is to let the user store (named) states, and then switch between them using a pull down menu. That approach would look like a cross between the Layers tool and the Align and Distribute tool. See the attached drawing (red squares are selected options, I could not highlight the static button images). In some ways I would favor that approach over what we have now because:

1. Snapping is the only right side menu of its type, and I would rather have the screen drawing space.
2. It is almost impossible to work in Inkscape without "fill and Stroke" and "Align" stacked up in the dock on the right side of the screen. Since those are already there, adding one more entry to the dock ("Snapping") would take up no more space.
3. I generally would only ever use 2 or 3 snapping states in a drawing. (None, snap to sides, snap to nodes). Selecting those from the pull down menu is probably faster than disable one set, enable the other.

Just realized that the "iconify the dock" icon arrow points the wrong way. It points left, but the dock iconifies to the right.

Hallo David,
> It is almost impossible to work in Inkscape without "fill and Stroke" and "Align"
> stacked up in the dock on the right side of the screen.
That's not true for me. I like having the most space free on screen while working so I never use stacked up docks. Also, doing technical drawings I don't have a so frequent need of changing fill and stroke, nor alignment as I use guides a lot and they are always available and only where needed.
On the contrary, I make an heavy use of different snapping options and having all of them ready for use on the (thin) right bar is really handy.

I also use at most few snapping configurations but they usually differ for a button or two, so toggling between them is quick and easy for me.
Anyway, I already proposed the customizable toggle sets (in the form of few more buttons in the bar, of course ;) but if made as you proposed (in a dock) they would indeed take up a huge space for me! I'd rather prefer to have small buttons with a key combination for fast selection (something like ctrl-alt-1, ctrl-alt-2, and so on); like pipe organs' stops and free registrations, if you know how they work. Personally I don't feel so comfortable with pull down menus: I feel they are hiding the information of which combination I'm using, but just showing its name.

It's true that enabling a group toggle without any sub-toggle enabled does not change anything on Inkscape's snapping behavior, but why should you have it disabled if nothing is being disabled? :) Maybe the main toggle could be grayed out when no sub-toggles are selected so it remains in the on state until something is enabled under it, but I feel this would be just a cosmetic change that in some cases could give problems to users not understanding what's going on and a better visualization of toggled-but-disabled buttons would be needed anyway.
In general I don't like a lot the idea of setting all sub icons when none is on and the master becomes enabled: I never have a full set of options all enabled at once, so If for some reason I had disabled a whole subgroup and temporary switched off all snappings with the master of masters button (sometimes I do when there are too many objects on canvas and I have to move a big group), when coming back to snapping enabled I'd find a lot of buttons unintentionally toggled on and would have to switch them all off manually. To avoid this, an exception on your proposed behavior must be introduced so when a master is toggled by a super master, the rule should not apply; I feel it's becoming too complicated. And someone could toggle a master with no subs enabled by mistake...