What are your thoughts on this for the next version? I often have to drag a node a little bit to connect it to another node (to close the contour). The magnetic guidelines forces me to put the node where I don’t want it. In disabling it the magnetic guideline with ctrl, it disables the desired effect of closing the contour.
An old paradigm that I think works well in many apps is to be able to freely move a node and hold down shift to constrain its movement.
The magnetic guidelines in its current version does the opposite, ie. it constrains by default, and in disabling the unwanted constraint, it disables a constraint elsewhere. Would it be better to have the shift key act as this magnetic guideline?
I wonder why your response from the 30 October isn’t included in the conversation thread from the 28th.
Since you’re bringing up shift, I’ll point out: shift has been used for years in several drawing apps as a way to constrain displacement of points. I invite you to open Illustrator, draw a point, and then with the shift key drag the point. Its movement is constrained for elongating horizontal/vertical/diagonal lines; a constraint that happens only when you tell it to. Same behaviour in FontLab. Glyph’s magnetic guides act instead like Illustrator’s Smart Guides. For drawing short lines, these type of guides are often obstructive.
Is there a preference to turn OFF Glyph’s magnetic guides, like you can Illustrator’s Smart Guides?
Shift has a different function than the automatic guidelines, also in the programs you mention. Shift is, as you point out, for constraining the movement of the selection, but not constraining to a line’s actual angle. You would only be able to elongate exactly horizontal or vertical lines with it in Glyphs. So, Shift cannot replace the automatic guidelines.
Where is your screencast? Here is mine: http://quick.as/Z1A8fJ3y
Before I close the path, I am holding down Ctrl (indicated by the blue circle) to disable the automatic guideline. In the end, you see that the path is closed.
Maybe what is difficult is that, because snapping is disabled, you have to be more precise when dragging one node on top of the other. Zooming in a little helps.
For a while I asked why is wasn’t possible to use shift to move diagonal. At the time it was about cutting, but still the idea of not being able to use shift for diagonals and to use a workaround is to me a little strange.
@mekkablue answered me that in type design one seldom find a 45 degree angle. This might be the case, but I use it quite often in my work. A lot of other programms (Illy, FL. FOG etc.) have that function and many people are used to it.
I also once had a project where 45° played a role, and that was a pixel font and I simply set a coarser grid to achieve the point snapping that would create 45° angles.
In all other projects I have been involved with, different angles were more important. That is why I argue that (in the realm of type design at least) 45° in Shift-constrainment is in the way more often than it helps. Horizontal, vertical, and perhaps the italic angle, yes, but other constraints make no sense in a font editor.
Out of curiosity: Can you show me those fonts with 45° angles?
Sometimes, if you drag the node from very close, there are several competing spappers. In this case, drag the node somewhere else, release the mouse and drag it again. Or use the arrow keys to move the node.