Collect Width params in one place.

There are width params under the individual vertexes that are used if you have individual line widths or have changed line width through width ducks. Then there is the Outline Width param in every shape that can be use to change the overall line width.

Why not make the individual vertex width parameters children of the Outline Width parameter?
You could then work on them all together.

As it is now if you have keyframes and decides to change line widths and use individual vertex widths to get a nice looking line you have to go through all vertexes one by one and delete the keyframe values so the line is not animated into it’s old shape. This is very tedious work.
If they were children of the Outline Width parameter you could change the line in first keyframe then just delete the rest of the waypoints together in one go, without having to go through them vertex by vertex…

They could probably also be left in each individual vertex and have them linked to children of Outline Width (?) for those who like them the way they are.

It might be a good suggestion from a user standpoints, but I don’t think it fits well with Synfig’s internal structure. If we have a paradigm of “every point has an individual width”, then it makes sense to have the width as a sub-parameter of a point. Moving the widths out to their own parameters could generate a lot of problems. For example, it makes linking points+width much harder. Also consider what will happen if the vertex list and width lists somehow end up with a different number of elements.

Your problem, I think, needs a different solution. If the line widths aren’t animated, they can be edited outside of animation mode. If they are, maybe you could suggest some improvements to the keyframe locking features.

Alternatively, it may be that we should dispense with the concept of “one width per point” and instead adopt the convention of being able to set the width at any distance along the bline (that is, merge in genete’s “wline” developments)

I’m decided to re start the “wline” development for the next release. In that new outline layer the blinepoints won’t have a width associated. To control the widths there will be a list of width control points that will have these data:
-width (real number)
-position of the width along the bline (real number clamped to [0,1))
-type of width (integer)

This new outline would allow:
-Width points can slide along the bline using the animation of the position parameter.
-Create multiple section of outlines along the same bline with the same layer, thanks to the parameter width type. Types are:
*Interpolation: produces continuity between width points
*Stop type (rounded, arrow, square): produces a outline stop between two width points.
-Selectable start/and end types of outline section (rounded, square, arrow, etc.)
-Draw tool will have an additional control for widths smoothness. As blinepoints are not holder of widths there are two smooth parameters to control, one for blinepoints positions and other for width points positions.
-Width Tool should change to handle the new layer.

-G

So it’s better to have a pragmatic software rather than one thats easier to use?

Sound great! That seems to be an awesome feature.

What I’m saying is that if there is a problem with usability, I prefer to modify the user interface, not the internal document structure. From an implementation viewpoint, making the changes you suggested would require touching existing layers, the rendering system, the UI, possibly some actions, and ensuring backwards-compatibility for everything. A UI solution isn’t always available (for example the “wline” features cannot possibly be replicated in the current system), but if it exists is will most likely be the better option.

I’m under the impression that the crux of your problem is that keyframes are created where they shouldn’t be, which leads me to believe that the keyframing system is the place to look for a fix. For example, turning off the keyframe lock or entering a “create-no-new-waypoints” mode may satisfy your needs. Even if your suggestion is implemented or “wline” causes the problem to go away, without an improved keyframe/waypoint system the same problem might reappear for a different layer or situation.