Hi all, Am I the only one who finds it annoying that I have to specifically enable snapping *to* cusp nodes, in order for them to snap to the grid? In other words: I don't like the recent changes to the snapping UI. ;-)
Suggestion: "snap nodes, paths, and handles" enables snapping OF all those things; and is completely unrelated for snapping TO those thingies. Then the buttons below that are decoupled from it, and mean snapping TO the things their tooltip says.
Cheers, Johan
On Mon, 2012-04-16 at 12:53 +0200, Johan Engelen wrote:
Hi all, Am I the only one who finds it annoying that I have to specifically enable snapping *to* cusp nodes, in order for them to snap to the grid? In other words: I don't like the recent changes to the snapping UI. ;-)
Suggestion: "snap nodes, paths, and handles" enables snapping OF all those things; and is completely unrelated for snapping TO those thingies. Then the buttons below that are decoupled from it, and mean snapping TO the things their tooltip says.
Cheers, Johan
+1
On 16/04/2012 12:53, Johan Engelen wrote:
Am I the only one who finds it annoying that I have to specifically enable snapping *to* cusp nodes, in order for them to snap to the grid? In other words: I don't like the recent changes to the snapping UI. ;-)
Suggestion: "snap nodes, paths, and handles" enables snapping OF all those things; and is completely unrelated for snapping TO those thingies. Then the buttons below that are decoupled from it, and mean snapping TO the things their tooltip says.
Also discussed in
Bug #927898 https://bugs.launchpad.net/inkscape/+bug/927898 "snap to guides no longer working for path nodes or rotation origin"
~suv
Johan, if I correctly understood, you're more interested in specifying what to snap to while you're not in specifying what should snap. I'm not. If you want to group sources, you should also agree in grouping targets, so: 1 button to snap "nodes, paths, handles, ..." to whatever and 1 button to snap whatever to "nodes, paths, handles, ...". That would be fair :) Every other solution would introduce differences that not everybody could find useful and agree on. That's why I'd propose a less differentiated main interface (1 button per group both as target and source) and a more detailed configurable one, to suit everybody needs (we were speaking about few buttons associated with full-free configurability, with all possible options available). Would this make you happier with the UI? ;) I'm glad that someone else decided to express about this topic. Every comment is much appreciated and surely will help in improving the interface. Regards Luca
-- View this message in context: http://inkscape.13.n6.nabble.com/Snapping-tp4886159p4886657.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 16-4-2012 15:46, LucaDC wrote:
Johan, if I correctly understood, you're more interested in specifying what to snap to while you're not in specifying what should snap. I'm not. If you want to group sources, you should also agree in grouping targets, so: 1 button to snap "nodes, paths, handles, ..." to whatever and 1 button to snap whatever to "nodes, paths, handles, ...". That would be fair :) Every other solution would introduce differences that not everybody could find useful and agree on. That's why I'd propose a less differentiated main interface (1 button per group both as target and source) and a more detailed configurable one, to suit everybody needs (we were speaking about few buttons associated with full-free configurability, with all possible options available). Would this make you happier with the UI? ;)
I think that snapping is inherently asymmetric. While you have control over what will snap (by putting the mouse close to it), you have no quick control over what it will snap to. Enabling all snap sources is not very much different from enabling a few of them. Enable all snap targets will be uncontrollable. That's why I am in favor of an asymmetric interface. Example: to me it makes no sense to disable snapping of knots, because you can already quickly disable snapping while moving a knot by pressing shift. Snapping *to* knots is a different matter, and hence a toggle button :)
Cheers, Johan
On 04/16/2012 07:54 PM, Johan Engelen wrote:
On 16-4-2012 15:46, LucaDC wrote:
Johan, if I correctly understood, you're more interested in specifying what to snap to while you're not in specifying what should snap. I'm not. If you want to group sources, you should also agree in grouping targets, so: 1 button to snap "nodes, paths, handles, ..." to whatever and 1 button to snap whatever to "nodes, paths, handles, ...". That would be fair :) Every other solution would introduce differences that not everybody could find useful and agree on. That's why I'd propose a less differentiated main interface (1 button per group both as target and source) and a more detailed configurable one, to suit everybody needs (we were speaking about few buttons associated with full-free configurability, with all possible options available). Would this make you happier with the UI? ;)
I think that snapping is inherently asymmetric. While you have control over what will snap (by putting the mouse close to it), you have no quick control over what it will snap to. Enabling all snap sources is not very much different from enabling a few of them. Enable all snap targets will be uncontrollable. That's why I am in favor of an asymmetric interface. Example: to me it makes no sense to disable snapping of knots, because you can already quickly disable snapping while moving a knot by pressing shift. Snapping *to* knots is a different matter, and hence a toggle button :)
Cheers, Johan
While at all this, wouldn't it be nice to have, at least, an option to make snapping preferences inkscape specific, rather than document specific? I've lost hours and hours on clicking at not-that-small amount buttons.
Vlada
On 04/16/2012 08:41 PM, Vladimir Savic wrote:
While at all this, wouldn't it be nice to have, at least, an option to make snapping preferences inkscape specific, rather than document specific? I've lost hours and hours on clicking at not-that-small amount buttons.
If the majority of users feels the same about this issue, then I'm perfectly happy with that and will change that. Personally however, I prefer things the way they currently are. I believe that some snap settings are user-specific (e.g. how much snap-delay one prefers, or whether one only wants to snap the snap source closest to the pointer), while other settings are more document-specific (In one document one might only use bounding-box or path snapping, whereas in another document one might only use grid or guide snapping).
Time for a poll maybe? In favor: Vladimir Against: Diederik
If you want to vote somewhat anonymously, then send me a private message ;-)
Please speak up!
Regards,
Diederik
On Mon, Apr 16, 2012 at 2:03 PM, Diederik van Lierop <mail@...1689...> wrote:
On 04/16/2012 08:41 PM, Vladimir Savic wrote:
While at all this, wouldn't it be nice to have, at least, an option to make snapping preferences inkscape specific, rather than document specific? I've lost hours and hours on clicking at not-that-small amount buttons.
If the majority of users feels the same about this issue, then I'm perfectly happy with that and will change that. Personally however, I prefer things the way they currently are. I believe that some snap settings are user-specific (e.g. how much snap-delay one prefers, or whether one only wants to snap the snap source closest to the pointer), while other settings are more document-specific (In one document one might only use bounding-box or path snapping, whereas in another document one might only use grid or guide snapping).
Time for a poll maybe? In favor: Vladimir Against: Diederik
My vote is compromise. :) What about having a preference for storing snapping options globally vs the document. It could then still remain default to do per document settings, but for people that want the settings to persist between sessions, they can change that.
Cheers, Josh
On 16-4-2012 23:03, Diederik van Lierop wrote:
On 04/16/2012 08:41 PM, Vladimir Savic wrote:
While at all this, wouldn't it be nice to have, at least, an option to make snapping preferences inkscape specific, rather than document specific? I've lost hours and hours on clicking at not-that-small amount buttons.
If the majority of users feels the same about this issue, then I'm perfectly happy with that and will change that. Personally however, I prefer things the way they currently are. I believe that some snap settings are user-specific (e.g. how much snap-delay one prefers, or whether one only wants to snap the snap source closest to the pointer), while other settings are more document-specific (In one document one might only use bounding-box or path snapping, whereas in another document one might only use grid or guide snapping).
Time for a poll maybe? In favor: Vladimir Against: Diederik
Probably what would fix Vlada's and my annoyance here, is that Vlada and I should save our snap preferences to default.svg...? I think it is ok to have them per document basis. As long as the default new document template is somewhat what I expect. Right, Vlada?
Cheers, Johan
On 04/17/2012 12:40 AM, Johan Engelen wrote:
On 16-4-2012 23:03, Diederik van Lierop wrote:
On 04/16/2012 08:41 PM, Vladimir Savic wrote:
While at all this, wouldn't it be nice to have, at least, an option to make snapping preferences inkscape specific, rather than document specific? I've lost hours and hours on clicking at not-that-small amount buttons.
If the majority of users feels the same about this issue, then I'm perfectly happy with that and will change that. Personally however, I prefer things the way they currently are. I believe that some snap settings are user-specific (e.g. how much snap-delay one prefers, or whether one only wants to snap the snap source closest to the pointer), while other settings are more document-specific (In one document one might only use bounding-box or path snapping, whereas in another document one might only use grid or guide snapping).
Time for a poll maybe? In favor: Vladimir Against: Diederik
Probably what would fix Vlada's and my annoyance here, is that Vlada and I should save our snap preferences to default.svg...? I think it is ok to have them per document basis. As long as the default new document template is somewhat what I expect. Right, Vlada?
Cheers, Johan
Hmmm... Your suggestion is more reasonable than my approach. Thanks for reminding me that default.svg is an option. :) Too bad it's not that obvious. Had to browse through inkscape.org in order to find where should I put that file in. ;)
Vlada
On Mon, Apr 16, 2012 at 3:55 PM, Vladimir Savic <vladimir.firefly.savic@...400...> wrote:
On 04/17/2012 12:40 AM, Johan Engelen wrote:
Probably what would fix Vlada's and my annoyance here, is that Vlada and I should save our snap preferences to default.svg...? I think it is ok to have them per document basis. As long as the default new document template is somewhat what I expect. Right, Vlada?
Hmmm... Your suggestion is more reasonable than my approach. Thanks for reminding me that default.svg is an option. :) Too bad it's not that obvious. Had to browse through inkscape.org in order to find where should I put that file in. ;)
It's very much a viable solution. But I do think if we're going to recommend saving a customized default.svg, we should really add an option to more easily do so (basically, make the user avoid having need to know where it's located). I think we have enough reasons besides snapping options alone to do so (document size, guides, etc).
Cheers, Josh
2012/4/16 Josh Andler <scislac@...400...>
On Mon, Apr 16, 2012 at 3:55 PM, Vladimir Savic <vladimir.firefly.savic@...400...> wrote:
On 04/17/2012 12:40 AM, Johan Engelen wrote:
Probably what would fix Vlada's and my annoyance here, is that Vlada and I should save our snap preferences to default.svg...? I think it is ok to have them per document basis. As long as the default new document template is somewhat what I expect. Right, Vlada?
Hmmm... Your suggestion is more reasonable than my approach. Thanks for reminding me that default.svg is an option. :) Too bad it's not that obvious. Had to browse through inkscape.org in order to find where should I put that file in. ;)
It's very much a viable solution. But I do think if we're going to recommend saving a customized default.svg, we should really add an option to more easily do so (basically, make the user avoid having need to know where it's located). I think we have enough reasons besides snapping options alone to do so (document size, guides, etc).
Some time ago I thought that per-document snapping wasn't a good idea, but after getting used to create my own templates with my own preferences, I have to admit that I changed my mind, and I find being able to store the snapping settings with my files very useful.
It's true that customization of default templates is somewhat hidden for the casual user (and add an extra hurdle with localized versions) so it would be really good if Inkscape provides a more visible way to personalize the default template.
Anyway, maybe it's a good moment to also revisit the snapping settings which Inkscape ships as default. Personally I think that enabling snapping to cusp nodes, turning on "Only snap the node closest to pointer" and tweaking the snapping delay a little would be a great help for new users who find inkscape snapping maybe a tad difficult to tame.
Cheers, Gez.
Hi all,
Good to see that so many people still care about snapping :-)
On 04/16/2012 07:54 PM, Johan Engelen wrote:
I think that snapping is inherently asymmetric. While you have control over what will snap (by putting the mouse close to it),
.. and by using (shift-)tab to cycle through all snap sources ... BTW, please remind that not everyone is using the "only use snap source closest to the pointer" option. Let alone that they have touched the slider to set the weighing for that option.
you have no quick control over what it will snap to.
I don't agree with that. You can control what it will snap too, buy moving your mouse towards your desired snap target. That's the whole idea of snapping ;-). If this doesn' t work for you, then you might have too many snap targets enabled.
I have learned over time though that everybody uses the snapping mechanisms in a different way. So my opinion, is just that: an opinion.
Would it be useful if I add (shift-)ctrl-tab cycling for the snap targets? You see, I'm an engineer: I try to solve problems by adding even more features ;-)
Enabling all snap sources is not very much different from enabling a few of them. Enable all snap targets will be uncontrollable. That's why I am in favor of an asymmetric interface.
Well, I have one technical argument against that: snapping can challenge even your brand new core i7. The number of possible combinations of sources and targets can grow quickly, for example when using a complex document (typically a large group of tiny objects from an imported pdf or dxf). In such a case it helps to disable as many snap targets and sources as possible. However, I also agree that this probably doesn't happen too often for our average user, while a cumbersome UI is something one simply cannot escape.
Example: to me it makes no sense to disable snapping of knots
It does! I tend to only use cusp nodes as a snap source, and not smooth nodes. Therefore I want to eliminate smooth nodes as a snap source, but if I hard code that then you will not be happy because you want to consider all as snap sources. They only way out of this is to make things configurable.
, because you can already quickly disable snapping while moving a knot by pressing shift.
Problem: press-shift-to-disable-snapping isn't implemented in all tools. That's my personal annoyance with Inkscape (more general: inconsistency of modifier keys).
You see, I don't mind changing the UI or snapping code (otherwise I wouldn't still be working on this after five years). It's hard however to make everyone perfectly happy.
As a side note: these are the things that are still on my list (among others which I forgot): - store the snapping preferences differently in the document (the current list of strings is becoming a little bit too verbose, e.g. inkscape:snap-bbox-edge-midpoints="true"). I'm thinking of using some hexadecimal encoding strings instead. Nobody edits these setting using a text editor, right? If you do this on a regular basis then please speak up now :-) - add more configurability, as requested for example by LucaDC. This means that you will be able to control each snap source and target individually (currently you can't. Much has been hidden already. We already have about 20 sources and 40 targets, but you won't have noticed because of the implicit snapping logic). But this maximum configurability will be slightly tucked away in the UI, to not bother other users too much which this. - Add tangential/perpendicular snapping when rotating selections
Regards,
Diederik
TL;DNR: please always snap nodes in the node tool.
On 16-4-2012 22:55, Diederik van Lierop wrote:
Hi all,
Good to see that so many people still care about snapping :-)
Note that at the moment I care most about "fixing" the snapping in the node tool.
On 04/16/2012 07:54 PM, Johan Engelen wrote:
I think that snapping is inherently asymmetric. While you have control over what will snap (by putting the mouse close to it),
.. and by using (shift-)tab to cycle through all snap sources ... BTW, please remind that not everyone is using the "only use snap source closest to the pointer" option. Let alone that they have touched the slider to set the weighing for that option.
I don't use "only use snap source closest to the pointer". The weighting is set to 0.5. I guess that is default. And seems to work fine for me. It feels like Inkscape chooses a point close to my mouse. (in the node tool, none of this matters)
you have no quick control over what it will snap to.
I don't agree with that. You can control what it will snap too, by moving your mouse towards your desired snap target. That's the whole idea of snapping ;-). If this doesn't work for you, then you might have too many snap targets enabled.
Ok, I was a bit too quick in typing that :) sorry. Still, I think you have better control over snap source, because you have only one object to worry about, instead of grid snap targets and all other paths...
I have learned over time though that everybody uses the snapping mechanisms in a different way. So my opinion, is just that: an opinion.
granted, mine is too only that :)
Would it be useful if I add (shift-)ctrl-tab cycling for the snap targets? You see, I'm an engineer: I try to solve problems by adding even more features ;-)
Hard to discover, but useful for 'power users'? I was not aware there already is snap source cycling. Have to read about how that works.
Enabling all snap sources is not very much different from enabling a few of them. Enable all snap targets will be uncontrollable. That's why I am in favor of an asymmetric interface.
Well, I have one technical argument against that: snapping can challenge even your brand new core i7. The number of possible combinations of sources and targets can grow quickly, for example when using a complex document (typically a large group of tiny objects from an imported pdf or dxf). In such a case it helps to disable as many snap targets and sources as possible. However, I also agree that this probably doesn't happen too often for our average user, while a cumbersome UI is something one simply cannot escape.
I guess this is in favor of always snapping nodes in the node tool, right? Because now one would have to add them as snap targets too. For the users I know, documents are never really complex. First time users also don't create very complicated documents. Still, I think the number of "always on" snap *sources* can be quite small: node tool: *always* snap nodes, no reason not to (shift) select tool: always snap bbox, (shift disables). I agree it is not a good idea to always snap path nodes in the select tool. shape tools: always snap, because there is only one snap source ever, right? (and shift disables)
(Related issue: I think the default snap delay should be zero (or maybe it is now?). The delay looked like a bug to a couple of new users I talked into using Inkscape :) (I don't know any program either that has such a (noticeable) delay). I am sure it is a nice feature, but I feel it is a feature that one has to knowingly set to non-zero.)
Example: to me it makes no sense to disable snapping of knots
It does! I tend to only use cusp nodes as a snap source, and not smooth nodes. Therefore I want to eliminate smooth nodes as a snap source, but if I hard code that then you will not be happy because you want to consider all as snap sources. They only way out of this is to make things configurable.
, because you can already quickly disable snapping while moving a knot by pressing shift.
Problem: press-shift-to-disable-snapping isn't implemented in all tools. That's my personal annoyance with Inkscape (more general: inconsistency of modifier keys).
So we should fix that, instead of creating some strange workaround ! In the node tool, it seems to work fine with shift so... let's please always snap those nodes? In tools where it doesn't work, I guess the "check_for_toggle_button" should be replaced with "! check_for_shift" ?
You see, I don't mind changing the UI or snapping code (otherwise I wouldn't still be working on this after five years). It's hard however to make everyone perfectly happy.
I don't think "always snapping node-tool knots" will make anybody unhappy :) If so, tell them about "shift". It is very strange to see the create path tool snap to the grid, and then the node tool not. It confused me and I started looking for a bug! (then after a while I tried turning on all snap buttons and then it worked)
Hope I am not upsetting you Diederik, it's all in good spirit. The new snapping stuff is wonderful. But the UI is such that I cannot use it! ;) I find it very unintuitive that I should look for snap options in the document properties dialog! The perp and tang snapping is great, but is way too much effort to look it up in the properties dialog and click it, do something, then unclick it, close dialog.
We should have a IRC/Jabber meeting about all this!
:-) Johan
On 04/17/2012 12:34 AM, Johan Engelen wrote:
On 16-4-2012 22:55, Diederik van Lierop wrote:
Would it be useful if I add (shift-)ctrl-tab cycling for the snap targets? You see, I'm an engineer: I try to solve problems by adding even more features ;-)
Hard to discover, but useful for 'power users'? I was not aware there already is snap source cycling. Have to read about how that works.
I don't think you can easily find some documentation about this feature yet ;-). So instead of asking you to read the code, I will give you a short tutorial:
Enable snap-closest-node-only in the preferences, make sure some snap types are enabled (e.g. snap-cusp-nodes), and drag an object using the selector tool. Now the snap source should light up while dragging. If there's more than one snap source that is being dragged, then pressing shift will select the next closest snap source. Shift-tab will reverse.
Diederik
I'd like to subscribe everything Diederik wrote. You see, we agree too much so it's better not to leave us alone in deciding new features... ;) In particular, I'd like to reinforce some of his considerations: - my outdated PC (Pentium IV) still behaves very well with all applications I use (I can't game at work ;), but grasps a bit with Inkscape; I can't live with all snapping options turned on because I either wait for snapping or work... - about controlling what to snap, try snapping a thin and empty circle's center... and what if you need to snap a similar object (thin and void)'s center that has thousands nodes all around? Maybe snapping the center to the grid (!) - for the users I know (me :), drawings can get _very_ complex in terms of objects and nodes count; the possibility of disabling unneeded snapping sources is a need for me, not a wish; - personally I don't like a lot the idea of having different snapping behaviors when I switch tool: if I enabled or not node snapping, I expect it being the same with all tools; and, by the way, why shouldn't it? - I never use bounding box snapping, I always keep it disabled because it always get into the way when I want to snap something else; - the reason for not relying on pressing shift is that if you seldom need some snapping why should you have to press it all other (i.e. most) times?
I don't think "always snapping node-tool knots" will make anybody unhappy
Me : ) And not because I never use it (I almost always have node snapping turned on) but because I don't like the idea of deciding what users need without asking them. And this approach could eventually turn against my use cases on other features.
I agree on the default.svg considerations. I spent a bit of time at the beginning to understand how to configure Inkscape so it starts with options that make sense to me (e.g. units set to mm). Now it turns out it's much powerful because you can start from a known configuration and then save relevant options on each document (I often have them different on different files). Sure it should be made more user friendly. A menu option opening the current default.svg file (or maybe also others, e.g. the default for the currently selected language) could be enough: you open the file (you don't have to know where it is), you change options, save and close it. Done.
Luca
-- View this message in context: http://inkscape.13.n6.nabble.com/Snapping-tp4886159p4889781.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
---- LucaDC <dicappello@...2144...> wrote:
I don't think "always snapping node-tool knots" will make anybody unhappy
Me : ) And not because I never use it (I almost always have node snapping turned on) but because I don't like the idea of deciding what users need without asking them. And this approach could eventually turn against my use cases on other features.
Before 0.49, the node tool always snapped. You don't ask users for functionality that is just logic. Do we ask users whether they want a save entry on the file menu? ;-) But go ahead and ask (and annoy) users, I am very sure 120% will say, yes snap the thing! now! :P Really, what is the use of the shift button in the node tool or the global snap disable button otherwise?
Cheers, Johan
Johan Engelen-4 wrote
Before 0.49, the node tool always snapped.
Sorry, I think there is a misunderstood on what we are speaking about. I can't understand what you mean with this. I'm talking about the possibility of enabling and disabling snapping. I don't want to have to turn global snap off to have nodes not snapping, I want to control what nodes do with a button called "node snapping". That's logic for me.
Johan Engelen-4 wrote
You don't ask users for functionality that is just logic.
Sure, provided we all agree that it is logic. :) And if we don't, probably it's worth asking.
Johan Engelen-4 wrote
Really, what is the use of the shift button in the node tool or the global snap disable button otherwise?
The shift temporarily disables something that has been enabled. If you didn't enable anything, it does nothing. The global snap is a quick turn-all-off. It's not intended for turning off something that can't be turned off otherwise (why forcing a full snap off? What if I need disabling something that can't be disabled in a different way but still keep some other sort of snapping?).
Your argumentations sound so strange to me that I think I'm not understanding correctly what you mean. If you feel that mine are obvious, so I'm right. Sorry, be patient.
-- View this message in context: http://inkscape.13.n6.nabble.com/Snapping-tp4886159p4890698.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 17-4-2012 17:41, LucaDC wrote:
Johan Engelen-4 wrote
Before 0.49, the node tool always snapped.
Sorry, I think there is a misunderstood on what we are speaking about. I can't understand what you mean with this. I'm talking about the possibility of enabling and disabling snapping. I don't want to have to turn global snap off to have nodes not snapping, I want to control what nodes do with a button called "node snapping". That's logic for me.
0.48: there is the ability to turn snapping on and off *from* nodes. It is on per default, shift turns it off. Now, 0.49 adds another possibility to turn on/off node snapping, however, it is now no longer possible to only snap *from* nodes without snapping *to* nodes. That is annoying me. It must be very strange to have figured out how to display a grid, and then find out that... "hey! nothing snaps to it! Great program this Inkscape...". And that's because you have to turn on all kinds of snap source+targets per default, so that everything snaps to each other without grid...
I don't see the reason to change 0.48 behavior: snap a node while dragging it, shift disables it quickly. The control you want is: "shift". And we've had that for a long time in Inkscape.
Having control of snap sources can be useful, but only if there are more sources to choose from in the first place. When dragging a node, there is only one source to choose from, so then it's an easy choice, and shift disables snapping.
-Johan
On 04/17/2012 07:24 PM, Johan Engelen wrote:
0.48: there is the ability to turn snapping on and off *from* nodes. It is on per default, shift turns it off. Now, 0.49 adds another possibility to turn on/off node snapping,
In v0.48 our users had to realize there was a distinction between snap sources and snap targets. That proved to be confusing. Therefore we now have a global toggle, a group toggle, and a snap type toggle. This way one only has to think about groups of snap types. On the lowest level a type of snap can be set, and these can be toggled as a group or overall.
however, it is now no longer possible to only snap *from* nodes without snapping *to* nodes. That is annoying me.
That's why it's on my to-do list to allow a more fine grained control of snap sources and snap targets again. But it will be hidden from the main level of controls, it will not be exposed using the buttons we have now. I was thinking of adding a button that pops up the document properties dialog, and to show two lists there: one with all snap sources (> 20), and one with all snap targets (about 40). This way both you and Luca can have any setting you want with maximum control, without bothering new users too much.
It must be very strange to have figured out how to display a grid, and then find out that... "hey! nothing snaps to it! Great program this Inkscape...".
Of course we can discuss what should be enabled by default, and what not. This can be fixed by snapping cusp nodes by default.
And that's because you have to turn on all kinds of snap source+targets per default, so that everything snaps to each other without grid...
In v0.48 one had to enable three buttons to enable snapping to a grid, IIRC. "Global snapping", "Snap nodes or handles", and "Snap to grid" had to be enabled. And for this one had to distinguish between the "Snap nodes or handles" button and the "Snap to cusp nodes" buttons, with the former representing the sources and the latter representing the targets. That means observing the different colors in the icons (sources were depicted as blue nodes, whereas targets were depicted as green nodes), or reading the tooltips. In v 0.49 one has to enable four buttons, which is one more. But at least it's all just about grouping of snap-types, which is much easier to grasp than thinking about sources and targets. Currently, you cannot even toggle "snap cusp nodes" if the group itself hasn't been toggled. It will be greyed out. That shouldn't be too difficult to figure out. The v0.48-way might appear to be easier, but isn't this just because you got used to it?
I don't see the reason to change 0.48 behavior: snap a node while dragging it
... which required enabling three buttons!
, shift disables it quickly.
That still works
The control you want is: "shift". And we've had that for a long time in Inkscape.
Having control of snap sources can be useful, but only if there are more sources to choose from in the first place. When dragging a node, there is only one source to choose from,
Not completely true. There's still the distinction between cusp and smooth nodes.
so then it's an easy choice, and
We could overrule the snap settings per tool quite easily, but I don't like the idea. Why introduce inconsistencies? There will be people asking "hey, why do these nodes snap to the grid in the node tool? I just turned off snapping of cusp nodes while I was using the selector tool, didn't I" ?
IMHO the solution should be in enabling it by default, or in allowing the extremely fine grained control.
Diederik
On 17-4-2012 21:01, Diederik van Lierop wrote:
On 04/17/2012 07:24 PM, Johan Engelen wrote:
0.48: there is the ability to turn snapping on and off *from* nodes. It is on per default, shift turns it off. Now, 0.49 adds another possibility to turn on/off node snapping,
In v0.48 our users had to realize there was a distinction between snap sources and snap targets. That proved to be confusing. Therefore we now have a global toggle, a group toggle, and a snap type toggle. This way one only has to think about groups of snap types. On the lowest level a type of snap can be set, and these can be toggled as a group or overall.
I never realized this. Default was perfect. I keep hammering the perfect settings: always snap nodes, never snap to them. If you want something different, click buttons.
however, it is now no longer possible to only snap *from* nodes without snapping *to* nodes. That is annoying me.
That's why it's on my to-do list to allow a more fine grained control of snap sources and snap targets again. But it will be hidden from the main level of controls, it will not be exposed using the buttons we have now. I was thinking of adding a button that pops up the document properties dialog, and to show two lists there: one with all snap sources (> 20), and one with all snap targets (about 40). This way both you and Luca can have any setting you want with maximum control, without bothering new users too much.
Please prioritize it.
It must be very strange to have figured out how to display a grid, and then find out that... "hey! nothing snaps to it! Great program this Inkscape...".
Of course we can discuss what should be enabled by default, and what not. This can be fixed by snapping cusp nodes by default.
And that's because you have to turn on all kinds of snap source+targets per default, so that everything snaps to each other without grid...
In v0.48 one had to enable three buttons to enable snapping to a grid, IIRC. "Global snapping", "Snap nodes or handles", and "Snap to grid" had to be enabled. And for this one had to distinguish between the "Snap nodes or handles" button and the "Snap to cusp nodes" buttons, with the former representing the sources and the latter representing the targets. That means observing the different colors in the icons (sources were depicted as blue nodes, whereas targets were depicted as green nodes), or reading the tooltips. In v 0.49 one has to enable four buttons, which is one more. But at least it's all just about grouping of snap-types, which is much easier to grasp than thinking about sources and targets. Currently, you cannot even toggle "snap cusp nodes" if the group itself hasn't been toggled. It will be greyed out. That shouldn't be too difficult to figure out. The v0.48-way might appear to be easier, but isn't this just because you got used to it?
This is all besides my point. 0.49 *now* cannot behave like 0.48. Please fix that soon.
I don't see the reason to change 0.48 behavior: snap a node while dragging it
... which required enabling three buttons!
No it was default. I challenge you to find anybody who knows what buttons you mean! ;-)
, shift disables it quickly.
That still works
The control you want is: "shift". And we've had that for a long time in Inkscape.
Having control of snap sources can be useful, but only if there are more sources to choose from in the first place. When dragging a node, there is only one source to choose from,
Not completely true. There's still the distinction between cusp and smooth nodes.
If I drag a smooth node, I *always* want it to snap (unless shift...). If I select a bunch of nodes, you still drag *one* node. And that one should snap, always, regardless of type. Don't you find it very awkward to see some other node snap than the one you are dragging? Why wouldn't you just have dragged that node instead?
so then it's an easy choice, and
We could overrule the snap settings per tool quite easily, but I don't like the idea. Why introduce inconsistencies? There will be people asking "hey, why do these nodes snap to the grid in the node tool? I just turned off snapping of cusp nodes while I was using the selector tool, didn't I" ?
No this is not confusing at all, since the selector tool cannot see nodes, nor can you "select them and drag them". It is quite different really.
Really am I alone in this? I would hate to have to add a "if_johan" piece of code to be able to use Inkscape. (yes I feel that strongly about it, and already have to apologize for other Inkscape quirks to colleagues)
Cheers, Johan
On 04/17/2012 09:36 PM, Johan Engelen wrote:
That's why it's on my to-do list to allow a more fine grained control of snap sources and snap targets again. But it will be hidden from the main level of controls, it will not be exposed using the buttons we have now. I was thinking of adding a button that pops up the document properties dialog, and to show two lists there: one with all snap sources (> 20), and one with all snap targets (about 40). This way both you and Luca can have any setting you want with maximum control, without bothering new users too much.
Please prioritize it.
It already is, but I'm a bit short on spare-time.
In v0.48 one had to enable three buttons to enable snapping to a grid, IIRC. "Global snapping", "Snap nodes or handles", and "Snap to grid" had to be enabled. And for this one had to distinguish between the "Snap nodes or handles" button and the "Snap to cusp nodes" buttons, with the former representing the sources and the latter representing the targets. That means observing the different colors in the icons (sources were depicted as blue nodes, whereas targets were depicted as green nodes), or reading the tooltips. In v 0.49 one has to enable four buttons, which is one more. But at least it's all just about grouping of snap-types, which is much easier to grasp than thinking about sources and targets. Currently, you cannot even toggle "snap cusp nodes" if the group itself hasn't been toggled. It will be greyed out. That shouldn't be too difficult to figure out. The v0.48-way might appear to be easier, but isn't this just because you got used to it?
This is all besides my point. 0.49 *now* cannot behave like 0.48. Please fix that soon.
I know. This was only to explain why v0.49 was changed, and why this regression was introduced. But don't worry, this regression will be fixed!
If I drag a smooth node, I *always* want it to snap (unless shift...). If I select a bunch of nodes, you still drag *one* node.
Not if you use the handles to scale or stretch a selection of nodes. In that case Inkscape will have to decide itself which node should snap. So here one could decide to give Inkscape a hand in deciding what should snap by disabling the snapping of smooth nodes. BTW, when using ctrl-shift while scaling Inkscape will stretch symmetrically. Shift is already taken, so you cannot disable snapping by using shift in that case.
And that one should snap, always, regardless of type. Don't you find it very awkward to see some other node snap than the one you are dragging? Why wouldn't you just have dragged that node instead?
The node tool is indeed different in that respect from the selector tool. So we could make the node tool behave differently. But I hate all these small inconsistencies!
No this is not confusing at all, since the selector tool cannot see nodes, nor can you "select them and drag them". It is quite different really.
Yes, every tool is different, I agree. But let's please try to make all tools use the settings, preferences, and shortcut-keys in the exact same way! Different logic for different tools is bad practice.
Really am I alone in this? I would hate to have to add a "if_johan" piece of code to be able to use Inkscape.
That won't be needed after I've exposed the detailed snap sources/targets, and after everybody can set their own defaults, right?
Regards,
Diederik
On 17-4-2012 21:57, Diederik van Lierop wrote:
And that one should snap, always, regardless of type. Don't you find it very awkward to see some other node snap than the one you are dragging? Why wouldn't you just have dragged that node instead?
The node tool is indeed different in that respect from the selector tool. So we could make the node tool behave differently. But I hate all these small inconsistencies!
No this is not confusing at all, since the selector tool cannot see nodes, nor can you "select them and drag them". It is quite different really.
Yes, every tool is different, I agree. But let's please try to make all tools use the settings, preferences, and shortcut-keys in the exact same way! Different logic for different tools is bad practice.
It is not different logic or inconsistency. It is as consistent as showing the nodes only in the node tool, showing bbox only in selection tool, showing circle nodes in circle tool, etc.
Note that: the selection tool is the only tool where "multiple snap sources" makes sense.
I would hate to have to add a "if_johan" piece of code to be able to use Inkscape.
That won't be needed after I've exposed the detailed snap sources/targets, and after everybody can set their own defaults, right?
Yep! :) (but I'm not sure if you have to go to the trouble of finding UI/dialog space and coding time to implement all these details) Just set the defaults to Inkscape 0.48. (simply to offload ~suv with the otherwise heaps of bug reports like this one: https://bugs.launchpad.net/inkscape/+bug/927898 )
Cheers, Johan
On 04/17/2012 10:33 PM, Johan Engelen wrote:
On 17-4-2012 21:57, Diederik van Lierop wrote:
And that one should snap, always, regardless of type. Don't you find it very awkward to see some other node snap than the one you are dragging? Why wouldn't you just have dragged that node instead?
The node tool is indeed different in that respect from the selector tool. So we could make the node tool behave differently. But I hate all these small inconsistencies!
No this is not confusing at all, since the selector tool cannot see nodes, nor can you "select them and drag them". It is quite different really.
Yes, every tool is different, I agree. But let's please try to make all tools use the settings, preferences, and shortcut-keys in the exact same way! Different logic for different tools is bad practice.
It is not different logic or inconsistency. It is as consistent as showing the nodes only in the node tool, showing bbox only in selection tool, showing circle nodes in circle tool, etc.
I don't agree with you on this point. Showing different elements (e.g. nodes, handles, bounding boxes, etc) for different tools indeed makes sense. However, this does not apply for having different behavior per tool. For one, showing different things is very explicit and is hard to miss. Imagine however that someone would like to disable snapping in the node tool. In each and every tool, this can be achieved using either of three methods: - by disabling the global snap toggle, or - by disabling the "snap nodes, paths, and handles" group, or - by disabling both the "snap cusp nodes" and "snap smooth nodes" group. Now if we would hard code snapping of nodes in the node tool, then the latter method would not work. Sure, our users have two other options left, but there will be people running into this, trying to disable snapping using the third methods and not succeeding. And in the end one might even file a bug report for this. It might be easier and make more sense for the workflow of some if we'd hard-code the snapping of nodes in the node tool, but I believe that others might feel this as annoying.
So I agree we have a regression here as you explained, but we should not solve this by hard-coding the snapping of all nodes in the node tool.
I've compiled a list of things that should be done w.r.t. the snapping mechanism, based on the discussion on this list the past few days: - Snapping of cusp nodes on by default - Fine grained control of all sources and targets for power users (requires individual control of sources and targets, and storing snap preferences more efficiently) - Snap delay to 50 ms by default (I would still like to have some confirmation that this is low enough, from those of you who are annoyed by the snap delay) - Tab-cycle snap targets (Just an idea, of which we still have to find out if this is practical) - Easy way to store preferences to be used as default in the templates. (Not only for the snap preferences, but Inkscape wide for all preferences? If so, then please don't wait for me implementing this. It could be a very long time before I get to such a new feature)
Did I miss anything?
Diederik
On 21-4-2012 22:58, Diederik van Lierop wrote:
On 04/17/2012 10:33 PM, Johan Engelen wrote:
On 17-4-2012 21:57, Diederik van Lierop wrote:
And that one should snap, always, regardless of type. Don't you find it very awkward to see some other node snap than the one you are dragging? Why wouldn't you just have dragged that node instead?
The node tool is indeed different in that respect from the selector tool. So we could make the node tool behave differently. But I hate all these small inconsistencies!
No this is not confusing at all, since the selector tool cannot see nodes, nor can you "select them and drag them". It is quite different really.
Yes, every tool is different, I agree. But let's please try to make all tools use the settings, preferences, and shortcut-keys in the exact same way! Different logic for different tools is bad practice.
It is not different logic or inconsistency. It is as consistent as showing the nodes only in the node tool, showing bbox only in selection tool, showing circle nodes in circle tool, etc.
I don't agree with you on this point. Showing different elements (e.g. nodes, handles, bounding boxes, etc) for different tools indeed makes sense. However, this does not apply for having different behavior per tool. For one, showing different things is very explicit and is hard to miss. Imagine however that someone would like to disable snapping in the node tool. In each and every tool, this can be achieved using either of three methods:
- by disabling the global snap toggle, or
- by disabling the "snap nodes, paths, and handles" group, or
- by disabling both the "snap cusp nodes" and "snap smooth nodes" group.
Now if we would hard code snapping of nodes in the node tool, then the latter method would not work. Sure, our users have two other options left, but there will be people running into this, trying to disable snapping using the third methods and not succeeding.
And in the end one might even file a bug report for this.
Really? Did that ever happen with the past versions? We already have bug reports about the current UI...
Apparently, I cannot stop you guys from adding this extremely fine-detailed control of snapping. Please do not add it anywhere in the toolbar UI, but hide it somewhere deep instead, and set it to the correct (nota bene) values per default. Choice of snap targets is interesting and should be in UI, choice of snap sources like nodes isn't.
(other examples of toggles ready for removal: grid and guides snapping toggles. shift+3, shift+| work fine for disabling the showing/snapping of grids/guides. yes you won't be able to see them but... come on.... Perpendicular and tangential snap toggles would be a much better of that space)
Cheers, Johan
On 04/22/2012 06:08 PM, Johan Engelen wrote:
Apparently, I cannot stop you guys from adding this extremely fine-detailed control of snapping.
This has not been done at all, and this has nothing to do with the issues you have with the current state of the UI. Before we had a distinction between sources and targets in the snap buttons. This has been removed to make things easier, and I truly believe it's easier now. Basically, I did exactly what you' re asking: NOT adding fine-grained control!
Please do not add it anywhere in the toolbar UI, but hide it somewhere deep instead
That is exactly what I proposed a few mails ago (adding only a single button to pop-up the document properties dialog, making it discoverable while avoiding clutter), to allow power-users to achieve what they need and to allow novices to find their way around the snapping toolbar.
Choice of snap targets is interesting and should be in UI, choice of snap sources like nodes isn't.
You're basing your opinion too strongly on the node tool only, I believe. In the selector tool for example you really need to be able to control what snaps to the grid, and what not. So control of snap sources is a must, also for novices. Buttons are much easier for this than options such as "snap-closest-only", and are in some cases even indispensable as Luca explained. I would feel the same about the node tool, because in general I don't want to snap smooth nodes to anything. But it should be possible for power-users.
(other examples of toggles ready for removal: grid and guides snapping toggles. shift+3, shift+| work fine for disabling the showing/snapping of grids/guides. yes you won't be able to see them but... come on....
What would removing those toggles bring us? Only more space on the snap toolbar? They're not confusing, they're all at the bottom, and on top of that the window size is still limited by the tools toolbar.
Perpendicular and tangential snap toggles would be a much better of that space)
I've thought about that too, but these options currently still depend on the snapping to paths. Therefore, they should be greyed out when snapping to paths is disabled, but this would add another sub-group to the snap toolbar. So it requires a bit more work than just dropping the buttons there.
Kind regards,
Diederik
Brief replies:
On 22-4-2012 22:26, Diederik van Lierop wrote:
On 04/22/2012 06:08 PM, Johan Engelen wrote:
Apparently, I cannot stop you guys from adding this extremely fine-detailed control of snapping.
This has not been done at all, and this has nothing to do with the issues you have with the current state of the UI. Before we had a distinction between sources and targets in the snap buttons. This has been removed to make things easier, and I truly believe it's easier now. Basically, I did exactly what you' re asking: NOT adding fine-grained control!
But you are planning to (hence the future sense of the sentence).
Please do not add it anywhere in the toolbar UI, but hide it somewhere deep instead
That is exactly what I proposed a few mails ago (adding only a single button to pop-up the document properties dialog, making it discoverable while avoiding clutter), to allow power-users to achieve what they need and to allow novices to find their way around the snapping toolbar.
Choice of snap targets is interesting and should be in UI, choice of snap sources like nodes isn't.
You're basing your opinion too strongly on the node tool only, I believe.
You're basing your opinion too strongly on the selector tool only, I believe. There is no other tool that needs precise control of snap sources. Note: you would have to add *separate* node snap sourcing in the selector tool from node snap sourcing in the node tool. I think the majority of grid users want node snap sourcing in the node tool, and not in the selector tool.
In the selector tool for example you really need to be able to control what snaps to the grid, and what not. So control of snap sources is a must, also for novices. Buttons are much easier for this than options such as "snap-closest-only",
Really? For each move you do, you go to the toolbar and set the correct snap buttons?
and are in some cases even indispensable as Luca explained.
This is only relevant for the selector tool, right? How often is "some cases", and does the tab cycling solve it easily, or is that too cumbersome?
I would feel the same about the node tool, because in general I don't want to snap smooth nodes to anything. But it should be possible for power-users.
If snapping is on. And you have only one single thing that could possibly snap. The most logical thing to do is snap it. Full stop. If you don't want it to snap, press shift. (sorry for being repetitive)
(other examples of toggles ready for removal: grid and guides snapping toggles. shift+3, shift+| work fine for disabling the showing/snapping of grids/guides. yes you won't be able to see them but... come on....
What would removing those toggles bring us? Only more space on the snap toolbar? They're not confusing, they're all at the bottom, and on top of that the window size is still limited by the tools toolbar.
Yes more space and less clutter. They are not confusing, they just have very little use. What would adding those toggles bring us?
Perpendicular and tangential snap toggles would be a much better of that space)
I've thought about that too, but these options currently still depend on the snapping to paths. Therefore, they should be greyed out when snapping to paths is disabled, but this would add another sub-group to the snap toolbar. So it requires a bit more work than just dropping the buttons there.
The graying-out for the snap buttons is not necessary and is arguably annoying for quickly setting snap preferences. If at all we want this, it should have the lowest priority and can be added at very late stage; no need to worry about that now.
Can I go ahead and restore node tool snap behavior?
Regards, Johan
On 2012-04-22 23:48, Johan Engelen wrote:
You're basing your opinion too strongly on the selector tool only, I believe.
No, I'm trying to make a consistent UI, and one that doesn't have a steep learning curve. Without taking away control from power users
I think the majority of grid users want node snap sourcing in the node tool, and not in the selector tool.
Please explain, because I don't understand this. Are you saying that in the selector tool nodes shouldn't snap?
In the selector tool for example you really need to be able to control what snaps to the grid, and what not. So control of snap sources is a must, also for novices. Buttons are much easier for this than options such as "snap-closest-only",
Really? For each move you do, you go to the toolbar and set the correct snap buttons?
Easiest != Fastest.
and are in some cases even indispensable as Luca explained.
This is only relevant for the selector tool, right? How often is "some cases", and does the tab cycling solve it easily, or is that too cumbersome?
Yes, that can be cumbersome if you have many nodes. But what's more important that it's hard to discover. Even you hadn't discovered it ;-)
I would feel the same about the node tool, because in general I don't want to snap smooth nodes to anything. But it should be possible for power-users.
If snapping is on. And you have only one single thing that could possibly snap. The most logical thing to do is snap it. Full stop. If you don't want it to snap, press shift.
If only shift-to-disable-snapping would have been implemented consistently... If behaves very differently from case to case, even when limiting the discussion to the node tool. When you start dragging a node or a selection of nodes, it matters if you press shift before or after you click and drag the node. Of course, this is by design. Also, when using the handles to scale a selection of nodes, shift makes the scaling symmetric instead of disabling snapping.
I'm very much in favor of shift-to-disable-snapping, but we need other options too as long as this hasn't been implemented consistently and Inkscape wide. We cannot expect everyone to discover and remember the peculiarities related to the modifier keys. Obviously this is not a problem for you and me, but for others having a clearly visible and discoverable button is easiest (not fastest)
Can I go ahead and restore node tool snap behavior?
Yes, but only it things are still unbearable for you after I'm done :-).
Regards,
Diederik
Johan Engelen-4 wrote
Can I go ahead and restore node tool snap behavior?
Sorry but I think I've missed the survey from which you deduced that your approach is the preferred one by the majority of users ;) Jokes apart, I thinks that there hasn't been enough complaints about the current one (that is good to me, so I don't want to judge if it's better or not than yours) to justify an intervention on something that Diederik is already working on (and I feel his work will fix such issues). If it's so important for your workflow and you are able, good for you: you can fix your own copy of code in the meantime and wait for future development. Do you want a list of things I'm still waiting to be fixed?
And sorry again for being dummy but I didn't clearly understand what you would "restore". I've understood that you would like having nodes always snap in node tool but I can't remember having this happen in past releases. I've always been able to switch node snapping on and off (regardless of the tool). Do you really want to force all people that don't need (or don't want) node snapping but do need some other sorts of snapping to live with shift pressed (when in node tool)? Again, this sounds so much strange to me that I really feel I didn't catch your request.
-- View this message in context: http://inkscape.13.n6.nabble.com/Snapping-tp4886159p4909636.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On 23-4-2012 11:15, LucaDC wrote:
And sorry again for being dummy but I didn't clearly understand what you would "restore". I've understood that you would like having nodes always snap in node tool but I can't remember having this happen in past releases.
Restore 0.48, 0.47, 0.46, 0.45 behavior. Please check for yourself.
-Johan
Although I am contributing frequently to the code, for using anything else then basic functionality, I consider myself to be a newbie. To be honest, I never understood the snapping interface, nor in 0.49, nor in 0.48 or in prior releases. I actually always enabled all snap buttons as I did not understand the meaning of the individual buttons.
I have followed this discussion from a distance and is at least partly too technical for me. So here are just my 2 cents: Ask yourself the questions why would your neighbour (who off course uses Inkscape) need a certain button and where would he expect this button in the interface. For a beginner, there are issues with both questions: - in the point of view of a novice user: why at all do the buttons "Snap bounding boxes", "Snap nodes, paths, and handles", "Snap other points (centers, guide origins, gradient handles, etc.)" exist? Without activating these, it is apparently not possible to snap anything. This is confusing for users. - is there a difference between snapping from and snapping to, and do we actually want this difference? (Keep in mind that every user is different from yourself!) A novice user also does not know, or can hardly deduce it from the interface... Look a bit clearer to the user messages: sometimes you have "Snap ... points" in the message, sometimes "Snap to ... points", but either the user messages are named randomly or these buttons seem to be randomly positioned. If it is desirable to have the asymmetric behaviour for part of our user base, then + position the relevant buttons visually well separated from each other. At least by a bar, although a single word in the button bar would greatly help too. + update the user messages accordingly (user messages in 0.48 were not self explaining either) + BUT provide a checkbox to get symmetric behaviour (per Johan)
Regards K.
Op 23 april 2012 19:42 heeft Johan Engelen <jbc.engelen@...2592...> het volgende geschreven:
On 23-4-2012 11:15, LucaDC wrote:
And sorry again for being dummy but I didn't clearly understand what you would "restore". I've understood that you would like having nodes always snap in node tool but I can't remember having this happen in past releases.
Restore 0.48, 0.47, 0.46, 0.45 behavior. Please check for yourself.
-Johan
For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 04/23/2012 10:14 PM, Kris De Gussem wrote:
Although I am contributing frequently to the code, for using anything else then basic functionality, I consider myself to be a newbie.
Same here! I've spend more time coding than actually using Inkscape :-)
For a beginner, there are issues with both questions:
- in the point of view of a novice user: why at all do the buttons
"Snap bounding boxes", "Snap nodes, paths, and handles", "Snap other points (centers, guide origins, gradient handles, etc.)" exist? Without activating these, it is apparently not possible to snap anything. This is confusing for users.
True, snapping has a learning curve. This can be remedied to some extent by choosing sensible defaults. Currently, handles snap to grids/guides by default, so when creating a new shape it will snap to the grid. By now you've probably also learned that we should snap nodes to grids by default. The next thing to do is to try to make it easy for users to discover the snapping features in a natural way. That is, make sure that we have a decently designed snap toolbar. I've tried to improve that in trunk.
- is there a difference between snapping from and snapping to, and do
we actually want this difference? (Keep in mind that every user is different from yourself!) A novice user also does not know, or can hardly deduce it from the interface... Look a bit clearer to the user messages: sometimes you have "Snap ... points" in the message, sometimes "Snap to ... points",
Exactly that distinction has been removed in nightly builds! There's no sources vs. targets distinction remaining in the snap toolbar, nor in its tooltips (if you still find any then please let me know). Yes, there is a difference between sources and targets under the hood, and we should expose that to experienced users. But I've first tried to hide that for newbies, now I only have to expose it again in an intuitive way for power users
but either the user messages are named randomly or these buttons seem to be randomly positioned.
If you see room from improvements anywhere then please let me know. I might have developed a blind spot for that over time.
If it is desirable to have the asymmetric behaviour for part of our user base, then + position the relevant buttons visually well separated from each
Instead, I was planning to hide this completely, and make it only accessible in the document properties dialog. Only one button will be added to the snap toolbar: to open the document properties dialog with the snapping tab in the front (to make these asymmetric options easily accessible and discoverable for the users). All buttons on the toolbar will toggle the relevant snap source AND target simultaneously, making the snap-toolbar symmetric.
+ update the user messages accordingly (user messages in 0.48 werenot self explaining either)
Please suggest better messages! I will implement them, but I figure you've got a lot experience with these things.
+ BUT provide a checkbox to get symmetric behaviour (per Johan)
One can get asymmetric behavior in future versions by setting the sources and targets independently, and if desired these can be stored in the default.svg template.
Kind regards,
Diederik
I am getting angry every time I read this thread, so I will no longer reply.
-Johan
On 04/23/2012 07:42 PM, Johan Engelen wrote:
I am getting angry every time I read this thread, so I will no longer reply.
I don't know what exactly ticked you off, but if it was one (or all) of my comments then please realize that wasn't my intention at all, and I apologize for that. I felt that we were having a good discussion.
Anyway, let me remind you that I promised to change the defaults, and that I promised to also enable your workflow again: snapping all nodes, be it cusp or smooth nodes sources, to either cusp or smooth node targets (but not both). Also remind that it's still a work in progress, and that we're only talking about nightly builds here. It's not like v0.49 is going to be released any time soon.
Regards,
Diederik
On Tue, Apr 24, 2012 at 6:50 PM, Diederik van Lierop <mail@...1689...> wrote:
On 04/23/2012 07:42 PM, Johan Engelen wrote:
I am getting angry every time I read this thread, so I will no longer reply.
I don't know what exactly ticked you off, but if it was one (or all) of my comments then please realize that wasn't my intention at all, and I apologize for that. I felt that we were having a good discussion.
Anyway, let me remind you that I promised to change the defaults, and that I promised to also enable your workflow again: snapping all nodes, be it cusp or smooth nodes sources, to either cusp or smooth node targets (but not both). Also remind that it's still a work in progress, and that we're only talking about nightly builds here. It's not like v0.49 is going to be released any time soon.
Regards,
Diederik
Do we have a blueprint or wiki page or anything that captures what we're planning on doing? Think it might help to document what the alternate workflows are etc
Johan Engelen-4 wrote
I am getting angry every time I read this thread, so I will no longer reply.
Ops, that's not good at all. Johan, please accept my apologizes if you think it was my fault; and if so, please, also believe me that the result is the opposite of what was my intent. I hope to hear you again in this thread as soon as any new implementation will be available to be judged and refined (so now it's up to you, Diederik ;): your point of view is all the more important and useful as it's different from ours. IMHO the new approach will fit for much more needs as the current one. Let's wait for it and, hopefully, we'll have less (or, at least, different) problems to deal with. Sure it won't take ages, won't it? :) Luca
-- View this message in context: http://inkscape.13.n6.nabble.com/Snapping-tp4886159p4933234.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On Sat, Apr 21, 2012 at 9:58 PM, Diederik van Lierop <mail@...1689...> wrote:
And in the end one might even file a bug report for this.
people will complain either way, you cant please everyone. We have historically had a policy of trying not to go too overboard with options/preferences in the ui, the more you add, the more opportunities you have for confusing the heck out of people. I cant say I've used the snapping recently enough to be able to comment on current vs old behaviour, although I think that trying to force a consistant logic across tools whose inherent nature is inconsistant is unwise. you can have a logical approach without it meaning the detail of implementation is always consistant. ie we always snap the item being dragged to the snap targets. for selector you have to specify more detail on what aspect of the item being dragged you wish to snap too, as you have an entire object, but for the node tool the item being dragged is a node, so thats what you snap.
participants (11)
-
unknown＠example.com -
Diederik van Lierop -
gespertino＠...400... -
Johan Engelen -
John Cliff -
Josh Andler -
Kris De Gussem -
LucaDC -
Tavmjong Bah -
Vladimir Savic -
~suv