Proposal: stick to node or stick to segment
The concept is pretty simple: you take two nodes, you have them "stick" together (think snapping), and when you move the other node directly or indirectly (moving the whole object), the other node stuck to it moves along.
Same with segments. It basically makes a copy of that segment and its handles, and sticks all of them together.
Same with whole objects actually, I forgot that one, you "snap" the whole object onto a point.
Background: I mainly came up with the concept because I like (trying to) do drawings with complex strokes. The new LPE interface makes the complex strokes a lot easier, but if you actually want to fill anything in between, you have to edit the strokes And the fill (basically doubling the edit time).
Now, you Could tell me to just deal with it and/or delete the fill and make a new one, but it becomes a whole other story if Inkscape wants to include animation one day, so consider this a preliminary feature:
http://img373.imageshack.us/img373/2604/stickynodesja9.png
The problem is the interface. We could have a sub-mode of Edit, or a whole new tool, and of course we'll need shortcuts. Then for that new fill option, a new option would have to be added as well. I'm still pondering the matter (as well as the text tool interface), but maybe some of you have ideas already? This way at least we could discuss the blueprint. Maybe when Summer of Code 2009 comes around, some student would be interested and take up the whole thing! :)
Valerie schrieb:
The concept is pretty simple: you take two nodes, you have them "stick" together (think snapping), and when you move the other node directly or indirectly (moving the whole object), the other node stuck to it moves along.
I like this very much. Although you mentioned it in the context of animation, I believe something like this could be very favorable for tech drawing, too (unfortunately it is probably beyond the scope of GSoC).
This and a couple of other recent proposals make me think that in the future we really should be able to access individual nodes in a path. Bulia and Bob commented on my recent post on this topic (from 2008-05-21), but perhaps other people have further suggestions how this could best be implemented? I'm certain that it would open up a whole new world of possibilities, of which Valerie's proposal above is only one facet.
Max
I like this very much. Although you mentioned it in the context of animation, I believe something like this could be very favorable for tech drawing, too (unfortunately it is probably beyond the scope of GSoC).
Very good point! Actually, I was trying to think about your technical proposals too, but I admit technical drawing isn't really my field, so I have trouble with proposing workflow.
All I know is that it could use a line-command system at the bottom since apparently many CAD programs have that. Though I admit, my reaction to that has always been to stare blankly. Being able to type in specific coordinates and actions though is likely something at least Some users want sooner or later...
The BIG difficulty is this: implementing sticky nodes would release a whole can of worms. Suddenly people would want: - of the stickies, one of the objects is fixed size. - or one of the objects changes size with movement. - it changes one parameter but not another. - or it maintains a certain angle - some people will bring up colours sooner or later D: - or both objects move together in a certain way (think gears, bicycle chains, and other such nasties) - eventually people will likely want 3D too - and how in the world do you assign all those properties to those poor objects?
That's a whole lot of possibilities, and it will likely put a Huge strain on the interface.
Honestly, the sooner Inkscape implements a dynamic workspace interface (that you can change according to your function: Fonts, Icons, Technical, Charts, Illustration, Animation), the sooner these things will be less of a compromise between functionality and "not cluttering the interface."
It's really nice to think of all the potential Inkscape still has, but these are some very big steps Inkscape needs to take. I admit it sounds scary. :D
On Tue, Jun 10, 2008 at 12:16 PM, Valerie <valerie_vk@...36...> wrote:
The BIG difficulty is this: implementing sticky nodes would release a whole can of worms.
Just as aside, long ago Peter Moulder checked in some code which is supposed to allow objects to stick to guidelines and be moved when the guideline is moved. It required some changed deep in SPItem transform methods. I think by now this code is not functional, if it ever was.
On k, 2008-06-10 at 16:51 +0200, Maximilian Albert wrote:
Valerie schrieb:
The concept is pretty simple: you take two nodes, you have them "stick" together (think snapping), and when you move the other node directly or indirectly (moving the whole object), the other node stuck to it moves along.
I like this very much. Although you mentioned it in the context of animation, I believe something like this could be very favorable for tech drawing, too (unfortunately it is probably beyond the scope of GSoC).
It would be best if implemented as in Visio or Dia. (I think its called "smart shape")
The idea is simple. Attache a "snapping points" to a group. If you draw a line it would snap to this specific point. So you could define for a rectangle 8 snapping points (4 in the corner and another 4 in the middle of each edges). It would be really handy for diagramming especially if a box is not jusa box but a complex graphics with blur and image, and the snapping would become non-obvious. In that case you could just define some snapping points and the diagramming would be simple and easy and not time consuming.
If this idea is not clear (sorry for my english) I can draw a little mockup to better show it.
Best regards, Khiraly
It would be best if implemented as in Visio or Dia. (I think its called "smart shape")
The idea is simple. Attache a "snapping points" to a group. If you draw a line it would snap to this specific point. So you could define for a rectangle 8 snapping points (4 in the corner and another 4 in the middle of each edges). It would be really handy for diagramming especially if a box is not jusa box but a complex graphics with blur and image, and the snapping would become non-obvious. In that case you could just define some snapping points and the diagramming would be simple and easy and not time consuming.
Splendid! So we have a start of an interface proposal! The snapping points should be any node though. Maybe the nodes of a destination option can appear upon mouseover. Is it implemented as a separate tool or as an option in an existing one?
Just as aside, long ago Peter Moulder checked in some code which is supposed to allow objects to stick to guidelines and be moved when the guideline is moved. It required some changed deep in SPItem transform methods. I think by now this code is not functional, if it ever was.
Maybe it's a good start though! Is it still in there somewhere?
participants (4)
-
bulia byak -
khiraly -
Maximilian Albert -
Valerie