Hi guys, overall you did a terrific job on these features, but I have several comments/questions on the UI:
Doc prefs:
- "snap guides while dragging" option does not seem to work - no snapping to grid, other guides or objects
- can we disable the remove button when there's nothing to remove in Grids?
- can we give grid names that at least reflect their type, e.g. AxGrid2222 or RectGrid2222 instead of grid2222?
- why two checkboxes, "enabled" and "visible"? what's the difference? It's not clear. I propose to rename them to "Snapping enabled" and "Grid visible". Also if I uncheck "enabled", visible does not work - why? if that's intentional, please just gray out the rest of the grid options when "enabled" is unchecked.
- why there's no option for hex grid to show dots?
- 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).
- "Snap at specified distance" is misleading; better something like "Snaps only when closer than:"
- "Miscellaneous" is a bad label - 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?
- 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?
- 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?
bulia byak wrote:
Hi guys, overall you did a terrific job on these features,
Definitely true!
- "snap guides while dragging" option does not seem to work - no
snapping to grid, other guides or objects
Yes, it does. At first, I was thinking the same - until I read the tooltip. It explains very well how to make this option work. However, IMO the problem is that the user normally expects a different behaviour and thus doesn't bother to read the tooltip.
I personally find it somewhat unintuitive that guides don't snap automatically when "Snap guides while dragging" is checked. I wonder if it would make sense to snap guides unconditionally in this case (or at least to nodes by default), without the need to specify the precise snapping behaviour in the "Snaps" tab (we could provide a keyboard modifier to temporarily avoid snapping while dragging guides).
Otherwise, we definitely need to point the user more explicitly to the "Snaps" tab - either by adding a comment (outside the tooltip) in the "Guides" tab or by moving the said option into the "Snaps" tab, too (i.e., under the section "What snaps" add a checkbox for guidelines).
- can we disable the remove button when there's nothing to remove in Grids?
This comment I don't understand. I only see this button when a grid is present in the document, and in this case it successfully removes the grid.
- why two checkboxes, "enabled" and "visible"? what's the difference?
It's not clear. I propose to rename them to "Snapping enabled" and "Grid visible". Also if I uncheck "enabled", visible does not work - why? if that's intentional, please just gray out the rest of the grid options when "enabled" is unchecked.
Another related issue: Is the '#' shortcut supposed to only toggle visibility or to also enable/disable grids? Currently it does both (which is what I would expect, so I'd leave it that way), but
1) it doesn't update the corresponding checkboxes in the "Grids" tab 2) this behaviour seems to contradict the fact that the shortcut is listed in the "View" menu (which suggests that it only toggles visibility)
Max
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: donderdag 10 januari 2008 4:04 To: Inkscape Devel List; Diederik van Lierop; Engelen, J.B.C. (Johan) Subject: grids, guides, snapping UI
Hi guys, overall you did a terrific job on these features, but I have several comments/questions on the UI:
Doc prefs:
- "snap guides while dragging" option does not seem to work -
no snapping to grid, other guides or objects
- can we disable the remove button when there's nothing to
remove in Grids?
Tried it, but the code that is there now does not work for some reason.
- can we give grid names that at least reflect their type, e.g.
AxGrid2222 or RectGrid2222 instead of grid2222?
Inkscape assigns an id to the grids automatically, I do not know how to hack into this (I just add a inkscape:grid leaf to the XML, and inkscape automatically generates grid****).
- why two checkboxes, "enabled" and "visible"? what's the difference?
It's not clear. I propose to rename them to "Snapping enabled" and "Grid visible". Also if I uncheck "enabled", visible does not work - why? if that's intentional, please just gray out the rest of the grid options when "enabled" is unchecked.
It is working as intended. "enabled" used to be "snapping enabled" and act correspondingly, however I found it annoying. Will try *just* graying it out, but past experience tells me the UI does not listen very carefully to my wishes...
- why there's no option for hex grid to show dots?
Please implement it if you want it :P
-johan
On Jan 10, 2008 2:19 PM, <J.B.C.Engelen@...1578...> wrote:
-----Original Message----- From: bulia byak [mailto:buliabyak@...400...] Sent: donderdag 10 januari 2008 4:04 To: Inkscape Devel List; Diederik van Lierop; Engelen, J.B.C. (Johan) Subject: grids, guides, snapping UI
Hi guys, overall you did a terrific job on these features, but I have several comments/questions on the UI:
Doc prefs:
- "snap guides while dragging" option does not seem to work -
no snapping to grid, other guides or objects
- can we disable the remove button when there's nothing to
remove in Grids?
Tried it, but the code that is there now does not work for some reason.
- can we give grid names that at least reflect their type, e.g.
AxGrid2222 or RectGrid2222 instead of grid2222?
Inkscape assigns an id to the grids automatically, I do not know how to hack into this (I just add a inkscape:grid leaf to the XML, and inkscape automatically generates grid****).
- why two checkboxes, "enabled" and "visible"? what's the difference?
It's not clear. I propose to rename them to "Snapping enabled" and "Grid visible". Also if I uncheck "enabled", visible does not work - why? if that's intentional, please just gray out the rest of the grid options when "enabled" is unchecked.
It is working as intended. "enabled" used to be "snapping enabled" and act correspondingly, however I found it annoying. Will try *just* graying it out, but past experience tells me the UI does not listen very carefully to my wishes...
- why there's no option for hex grid to show dots?
Please implement it if you want it :P
-johan
On Jan 10, 2008 3:19 PM, <J.B.C.Engelen@...1578...> wrote:
- can we disable the remove button when there's nothing to
remove in Grids?
Tried it, but the code that is there now does not work for some reason.
Incredibly, you are right: I tried to hide it but also failed :( That's GTK for you.
Anyway, for now I at least grayed it out when no grids are defined. That works for some reason.
bulia byak schrieb:
On Jan 10, 2008 3:19 PM, <J.B.C.Engelen@...1578...> wrote:
- can we disable the remove button when there's nothing to
remove in Grids?
Tried it, but the code that is there now does not work for some reason.
Incredibly, you are right: I tried to hide it but also failed :( That's GTK for you.
Strangely, when using hide()/show() instead of set_sensitive(), the button is in fact correctly hidden, _but only after a grid is created and removed again_. For example, try the following with Johan's old code (i.e., before revision 17189):
- start Inkscape and open Document Preferences - press "New" to create a new grid - press "Remove" to delete it again
As soon as the grid is deleted, the "Remove" button becomes invisible as intended. Also, when creating and deleting new grids or using undo/redo, hiding and showing the button works as it should. It's only the very first hide() that fails. Any ideas what it could be that causes this? Is this a GTK bug? After all, the call to hide() happens at all times. Or must anything be initialized before hide() can work? (Doesn't sound very likely to me but then I'm far from being a GTK expert.)
Max
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
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.
participants (4)
-
unknown＠example.com -
bulia byak -
Diederik van Lierop -
Maximilian Albert