Hi all, When you add a node to a path using the nodetool with ctrl+alt, it maintains the selection of previously selected nodes. This is extremely annoying: consider adding a node, moving it a bit, adding a new one, wanting to move it but then the old one also moves... (thanks Alessandro for pointing this out to me).
Is this desired behavior? If so, is it ok to add an option to reset selection to only the newly added node?
Ciao, Johan
2011/7/25 Johan Engelen <jbc.engelen@...2592...>:
Hi all, When you add a node to a path using the nodetool with ctrl+alt, it maintains the selection of previously selected nodes. This is extremely annoying: consider adding a node, moving it a bit, adding a new one, wanting to move it but then the old one also moves... (thanks Alessandro for pointing this out to me).
Is this desired behavior? If so, is it ok to add an option to reset selection to only the newly added node?
Right now we have two ways to insert a node: - doubleclick inserts the node and takes selection (only the newly inserted node is selected) - Ctrl+Alt click inserts the node and adds it to the selection without clearing other nodes
So doubleclick already does what this preference would do.
Regards, Krzysztof
To be fair, take other input devices into account. For example, when working with a tablet, double tap is far less accurate and a less viable alternative.
Cheers, Josh On Jul 25, 2011 7:46 PM, "Krzysztof Kosiński" <tweenk.pl@...400...> wrote:
2011/7/25 Johan Engelen <jbc.engelen@...2592...>:
Hi all, When you add a node to a path using the nodetool with ctrl+alt, it maintains the selection of previously selected nodes. This is extremely annoying: consider adding a node, moving it a bit, adding a new one, wanting to move it but then the old one also moves... (thanks Alessandro for pointing this out to me).
Is this desired behavior? If so, is it ok to add an option to reset selection to only the newly added node?
Right now we have two ways to insert a node:
- doubleclick inserts the node and takes selection (only the newly
inserted node is selected)
- Ctrl+Alt click inserts the node and adds it to the selection without
clearing other nodes
So doubleclick already does what this preference would do.
Regards, Krzysztof
------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Yes, I know doubleclick does what I want. (I actually did not know about ctrl+alt until Alessandro told me) Am I the only one who finds it annoying? Not only for tablet use but also for mouse usage, double-clicking is more strain than single click. I should have posed the question in a different way. Why is the old selection maintained? (instead of adding an option for it, is this not a bug?)
Ciao, Johan
---- Josh Andler <scislac@...400...> wrote:
To be fair, take other input devices into account. For example, when working with a tablet, double tap is far less accurate and a less viable alternative.
Cheers, Josh On Jul 25, 2011 7:46 PM, "Krzysztof Kosiński" <tweenk.pl@...400...> wrote:
2011/7/25 Johan Engelen <jbc.engelen@...2592...>:
Hi all, When you add a node to a path using the nodetool with ctrl+alt, it maintains the selection of previously selected nodes. This is extremely annoying: consider adding a node, moving it a bit, adding a new one, wanting to move it but then the old one also moves... (thanks Alessandro for pointing this out to me).
Is this desired behavior? If so, is it ok to add an option to reset selection to only the newly added node?
Right now we have two ways to insert a node:
- doubleclick inserts the node and takes selection (only the newly
inserted node is selected)
- Ctrl+Alt click inserts the node and adds it to the selection without
clearing other nodes
So doubleclick already does what this preference would do.
Regards, Krzysztof
The current behavior differs from the old node tool in Inkscape 0.47, but as mentioned earlier in a discussion with Alessandro, there might be use cases where it is really helpful to be able to keep the current selection of nodes when adding a new one (e.g. while node-sculpting).
I don't think it is a "bug", but maybe an option might be added for those preferring both methods to insert a node to behave the same way as in 0.47?
Quoting from an earlier discussion with Alessandro (a_l_e) on irc (#inkscape) on 2011-06-07:
23:03 < a_l_e> su-v: is alt-ctrl-click on a path a good way to add points to a path? 23:03 < su-v> why do you think it is not a good way? 23:03 < cwillu> a_l_e, you're silly :) 23:03 < a_l_e> cwillu: why? 23:03 < su-v> it's a toggle, you can also remove a node with this shortcut (IIRC) 23:03 < cwillu> a_l_e, dear god, don't alt-ctrl-click, you'll destroy _everything_ we've come to hold dear 23:03 < cwillu> yep 23:04 < su-v> a_l_e: http://inkscape.org/doc/keys048.html#id2407758 23:04 < a_l_e> ... i'm asking because when doing so, the new node gets selected but the current one (or the adjacent one) is also selected... 23:04 < a_l_e> which i is annoying... 23:04 < a_l_e> i would expect only the new one to be selected... 23:04 < cwillu> a_l_e, really? doesn't do anything here 23:05 < su-v> a_l_e: in this case, just double-click at add a node 23:05 < cwillu> a_l_e, only time I get an adjacent node selected is when I ctrl-z 23:05 < su-v> thus you can decide whether you want the new node to be added/remove to/from the current selection 23:05 < cwillu> or if I click on the line segment after 23:05 < a_l_e> i know... but with the tablet and while editing a path alt-ctrl-click feels more natural... 23:06 < su-v> double-click: insert new node (under cursor), select it 23:06 < su-v> ctrl+alt+click: add/remove node (from path and the current selection) 23:06 < a_l_e> personally, i don't see any reason for the other nodes to be selected... and i would make a bug report, if other people also think that it does not make sense... 23:07 < su-v> a_l_e: if you have no node selected, ctrl+alt+click selected both the new node _and_ one of the adjacent ones? can't reproduce 23:07 < cwillu> a_l_e, doesn't do that here 23:08 < a_l_e> not sure about it... 23:08 < su-v> what it does is to add the new node (or remove it) from the current selection (which can be useful) 23:08 < a_l_e> but if one is selected it's not deselected... 23:08 < a_l_e> how can it be useful? (it's a serious question! :-) 23:08 < su-v> a_l_e: if you have a complex selection of nodes, you will be glade not have to redo the selection because you want to insert an additional node 23:09 < su-v> or e.g. when sculpting nodes of complex paths 23:09 < a_l_e> ok, if there is a usecase i don't write a bug report... and try to always click a second time on the node :-) 23:09 < su-v> <esc> 23:09 < su-v> deselects all nodes 23:10 < a_l_e> the problem is that i tend to add a node and move it right away... which results in the segment being moved instead of the node alone... 23:10 < su-v> then 'ctrl+click' (if you don't want to double-click ;) ) 23:11 < su-v> double-click and drag? 23:11 < a_l_e> ctrl-click does not work.. 23:11 < a_l_e> double click is ok 23:11 < su-v> why does it have to be ctrl+alt+click? 23:11 < su-v> use ctrl+alt+click to quickly delete a node 23:11 < a_l_e> because i have already the left hand on the modifier keys and double click does not feel natural to me on the pen... 23:12 < a_l_e> i use c+a+click to delete nodes... 23:12 < a_l_e> that works correctly. 23:13 < a_l_e> however, problem solved: there is a use case for the current behavior of alt+ctrl+click so i won't ask for a change. 23:13 < su-v> I don't think it is incorrect to keep the current selection of nodes when inserting a new node with ctrl+alt+click 23:13 < su-v> it might depend in the workflow 23:16 < su-v> a_l_e: but I can confirm that the behavior has changed in the new node tool of 0.48 23:17 < su-v> (in 0.47, Ctrl+Alt+click deselects other selected nodes and only selects the new node) 23:17 < a_l_e> which is nicer :-) 23:17 < su-v> just tested and compared 0.47 and current trunk 23:17 < a_l_e> at least to me...
On 26/7/11 16:33, jbc.engelen@...2592... wrote:
Yes, I know doubleclick does what I want. (I actually did not know about ctrl+alt until Alessandro told me) Am I the only one who finds it annoying? Not only for tablet use but also for mouse usage, double-clicking is more strain than single click. I should have posed the question in a different way. Why is the old selection maintained? (instead of adding an option for it, is this not a bug?)
---- Josh Andler <scislac@...400...> wrote:
To be fair, take other input devices into account. For example, when working with a tablet, double tap is far less accurate and a less viable alternative.
On Jul 25, 2011 7:46 PM, "Krzysztof Kosiński" <tweenk.pl@...400...> wrote:
Right now we have two ways to insert a node:
- doubleclick inserts the node and takes selection (only the newly
inserted node is selected)
- Ctrl+Alt click inserts the node and adds it to the selection without
clearing other nodes
So doubleclick already does what this preference would do.
2011/7/25 Johan Engelen <jbc.engelen@...2592...>:
When you add a node to a path using the nodetool with ctrl+alt, it maintains the selection of previously selected nodes. This is extremely annoying: consider adding a node, moving it a bit, adding a new one, wanting to move it but then the old one also moves... (thanks Alessandro for pointing this out to me).
Is this desired behavior? If so, is it ok to add an option to reset selection to only the newly added node?
An option for it does seem like the best way to go imho.
Cheers, Josh
2011/7/26 ~suv <suv-sf@...58...>:
The current behavior differs from the old node tool in Inkscape 0.47, but as mentioned earlier in a discussion with Alessandro, there might be use cases where it is really helpful to be able to keep the current selection of nodes when adding a new one (e.g. while node-sculpting).
I don't think it is a "bug", but maybe an option might be added for those preferring both methods to insert a node to behave the same way as in 0.47?
Quoting from an earlier discussion with Alessandro (a_l_e) on irc (#inkscape) on 2011-06-07:
23:03 < a_l_e> su-v: is alt-ctrl-click on a path a good way to add points to a path? 23:03 < su-v> why do you think it is not a good way? 23:03 < cwillu> a_l_e, you're silly :) 23:03 < a_l_e> cwillu: why? 23:03 < su-v> it's a toggle, you can also remove a node with this shortcut (IIRC) 23:03 < cwillu> a_l_e, dear god, don't alt-ctrl-click, you'll destroy _everything_ we've come to hold dear 23:03 < cwillu> yep 23:04 < su-v> a_l_e: http://inkscape.org/doc/keys048.html#id2407758 23:04 < a_l_e> ... i'm asking because when doing so, the new node gets selected but the current one (or the adjacent one) is also selected... 23:04 < a_l_e> which i is annoying... 23:04 < a_l_e> i would expect only the new one to be selected... 23:04 < cwillu> a_l_e, really? doesn't do anything here 23:05 < su-v> a_l_e: in this case, just double-click at add a node 23:05 < cwillu> a_l_e, only time I get an adjacent node selected is when I ctrl-z 23:05 < su-v> thus you can decide whether you want the new node to be added/remove to/from the current selection 23:05 < cwillu> or if I click on the line segment after 23:05 < a_l_e> i know... but with the tablet and while editing a path alt-ctrl-click feels more natural... 23:06 < su-v> double-click: insert new node (under cursor), select it 23:06 < su-v> ctrl+alt+click: add/remove node (from path and the current selection) 23:06 < a_l_e> personally, i don't see any reason for the other nodes to be selected... and i would make a bug report, if other people also think that it does not make sense... 23:07 < su-v> a_l_e: if you have no node selected, ctrl+alt+click selected both the new node _and_ one of the adjacent ones? can't reproduce 23:07 < cwillu> a_l_e, doesn't do that here 23:08 < a_l_e> not sure about it... 23:08 < su-v> what it does is to add the new node (or remove it) from the current selection (which can be useful) 23:08 < a_l_e> but if one is selected it's not deselected... 23:08 < a_l_e> how can it be useful? (it's a serious question! :-) 23:08 < su-v> a_l_e: if you have a complex selection of nodes, you will be glade not have to redo the selection because you want to insert an additional node 23:09 < su-v> or e.g. when sculpting nodes of complex paths 23:09 < a_l_e> ok, if there is a usecase i don't write a bug report... and try to always click a second time on the node :-) 23:09 < su-v> <esc> 23:09 < su-v> deselects all nodes 23:10 < a_l_e> the problem is that i tend to add a node and move it right away... which results in the segment being moved instead of the node alone... 23:10 < su-v> then 'ctrl+click' (if you don't want to double-click ;) ) 23:11 < su-v> double-click and drag? 23:11 < a_l_e> ctrl-click does not work.. 23:11 < a_l_e> double click is ok 23:11 < su-v> why does it have to be ctrl+alt+click? 23:11 < su-v> use ctrl+alt+click to quickly delete a node 23:11 < a_l_e> because i have already the left hand on the modifier keys and double click does not feel natural to me on the pen... 23:12 < a_l_e> i use c+a+click to delete nodes... 23:12 < a_l_e> that works correctly. 23:13 < a_l_e> however, problem solved: there is a use case for the current behavior of alt+ctrl+click so i won't ask for a change. 23:13 < su-v> I don't think it is incorrect to keep the current selection of nodes when inserting a new node with ctrl+alt+click 23:13 < su-v> it might depend in the workflow 23:16 < su-v> a_l_e: but I can confirm that the behavior has changed in the new node tool of 0.48 23:17 < su-v> (in 0.47, Ctrl+Alt+click deselects other selected nodes and only selects the new node) 23:17 < a_l_e> which is nicer :-) 23:17 < su-v> just tested and compared 0.47 and current trunk 23:17 < a_l_e> at least to me...
On 26/7/11 16:33, jbc.engelen@...2592... wrote:
Yes, I know doubleclick does what I want. (I actually did not know about ctrl+alt until Alessandro told me) Am I the only one who finds it annoying? Not only for tablet use but also for mouse usage, double-clicking is more strain than single click. I should have posed the question in a different way. Why is the old selection maintained? (instead of adding an option for it, is this not a bug?)
---- Josh Andler <scislac@...400...> wrote:
To be fair, take other input devices into account. For example, when working with a tablet, double tap is far less accurate and a less viable alternative.
On Jul 25, 2011 7:46 PM, "Krzysztof Kosiński" <tweenk.pl@...400...> wrote:
Right now we have two ways to insert a node:
- doubleclick inserts the node and takes selection (only the newly
inserted node is selected)
- Ctrl+Alt click inserts the node and adds it to the selection without
clearing other nodes
So doubleclick already does what this preference would do.
2011/7/25 Johan Engelen <jbc.engelen@...2592...>:
When you add a node to a path using the nodetool with ctrl+alt, it maintains the selection of previously selected nodes. This is extremely annoying: consider adding a node, moving it a bit, adding a new one, wanting to move it but then the old one also moves... (thanks Alessandro for pointing this out to me).
Is this desired behavior? If so, is it ok to add an option to reset selection to only the newly added node?
W dniu 26 lipca 2011 18:01 użytkownik Josh Andler <scislac@...400...> napisał:
An option for it does seem like the best way to go imho.
I'm not a fan of adding yet another option - we already have far too many settings for things which are really workarounds for bugs or missing functionality. "Latency skew", "Enable relayout of incomplete sections" (????) and zoom correction factor (this should be available from GDK and on top of that it's not really implemented correctly - it just changes the zoom percentage for the 1:1 zoom button instead of making it so that 100% zoom = physical dimensions) are prime examples.
Maybe we should make Ctrl+Alt click act exactly the same as doubleclick? If hardly anybody needs to use the "insert and add to selection" functionality, and it can be done using other commands e.g. shift+click or rubberbanding, then there's no point in keeping it. (This is a matter of changing "false" to "true" in the argument of _insertNode() in the clicked() handler in ui/tool/curve-drag-point.cpp.)
Regards, Krzysztof
On 26/7/11 19:21, Krzysztof Kosiński wrote:
Maybe we should make Ctrl+Alt click act exactly the same as doubleclick?
That's how it worked in 0.47 (a new node is inserted, any selected nodes are deslected and the new node is selected).
Inkscape 0.48 added a new feature (Ctrl+Alt+click inserts a new new and adds it to the current selection of nodes), while keeping the old behavior for double-clicking to insert a new node.
If hardly anybody needs to use the "insert and add to selection" functionality, and it can be done using other commands e.g. shift+click or rubberbanding, then there's no point in keeping it.
AFAIU the point is that it _can't_ be done with other methods (insert a new node at the location of the mouse pointer and add it to the current selection of nodes) - but maybe I missed it or misunderstood. Can anyone provide detailed steps how to add i.e. insert a new node without losing the current selection of nodes with Inkscape 0.48.x or current trunk?
~suv
On 26-7-2011 19:57, ~suv wrote:
On 26/7/11 19:21, Krzysztof Kosiński wrote:
Maybe we should make Ctrl+Alt click act exactly the same as doubleclick?
That's how it worked in 0.47 (a new node is inserted, any selected nodes are deslected and the new node is selected).
Inkscape 0.48 added a new feature (Ctrl+Alt+click inserts a new new and adds it to the current selection of nodes), while keeping the old behavior for double-clicking to insert a new node.
Double-clicking does not work if you click at a spot where a bezier handle is (also if you cannot see the handle yet because no node is selected). Freehand paths often have bezier handles lying right on the path, so adding nodes to those paths with double click can be difficult. Ctrl+alt does work in that situation to add a node. So the ctrl+alt is not just a second way of doing the same thing.
If hardly anybody needs to use the "insert and add to selection" functionality, and it can be done using other commands e.g. shift+click or rubberbanding, then there's no point in keeping it.
AFAIU the point is that it _can't_ be done with other methods (insert a new node at the location of the mouse pointer and add it to the current selection of nodes) - but maybe I missed it or misunderstood. Can anyone provide detailed steps how to add i.e. insert a new node without losing the current selection of nodes with Inkscape 0.48.x or current trunk?
Can we assign this "add node while preserving selection" to ctrl+alt+shift ? (or is that already occupied?)
Ciao, Johan
W dniu 26 lipca 2011 20:31 użytkownik Johan Engelen <jbc.engelen@...2592...> napisał:
Can we assign this "add node while preserving selection" to ctrl+alt+shift ? (or is that already occupied?)
Ugh. I'd rather avoid triple modifiers. Let's assign Shift+Alt click to that, and Ctrl+Alt to insertion and taking selection - the former is not taken. In the stable version, just change "false" to "true".
Regards, Krzysztof
2011/7/27 Krzysztof Kosiński <tweenk.pl@...400...>:
Ugh. I'd rather avoid triple modifiers. Let's assign Shift+Alt click to that, and Ctrl+Alt to insertion and taking selection - the former is not taken.
I think despite the triple modifier we should stick with Shift+Ctrl+Alt (if it is not taken) for the simple reason of consistency: in other situations related to selections, pressing Shift when performing an action means "perform the action and add to the current selection". So we should keep it this way here, too. Besides, once you're already using a (somewhat clumsy) double modifier, pressing one additional key isn't that much worse imho, in particular since all three are close together. Just my 2 cents.
Max
2011/7/26 Krzysztof Kosiński <tweenk.pl@...400...>:
I'm not a fan of adding yet another option - we already have far too many settings for things which are really workarounds for bugs or missing functionality. "Latency skew", "Enable relayout of incomplete sections" (????) and zoom correction factor (this should be available from GDK and on top of that it's not really implemented correctly - it just changes the zoom percentage for the 1:1 zoom button instead of making it so that 100% zoom = physical dimensions).
As far as the latter (zoom correction factor) is concerned, I wasn't aware that gdk provides a way to solve this - thanks for pointing it out. The slider was suggested as a workaround ages ago, if I remember correctly because some commercial program (Adobe Illustrator?) had a similar option.
When you say that this should be available from GDK, I presume you are referring to the functions gdk_screen_(width|height) and gdk_screen_(width|height)_mm? I tried a quick fix based on these which seems to work for me. However, the documentation says: "Note that on many X servers this value will not be correct." Is there something else I could use?
If there isn't and we are stuck with the above functions, I have two more questions:
1) My (possibly kludgy) fix computes the following correction factor:
(gdk_screen_width() / gdk_screen_width_mm() * 25.4) / 90.0
Here 25.4 is the number of millimeters per inch, so that the value in brackets is the number of screen pixels per inch. This is then divided by the "true" value 90.0 pixels per inch to get the correction factor. This seems to work, but I was wondering whether the value 90.0 should be hard-coded or if it is configurable somewhere (I don't know much about screen resolutions, and I seem to remember that there are endless fights about what number of pixels per inch is "correct").
2) When I use the _height functions (instead of _width) I get slightly different correction factors. Should we thus have different scaling factors horizontally and vertically?
Cheers, Max
P.S.: Actually, when testing on a different computer I noticed that at 100% zoom the page width is almost, but not quite correct. This may have to do with item 2) above, though.
W dniu 27 lipca 2011 18:18 użytkownik Maximilian Albert <maximilian.albert@...1439...> napisał:
2011/7/26 Krzysztof Kosiński <tweenk.pl@...400...>: When you say that this should be available from GDK, I presume you are referring to the functions gdk_screen_(width|height) and gdk_screen_(width|height)_mm? I tried a quick fix based on these which seems to work for me. However, the documentation says: "Note that on many X servers this value will not be correct." Is there something else I could use?
Yes, I was thinking about those functions.
I think the value returned is incorrect when the X server can't read the monitor's EDID, or when the EDID contains bogus values. I don't know how often this happens. To be safe, let's not remove the correction slider, but give it a default value that matches the information from GDK.
- When I use the _height functions (instead of _width) I get slightly
different correction factors. Should we thus have different scaling factors horizontally and vertically?
I'm not sure about this. This would mean that the monitor's pixels are not square.
Regards, Krzysztof
2011/7/27 Krzysztof Kosiński <tweenk.pl@...400...>:
W dniu 27 lipca 2011 18:18 użytkownik Maximilian Albert <maximilian.albert@...1439...> napisał:
- When I use the _height functions (instead of _width) I get slightly
different correction factors. Should we thus have different scaling factors horizontally and vertically?
I'm not sure about this. This would mean that the monitor's pixels are not square.
Unfortunately, non-square pixels seem to be something that is becoming more common these days.
Cheers, Josh
Am Donnerstag, 28. Juli 2011, 06:29:43 schrieb Josh Andler:
2011/7/27 Krzysztof Kosiński <tweenk.pl@...400...>:
W dniu 27 lipca 2011 18:18 użytkownik Maximilian Albert
<maximilian.albert@...1439...> napisał:
- When I use the _height functions (instead of _width) I get slightly
different correction factors. Should we thus have different scaling factors horizontally and vertically?
I'm not sure about this. This would mean that the monitor's pixels are not square.
Unfortunately, non-square pixels seem to be something that is becoming more common these days.
While my impression was that they become *less* common nowadays, they have certainly always existed and it definitely makes sense to take the resolution vector into account.
HTH, Hans
On Wed, 2011-07-27 at 21:29 -0700, Josh Andler wrote:
2011/7/27 Krzysztof Kosiński <tweenk.pl@...400...>:
W dniu 27 lipca 2011 18:18 użytkownik Maximilian Albert <maximilian.albert@...1439...> napisał:
- When I use the _height functions (instead of _width) I get slightly
different correction factors. Should we thus have different scaling factors horizontally and vertically?
I'm not sure about this. This would mean that the monitor's pixels are not square.
Unfortunately, non-square pixels seem to be something that is becoming more common these days.
Not sure about more common considering all SD TVs have had non-square for 10's of years. ;-)
--Ted
participants (8)
-
unknown＠example.com -
Hans Meine -
Johan Engelen -
Josh Andler -
Krzysztof Kosiński -
Maximilian Albert -
Ted Gould -
~suv