On Jan 13, 2008 3:39 PM, Diederik van Lierop <mail@...1689...> wrote:
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.
Well, I just tried, and for me guideline does not snap to a rect, after i ticked "snap guides while dragging" and both snap to paths and snap to nodes. And dragging it with mouse over the rect. What am I doing wrong?
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.
So why not snap to bboxes by default? If the user wants nodes, he will likely use geometric bbox anyway, and it will work as expected.
no-no IMO. So we only have the option to snap to bounding box corners by default, which is less useful.
Maybe a little less useful, but a lot less confusing.
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.
Why, we could just always snap guidelines to bboxes, simply regardless of what other stuff snaps to. I think it will be a little saner. Though anyway, I'm not the user of this feature, so I will leave it to your judgment.
- "Miscellaneous" is a bad label
Agreed. Has been changed into "Snapping to special nodes".
Wait a minute, I'm confused again :) Is this what one snaps or what one snaps TO? a snappable point or snap destination? I thought the former.
- 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)
And here you seem to assume it's indeed a snappable point, not destination.
- 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
Yes, I see your point. But, we could make it even more obvious by adding explicit labels to them, for example "Snap to paths (nodes snapping only)" and "snap to bbox edges (bbox snapping only)". Long but comprehensive (and leave the graying out too, of course).
- 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?
Aha. See, I was confused about exactly this point above :)
I think you should still list it as a suboption under "nodes" in "what snaps", if only because it comes first. Then, in the tooltip of "nodes" under "snap to nodes", mention that the nodes are defined here as all those suboptions in the "snappables" tab. By the way, if we divide the stuff as I proposed, there will be a lot of room there for more nodes suboptions.
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.
Well, you made it non-strict yourself, by making an option that affects both :) I'm just thinking how to best deal with this.
Similarly, this issue will occur for the future midpoints, optional snapping of gradients or text base points, etc.
See above, I think just reusing the definition of "nodes" from snappables tab on the snap targets tab is a clean enough solution.
- 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.
See above, I don't think we need to refer to anything for guide snapping, just always snap it to bbox
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.
I think the main/specialized distinction is not very helpful really.