snap to guides no longer working for path nodes or rotation origin

> Self-compiled Inkscape 0.48+devel r10923

Due to various refactoring of the snap code in current trunk, you need to activate a specific node snap option (e.g. cusp nodes, and/ or smooth nodes) to have nodes snap to guides and grid when using the selection tool (not required when working in the node tool context, or one of the path drawing tools - pencil (freehand) or pen (bezier)).

Not sure whether this can be considered a bug - as far as I understand, it was an intentional change in how snapping works. Possibly you want to change the snap settings in the default template.

See also:
<http://article.gmane.org/gmane.comp.graphics.inkscape.devel/37130>

Same issue also mentioned in an earlier comment [1]:
«(…) In the select tool, please make nodes of dragged objects snap to path, to grid, to guides, to object/rotation centers etc. independent again - without requiring to have (cusp) nodes as active snap _targets_ as well. (…)»
<https://bugs.launchpad.net/inkscape/+bug/814457/comments/15>

@Diederik - would you mind to comment?

Related info:
«The distinction between snap sources and snap targets has been removed from the snap buttons (as of rev >= #10571). Now each group of snap buttons simply has a single toggle button, which turns all sources and targets in that group on/off. That's now all there is to it.»
<https://bugs.launchpad.net/inkscape/+bug/788178/comments/8>

As far as I understand, this change also causes that nodes (e.g. corners of rectangles) no longer are active snap sources in the select tool automatically, but have to be activated to allow to snap cusp (or smooth) nodes to other snap options (like grid or guides).

Among the side effects are:
- with the default template, objects no longer snap to grid or guides when dragged with the node tool
- a more fine-tuned node snapping is no longer possible in the select tool context (snap to path without snapping to nodes as well, snap cusp nodes to smooth nodes only, snap corners to midpoints of segments but not to other nodes, snap with nodes to grid only but not to other nodes, etc.) or requires additional steps (lots of zooming in/out, or moving objects to temporary layers to hide them if they interfere with or even prevent the intended snapping)
- …

sorry, typo:
- - with the default template, objects no longer snap to grid or guides when dragged with the node tool
+ - with the default template, objects no longer snap to grid or guides when dragged with the select tool

I see that there are different needs that require different implementations of snapping options:
 - ability to fine trim snapping with the possibility to select exactly snapping sources and targets which should be as much differentiated as possible (for example I'm thinking about also differentiating intersection between paths, guides, path and guide, etc... someone could ask for it);
 - ability to quickly change sources and targets so if you want to turn off node snapping you don't have to press plenty of buttons and then again to turn it back on; also, more flexibility = more buttons = more confusing GUI and less space on canvas.

One solution could be having one button for each snapping sources-targets "family" (what we have now, but maybe even less), then with a right click on each "family" button you open a dialog window fully-filled with checkboxes in which you can select, with regards to all other sources-targets (also in different families) what should snap to what. In this way you can have guides snapping to cusps but not to smooth nodes, but only if both the "nodes snap" and the "guides snap" buttons are pressed and the checkbox "snap to cusps" is selected under the "guides snapping table" dialog (no matter if the "snap to guides" checkbox under the "nodes snapping table" is selected or not).

Hence a single "on - off" button will control snapping super-fine tuned to the user needs for a whole category of snapping sources or targets.
If one user has very precise needs that seldom change, he could have all buttons always pressed and use their respective checkboxes only.
Otherwise, if someone else only needs "families", he could have all checkboxes always checked and quickly configure the snapping behavior using only buttons (and this could be the default option, very similar to what we have now).
Of course, between these two extreme cases there can be a wide variety of possible configurations.
The "snapping tables" should be accessible also from the document options: a combo box to select the "family" with the checkboxes table under it .

Ah, thanks very much for the comments. I see now that some of the snap-control buttons have changed in appearance and functionality. I think this is a change for the better, I remember how frustrating it could be previously to try and snap to a particular part of the moving object (for example, the center of a rectangle) if there was a guide nearby to the edge nodes and it would prefer to snap the edge of the rectangle instead of the center.

I was also previously unclear about how "source" and "target" snapping worked, and it seems like smart people are thinking about good ways to handle this. Feel free to remove this bug as it was just user confusion. Perhaps the new snapping interface could default to have the rules set to mimic the old inkscape snapping behavior to help ease the transition for users who are new to the new snapping interface?

Thanks much,
Matthew

@Luca: I' ve been thinking about this a bit, but this could be quite far reaching:
- Will it be possible to have both a granular settings and global settings, and still make things intuitive; how will these interact? What happens to the global toggles if one of the granular toggles is changed?
- Lot's of GUI code will have to be added, i.e. lot' s of new buttons and toggles. This is a pain.
- We currently have 23 different snap sources, and 38 different snap targets. Should we expose all of them?
- We will need to store the snap sources separately from the targets, which is not what we do now. Something has to be done there too, because it is getting ridculous to save 61 strings similar to "inkscape:snap-source-bbox-edge-midpoints", just for 61 boolean values. This is bloating the .svg files.

@Diederik:
>What happens to the global toggles if one of the granular toggles is changed?
I thought them to be completely independent: the global simply turns all off or enables those that are set. This doesn't prevent you changing the granular ones when the global is off (simply nothing will change until you turn it on).

>Lot's of GUI code will have to be added [...] This is a pain.
That's true, I know...

>We currently have 23 different snap sources, and 38 different snap targets. Should we expose all of them?
Gulp. This means 23*38=874 possible interactions to manage. I think I should have a look into the code to better understand: as a user I can't appreciate these numbers because now you can interact with only a few of them (really few compared to the internal numbers).
Anyway, the granularity approach asks for exposing all of them, but I think that it should be possible to logically merge some of them, to get lower numbers. And grouping them in families should make things even simpler (as now) for users that don't want to dive into internal details.

>We will need to store the snap sources separately from the targets
Sure, but not exactly. We should store for each source which targets it must snap to . It's a matrix, not a vector.
23 sources and 38 targets are a lot, but if we group sources into few groups, we'll end up with 874 boolean values but few buttons and in the dialog only the 38 targets would be needed.
In this scenario, we could have a "nodes" button in the toolbar opening a dialog with a combo box and 38 checkboxes (or less); in the combo we could select cusps, smooths and middles (sources), and this would populate the 38 "targets" checkboxes allowing granular selections; so: 1 button for 3 sources and their 114 combinations with the 38 possible targets.
Another button could be for "bounding boxes", having edges, corners, middle points and centers in the combo (1 button for 4 sources and their 152 combinations). And so on for the others (the next could be "paths" with snap to path, to intersections, tangent, perpendicular, etc...).
Maybe in the dialog there could be a "suspend all" button to temporarily turn off all the 38 targets for that particular source (not the entire group) without losing which is selected and which is not (greying them out?) so a particular source can be quickly turned off and on (just open the dialog, select it in the combo and hit the button).
Of course the dialog would be only one, the same for all sources. What changes for each are the values with which it's populated.
Under preferences, same dialog but the combo would have all 23 sources selectable.
Of course, before even starting an enumeration for sources and another for targets should be added: each interaction must have an (s,t) coordinate.
I can see other difficulties while writing (e.g. how to manage quickly turning on and off a particular target or even introducing target groups in a symmetrical manner under the global snap button), with their possible solutions; but before cracking the head on them we should decide if the approach is worth trying.

>[...]it is getting ridculous to save 61 strings[...]
Yes, and worse they would be much m...

On 02/20/2012 03:40 PM, LucaDC wrote:
> >What happens to the global toggles if one of the granular toggles is changed?
> I thought them to be completely independent: the global simply turns all off or enables those that are set. This doesn't prevent you changing the granular ones when the global is off (simply nothing will change until you turn it on).
That would be the most straightforward solution, but if for example one
button on the toolbar affects 2 independent toggles, then what do we do
with the status of the button after one of the 2 toggles has changed?

> >We currently have 23 different snap sources, and 38 different snap targets. Should we expose all of them?
> Gulp. This means 23*38=874 possible interactions to manage.
IMHO we should only consider to give each of the 23 sources an
individual toggle, and each of the 38 targets. Then, if you really want
to snap exclusively a gradient handle to a circle center, then only one
toggle in each of the source and target groups should be enabled.
Allowing to set each combination individually would be really too much.

> Why not saving a single string as binary values (like when you embed a picture)? Is that allowed by SVG? Many bits, few characters.
Yes, that's the way to go.

>what do we do with the status of the button after one of the 2 toggles has changed?
No, the button and the status of the two are independent: you can have A on and B off so if the button is pressed you'll have A and if the button is not you'll have none. If B is turned on the button doesn't change state. If neither A nor B are enabled, the button has no effect (everything is always disabled).

>MHO we should only consider to give each of the 23 sources an individual toggle, and each of the 38 targets.
Ok, this could be an option. But then I think you should provide to the user some configurable buttons so one can create it's own sets of snapping configurations. This could be an easy solution for both programmers and users. Maybe 3-4 buttons (sets) could be enough.

Sorry for taking a long time to respond, I've been a bit busy with other
things. Anyway, I'm not sure if I understood you correctly so let's make
our discussion a bit more concrete. For example, we now have a single
button that toggles snapping to guides. Lets call this the master
toggle. Under the hood however, it also toggles:
- snapping to intersections of guides
- snapping to origins of guides, and
- snapping perpendicularly to guides.
Let's call these slave toggles. Suppose that the master toggle is on,
and that the user goes to the document properties dialog and toggles one
of the slave toggles directly, for example the user turns off snapping
to the guide origins. The document properties dialog is being closed
afterwards, and only the snap toolbar can be seen. What is now the
status of the button, i.e. the master toggle? Is it on or is it off? If
you propose to leave it on, then what should happen if the user sets all
toggles to off?

When the user toggles one slave toggle, the master should not be affected and keep its previous state.
As you mentioned, there is a degenerate case when the master is on but no slave is selected. In this case toggling the master on or off would be useless. IMHO, this could be acceptable in a first stage of development because if the user toggles all slaves off, it's his choice and he should know what he has done (anyway better than not letting him turn all of them off). Of course, a more elaborate solution could be to turn off and gray out the master, to indicate that it has become useless (but still let right-click on it to open its slaves selection dialog; I suppose you don't like this right-click solution because you mentioned the properties dialog only: actually my idea is based on this quick access because without it, too few buttons would reduce usability a lot).

Anyway, I don't dislike the 3-4 user configurable snapping configurations buttons exposing the vector of all sources and targets. I think it's a good candidate to start trying to expose all of them and see if users like (and can take advantage of) a such detailed feature.

> When the user toggles one slave toggle, the master should not be affected and keep its previous state.
> As you mentioned, there is a degenerate case when the master is on but no slave is selected. In this case toggling the master on or off would be useless.

Yes, we could force the master to keep it's original state at any case. But we could also toggle it off as soon as all slaves have been turned off. If the state of the slaves varies, then toggling the master on or off could force all the slaves to take on the same state again. That seems natural to me. Anyway, I can just go ahead implementing this step by step and see where it leads us. Issues like this can be changed relatively easily if needed. Most work will be in changing the way the preferences are stored, and in how the slaves are represented in the GUI. Don't expect pop-up buttons for the slaves just yet, because that's tricky to implement GUI wise (I'm no GTK wizzard), and because it would require an icon for each slave (I'm not an artist either ;-)). That's why I preferred the document properties dialog, to just show a spreadsheet-like list all the master and slave buttons, each having a checkbox and a short descriptive text. But even that would be new to Inscape too. GUI-wise.