I'd like to avoid muddying up the simplicity of the one click stroke to path with extra options. Adding options would require a switch somewhere, or a popup dialog.

Imho, our current methods for user interaction with clones has been clunky at best. Just noticed that the bug wishlist item says that the marker strokes are also converted to fills...

However, since there is no other way (that I know of) to convert markers to clones, maybe we should include that as a separate function "Markers to Clones", and allow Stroke To Path to convert all the strokes in the object to path (including the markers), which I think is the expected behaviour in most cases where you are using Stroke to Path.

Would we like to see some more use-case analysis for scenarios involving markers in regards to different options for handling them?

Another way to handle it is that when the function Stroke to Path is complete, the markers are converted to clones, grouped, and them highlighted, so the user has the option to run the command again to convert the marker strokes to paths/fills as well.

The logic:

User wants to convert strokes to paths in a markered object (probably rare)

User runs Stroke to Path, stroke to Path does all of the following in sequence:

a. Stroke to path converts all base object strokes to paths, as per new function

b. Stroke to path them groups all objects which are not included in previous action and selects them so the user knows they have been broken off of the base object, but not converted to fills yet.

c. User them has the option to run stroke to path on the highlighted/selected objects instantly.


Thoughts?

-C






-C


On 17 May 2016 2:48 am, "Josh Andler" <scislac@...1063....> wrote:
On Sat, May 14, 2016 at 1:20 PM, C R <cajhne@...400...> wrote:
> I tend to agree with this, even though it's not the default behaviour
> currently.
> Mainly because I want as few side-effects as possible in this action, and
> it's far easier to unlink the clones rather than link them all together
> again.
> Maybe we should group them together as well so they can be unlinked all at
> once if necessary?

While I'm not sure I agree with adding in clones to the mix, if that
were the case I would agree that they should be grouped... but I
honestly think it should be optional behavior to not take everything
down to paths.

Cheers,
Josh