Move Waypoints troubles

I’ve been working on this bug:
sourceforge.net/tracker/index.ph … tid=757416
It is easy to limit the waypoints movements to don’t allow to drag them outside the boundaries of the current start/end of time of the document.
See code here:
synfig.git.sourceforge.net/git/g … 8bd29e5343
But the question is: Do we should limit that? Should we allow the user to move waypoints far away from the project limits? My answer is no. If the user wants to move the waypoints out of the boundaries of the document then to recover them it is needed to expand the document time limits and get the moved waypoints back. Why don’t just expand the time window before and move the waypoints normally?
I would like to know someone’s else opinion on this.

Also I would like to have a quick way to modify the start/end of time of the document and also the start and end times of the render, without need to edit them in a dialogue. That could be for other occasion :wink:
-G

I agree – waypoints should snap to the ends of the timeline and not beyond.

And on anther day, it would be nice to be able to optionally snap to waypoints too.

You mean be able to place one waypoint one frame past/before the previous/next waypoint?
-G

I think it is a feature not a bug :mrgreen:

I say no.

I want waypoints after end of document. AND I want to be able to scroll timeline after end of document (and before start).

When animating it often a good idea to continue motion past last frame so you get a natural motion up to end frame. If you animate only to end frame and then abrubtly stops you have to figure out how to move up to end frame and make the impression that the motion continues. Much easier to actually continue the path of the motion.

As it is now I almost always add frames before and after the actual scene to be able to animate natural start and ends.

That is exactly what I want to express.

Hmmm… Now that you mention that (which is totally reasonably) I’m thinking on some alternative solutions:

  1. Don’t limit the timebar exploration from the start frame to the end frame. Allow the user to scroll left and right “indefinitely” (ahem). This must consider that there should be a quick way to re-center to the start of time of the canvas (usually 0f) to avoid manual scrolling when you’re accidentally so far away of the current animation. Also we have to limit the zoom out of the timeline to a reasonable value. Currently it zooms out to fit the start and end times to the time track window. That won’t be possible if there are not such limits. With this solution the user can always find any moved waypoint.

  2. Stay with the current behavior (allow user move waypoints away from start or end of time) and when any of the waypoint is out of the start or end times scope, then extend them to cover that waypoint. In this way, the document limits are limited (not “infinite”) but will allow the user move waypoints outside the limit without troubles.

  3. Create a widget that allows to define visually the start and end of render and the start and end of document and which could be easily modified by the user.

For me the easiest solution is the number 2). I would like to read your opinions on this again.

Thank you very much!
-G

  1. seems reasonable. It is a system that works. Anime Studio works like this.
    We would need a few extra controls; focus timeline on current frame and zoom in on project range. A limit in zoom level would be needed as you say.

  2. Could be good. But how do you create waypoints outside of the timeline? Step there blindly and then create a key to have the timeline extend to that frame?
    Wait, do you mean extend start and end points? - Not good for me. Keep document range separate from timeline range. I want to be able to create waypoint outside of range. If it just extends the range then that is pretty much exactly what I do already.

Some animation tools have this behaviour, Pencil if I remember correctly.

  1. Blender does it this way and it works very well.

So this looks like a new feature and not simply a bug killing. According to the plans for this period, I just will fix some bugs during a few days and then come back to finish Advanced Outline features.
I postpone this to other chance.
Thanks for the feed back! :slight_smile:
-G

sorry, I made a slip. I meant to say “optionally snap to keyframes” and even snap to integer times. That would be
for dragging waypoints and for dragging the current time. I often find my waypoints are +/- 1 frame from where they should be…

emphasis on the OPTIONALLY. for example by pressing ctrl as you drag.

Andrew