Quantcast

Snapping

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Snapping

Johan Engelen-4
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

Tavmjong Bah
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



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

su_v
In reply to this post by Johan Engelen-4
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

LucaDC
In reply to this post by Johan Engelen-4
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

Johan Engelen-4
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

Vladimir Savic-3
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

Diederik en Rezi
In reply to this post by Johan Engelen-4
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



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

Diederik en Rezi
In reply to this post by Vladimir Savic-3
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

Josh Andler
On Mon, Apr 16, 2012 at 2:03 PM, Diederik van Lierop <[hidden email]> 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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

Johan Engelen-4
In reply to this post by Diederik en Rezi
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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

Johan Engelen-4
In reply to this post by Diederik en Rezi
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




------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

Vladimir Savic-3
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

Josh Andler
On Mon, Apr 16, 2012 at 3:55 PM, Vladimir Savic
<[hidden email]> 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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

Guillermo Espertino (Gez)
2012/4/16 Josh Andler <[hidden email]>

>
> On Mon, Apr 16, 2012 at 3:55 PM, Vladimir Savic
> <[hidden email]> 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.

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

LucaDC
In reply to this post by Diederik en Rezi
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

Johan Engelen-4
---- LucaDC <[hidden email]> 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


------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

LucaDC
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

Johan Engelen-4
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




------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

Guillermo Espertino (Gez)
In reply to this post by Guillermo Espertino (Gez)
2012/4/17 Vladimir Savic <[hidden email]>:

> Why not even setting it to zero? I do it almost immediately upon new
> install. Although, I admit that even having an option for delay is great,
> especially as drawing gets more complex.
>
> If you choose to change it (but not zero it) - half way down from default
> will work, I guess.

There was something witn zero delay, I can't remember what (and it
probably was fixed already). I think it was something related with
performance, but I'm not sure.
I should check my bug reports and see what was the problem (and if it
still exists), but I remember having to use a small delay to avoid it.

Anyway, If snapping with zero delay doesn't conflict with other tools
or something, I can agree that it's a much pleasing default, so +1.

Gez

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Snapping

Johan Engelen-4
On 17-4-2012 20:05, [hidden email] wrote:

> 2012/4/17 Vladimir Savic<[hidden email]>:
>
>> Why not even setting it to zero? I do it almost immediately upon new
>> install. Although, I admit that even having an option for delay is great,
>> especially as drawing gets more complex.
>>
>> If you choose to change it (but not zero it) - half way down from default
>> will work, I guess.
>
> There was something witn zero delay, I can't remember what (and it
> probably was fixed already). I think it was something related with
> performance, but I'm not sure.
> I should check my bug reports and see what was the problem (and if it
> still exists), but I remember having to use a small delay to avoid it.
>
> Anyway, If snapping with zero delay doesn't conflict with other tools
> or something, I can agree that it's a much pleasing default, so +1.

Can't remember ever having problems with setting it to 0.
Indeed, one of the first things I do with new install and for new users
(to prevents complaints about bugs :).

But the feature itself is great. I think I used it once on a complicated
document. (indicating that this setting would be nice to have on a
per-document basis?)

Cheers,
   Johan

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
123
Loading...