Sorry for not replying earlier, but I've been out hunting bugs ;-)
bulia byak wrote:
- "snap guides while dragging" option does not seem to work - no
snapping to grid, other guides or objects
This has been explained by Max and Gez, so I guess that has been cleared up. BTW, what has changed recently is that only the part of the guide near the cursor now snaps, not the full length of the guide.
I agree that's not good no to refer to the other tab in the tool tip ("'Snap to nodes' or 'snap to bounding box corners' must be enabled in the 'Snap' tab"), but I don't see any other clean or technically correct solution. Suppose that a user is using visual bounding boxes, then we cannot snap guides by default to nodes, as the guide would end up misaligned by half the stroke width. Things being slightly off is a big no-no IMO. So we only have the option to snap to bounding box corners by default, which is less useful. Besides, if the user at some point selects "Snap to nodes" in the other tab, then we should no longer snap to bounding box corners by default. That could be confusing, as we no longer implicitly snap to bounding boxes.
- Snap tab: for what snaps/nodes, the tooltip lists what they may snap
to, but here, more important is another question - what are nodes? only path nodes, or special points in shapes? what about gradient handles and text baselines - are they "nodes" too? I think this needs to be clarified right here. What they snap to is clear from the rest of options below.
- same about what snaps/bboxes: what they snap _to_ is not important
here, it's clear from the rest of options anyway, but that it only works in selector is important. Oops, no, wait; I just noticed that bboxes don't snap to paths/nodes, and nodes don't snap to bboxes. In that case this should be mentioned in the tooltips of course (e.g. "snap to bounding boxes of other objects but not to their paths" and vice versa).
Done! (see rev. #17045). Please let me know if it still can be improved.
- "Snap at specified distance" is misleading; better something like
"Snaps only when closer than:"
Done. I hope that Ted agrees, as "Snap at specified distance" was his suggestion... Anyway, both are better than the "Always snap" we had before. It used to enable the slide when it was unchecked.
- "Miscellaneous" is a bad label
Agreed. Has been changed into "Snapping to special nodes".
- doesn't this option belong in "what
snaps"? Maybe as a suboption under "nodes" - am I right in assuming the rotation center is considered a "node" for snapping?
Yes you are, and at one point it was indeed a sub-option of "nodes". It was adding to the clutter though, which would become really problematic when I add more special nodes in the future (I was thinking of midpoints, real object centers, but maybe also make gradient handles, text base points etc. optional)
- in any case, "Also snap the rotation center of an object when
snapping nodes or guides" - why are guides mentioned here? how can I snap rotation center of a guide?
It should have read "_to_ guides". Has been changed.
- finally, I think we should rearrange the tabs again :) Tooltips that
include "see previous tab" are a sign that something is very awkward here. As I understand the options, I would propose dividing them as follows:
first tab: "Snapping"
- enable snapping
- what snaps, including the rotation center option
second tab: "Snap targets"
- snap to guides
- snap to grids
- snap to objects
- snap to intersections
(in this order!)
What do you think?
Well, I see the advantages of this, but it also has its downsides: - Currently, we're greying out some checkboxes depending on whether "What snaps: nodes" or "What snaps: bbox corners" is selected. This helps the user in understanding that bbox corners only snap to bboxes, and nodes only to paths. This is not possible when spreading the checkboxes over different tabs - Some options are related to both the snap "source" and the snap target, e.g. the rotation center option: it can be snapped from and to. Were should this option go? Duplicate it? Or put it in a third tab? Likely it will end up in the first tab (if only because we have space left there), but we will not be able to maintain a strict separation between the snapping sources and targets. Similarly, this issue will occur for the future midpoints, optional snapping of gradients or text base points, etc. - The snapping of guides option will probably stay in the guide tab; its tooltip will therefore always be referring to another tab, and will always be awkward.
We currently have all the main snapping options in the first tab, with some specialized controls in the second tab. That distinction makes sense IMO. In your proposal we have all snapping sources in the first tab, and the snapping targets in the second. That would also make sense.
I don't think the differences are very big (and I can be convinced either way), but I do know which option requires the least effort ;-)
Diederik