On 4/4/07, Bill Baxter <wbaxter@...155...> wrote:
If you haven't seen Takeo Igarashi's work on animation, it's very slick. http://www-ui.is.s.u-tokyo.ac.jp/~takeo/research/rigid/index.html this one's mostly 3D but the same concepts apply to 2D http://www-ui.is.s.u-tokyo.ac.jp/~takeo/research/squirrel/index.html
Thanks for the interesting links. Using internal triangulation for more natural manipulation of paths is an idea that already occurred to me.
Try the Pattern along Path effect
Hmm, that just made an axis aligned texture along the path for me. So trying to apply a little pencil texture (approx 8px x 64px) to a previously drawn curve just resulted in a curve horizontally striped with my pencil texture. Maybe I wasn't using the right modes for Pattern along Path?
Not "Convert object to pattern", but Effects > Generate from Path > Pattern along Path:
http://inkscape.org/screenshots/gallery/inkscape-0.45-patternalongpath.png
Spirals on the other hand... well the tutorials didn't have much to say other than "these aren't as useful as stars".
Yet they are useful in design. I used them (at least) several times in real projects. And they are VERY hard to do manually unless you have a tool for them.
Panning the canvas is much easier by middle mouse button - no need to touch keyboard at all.
My laptop doesn't have a middle button.
Ctrl+right button works just as well. Ctrl+arrows are also very handy.
Actully, this has already been proposed many times by former Adobe users who are used to space-for-panning. My official stand on it always was: if someone implements this as an option (off by default), we will accept the patch. You need it, you code it :)
Oooh. That's encouraging. I'd like to look into it. I got the source compiling this morning. Is the basic infrastructure for handling temporary toggles in the input system there currently? That would be step one. Or actually... now that I think about it, step one would probably be to implement a grabbing hand tool, period, since there doesn't seem to be one.
A separate tool is not _really_ necessary - IMHO it will be just a waste of precious toolbar space. But it's just an IMHO, maybe we'll have to have it just to look more friendly to Adobe refuges. But, separate tool or not, the functionality itself must be in event-context.cpp which is the superclass of all event contexts (tools), so that it can be done in any tool without actual switching the tool internally (even though it may _look_ like tool switching to the user). The reason for that is that switching a tool is expensive - it means destroying the old event context object and instantiating a new one, and what's worse, it loses tool state and tool-specific selection (such as text selection in text tool or selected nodes in Node tool), and also removes the screen handles of the old tool which redraws parts of the screen and may be slow in complex documents. So, the processing of Space and the panning code must all be in event-context.cpp, so that each event context has its own copy of the code and can pan on Space without switching away from the current tool. (By the way the middle-click and ctrl+arrow panning is also in event-context.cpp, for the same reasons.) Whether we'll also get a new top-level tool button for Hand and whether the UI should show its button depressed on Space (which would necessarily be "fake" because the tool will not be actually switched) is up to the implementor; I would prefer to not have the tool button, but if we do have it, to not have it pressed when you press Space in another tool.
By the way, the same reasoning applies to our Dropper tool which is used for picking a color from the drawing. It is currently a separate tool, but it is most often used from within other tools, so this is inconvenient for all the same reasons (slow switch, losing selection, etc). So the current plan is to move the corresponding code from dropper-context.cpp to event-context.cpp and make it work in all tools (upon pressing F7) without switching. The Dropper tool button and context will likely remain, but it will just use the code from event-context parent. If you are interested in helping out, this might be a good next project after you implement the Space-panning :)
Watch the selected style indicator in the statusbar. It's quite informative showing you at a glance the fill, stroke, and opacity of the selected object (though currently not blur). Textual description in the statusbar is also very useful.
I see. That is somewhat better than nothing at all. But it seems like it might be common to get just "unset" as the value there if you have lots of clones. (I was just trying the technique out on the "keys.svg" file).
If you're working with clones, yes. But then just press Shift+D to jump to the original and see its style (which will be the style of the clone as well).