Personally I think the handling of path style attributes is quite a mess. Probably due to the strict svg useage concept.
They put too many options to one object in the specs which will always call for brute-force solutions by the user for a specific problem regardless how general that use case would be.

For example this topic raised a good point way off the spec's capability.
(On a side note, way off how drafting specifications define dashed lines.)
Or in general, how defining a stroke's custom dasharray is always in the percentage of the stroke width, and rendered as set only if the stroke is 1 px wide (?).

Custom markers are brute-force solutions for effects that should be way simpler to pull off.
Like this one, positionong a set of objects along a path without bending.
Or, to bend a gradient along a path,
which, "should be" as simple as switching the gradient fill to a gradient mesh, and bending that.

These use cases might not be easy programmatically but there are no options other than "draw manually" -(and which hardly equals "draw freely").

Yes, lpe-s can be a solution -hard-wired ones. There is no way a regular user could come up with a procedural drawing structure from scratch.
With an analogy lpe-s are the filter primitives you can rig together/put in a chain but there is no option on making one "filter primitive" from your own.

Like an option to design "dynamic blocks". As in msword, you have various drawing objects you can modify the shape by simple handles as you can do with the rectangle/star/ellipse tools.


This topic was related to that functionality.
Personally I wouldn't think it is a good idea to blot in alot of such custom shapes -and filters for that matter- but the ability to make your own and easy share/loading them in would be better. If you could make your own shapes, of course.

How would that be with the developers?
The mentioned rectangle/star/ellipse are using svg shapes, only the 3D box is a hard-wired, "inkscape specific" "dynamic block".
Meaning there is no 3D box svg element, and that you can modify it more or less, preserving its structure -with the tool's handles in the first place-.
Off specs features are not welcomed, everyone remembers the flowed text option.
Also would need a conceptual rethinking of the gui, which is not likely to happen any time in the near future (?).

My guess would be such a structure that svg provides /inkscape is using for lpe-s is limiting on the performance. From an "outsider" point of view the rendering is truncated between the defs section and the object's data and needs to rely storing too much temporary information.
In general I think there are parts where inkscape's main use is maxing out the svg specs limits, while others as animation or javascript are kept to a minimum.

brynn wrote:But for all those "quick shapes" options, it seems like an extension could provide that very easily. Open the extension, choose which shape you want, done.

Guess you are right that they could be generated by an extension taking in all the parametres and that you could switch to a live preview, taking more seconds for updating, and then you'd need to click another button.

And sometime it could even end up as a path effect for a live updating -but why on earth would you start by drawing a path to have live updating on a parametric object that looks nothing like the path it was added to?
Like the gears lpe or the ellipse by 5 points lpe? Practically seaking there they would be hidden and their use wouldn't be intuitive at all.