Hello everyone.
Good news: there are only three regressions left in the new node tool now. 1. Sculpting (Alt+drag) doesn't work. 2. Snapping nodes doesn't work. 3. Transforming one handle using the keyboard (left/right Ctrl and Alt + various keys) doesn't work Everything else should work like in the old one. I think 1 and 3 are not critical, so the only thing left to fix before the tool is ready for prime time is snapping.
Bad news: snapping is a complex feature, particularly because I want to provide it for nodeset transforms. Additionally, there is some code in SnapManager that assumes only one editable path. It could be finished before the new year, but it could as well take another month.
Regards, Krzysztof
1 is important for me... have you asked diedrik for help with snapping? I do not intend to offer his help, but if he is willing to give pointers or assist, I recommend talking with (and learning from) him. This is a big piece of community development, you usually don't have to go it alone... and it's generally not advisable.
On Dec 26, 2009 6:00 PM, "Krzysztof Kosiński" <tweenk.pl@...400...> wrote:
Hello everyone.
Good news: there are only three regressions left in the new node tool now. 1. Sculpting (Alt+drag) doesn't work. 2. Snapping nodes doesn't work. 3. Transforming one handle using the keyboard (left/right Ctrl and Alt + various keys) doesn't work Everything else should work like in the old one. I think 1 and 3 are not critical, so the only thing left to fix before the tool is ready for prime time is snapping.
Bad news: snapping is a complex feature, particularly because I want to provide it for nodeset transforms. Additionally, there is some code in SnapManager that assumes only one editable path. It could be finished before the new year, but it could as well take another month.
Regards, Krzysztof
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, 26 Dec 2009 20:11:32 -0800, Josh Andler <scislac@...400...> wrote:
1 is important for me... have you asked diedrik for help with snapping?
Yes he did, and we already discussed this a bit.
I do not intend to offer his help, but if he is willing to give pointers
or
assist, I recommend talking with (and learning from) him.
And I can learn how the new node tool works, so there's a lot to learn for me too.
This is a big piece of community development,
It certainly is, looking at the feature set on our wiki! I will check out Krzysztof's branch and have a look.
Diederik
2009/12/26 Krzysztof Kosiński <tweenk.pl@...400...>:
Hello everyone.
Good news: there are only three regressions left in the new node tool now.
- Sculpting (Alt+drag) doesn't work.
This should not be too difficult to port. Didn't you do this only because of low priority or were there any obstacles?
- Transforming one handle using the keyboard (left/right Ctrl and Alt
- various keys) doesn't work
Perhaps, while we're changing everything else, we might want to change this UI as well - it's not very convenient. I have another idea:
* just [] rotates both handles
* Ctrl (any) with [] rotates the handle which is closer to the mouse cursor. This requires combined keyboard/mouse work but seems more intuitive.
What do you think?
W dniu 27 grudnia 2009 06:16 użytkownik bulia byak <buliabyak@...400...> napisał:
This should not be too difficult to port. Didn't you do this only because of low priority or were there any obstacles?
Yes, it is relatively straightforward to port, but snapping is a priority.
- just [] rotates both handles
This one already works
- Ctrl (any) with [] rotates the handle which is closer to the mouse
cursor. This requires combined keyboard/mouse work but seems more intuitive.
If we do it this way, the other handle might become closer to the mouse pointer during the transformation. So when repeatedly pressing Ctrl+] the user wold rotate one handle and then suddenly the other handle would start rotating.
My main problem with the old method is that which handle is "left" and which is "right" is not defined very well, if that could be disambiguated (maybe by highlighting the handle that would be affected when the modifier is pressed?) the old way could be used. Or we could drop this feature entirely: all those actions can be performed with the mouse and appropriate modifiers. (Less features is sometimes a good thing because there is less code to maintain.)
W dniu 27 grudnia 2009 09:51 użytkownik Diederik van Lierop <mail@...1689...> napisał:
So, If I understand this correctly, then it's now possible to transform nodes from different paths simultaneously?
Yes. The transformations are not limited to translation; it is now possible to also scale, rotate and skew selections of nodes.
Or, why can't we use _snapTransformed(), maybe with some small modifications? Or make a similar method specifically for transforming nodesets?
Yes, it might be possible to use this method, thanks for bringing it to my attention.
Regards, Krzysztof
participants (4)
-
bulia byak -
Diederik van Lierop -
Josh Andler -
Krzysztof Kosiński