As far as I can understand from all this what it does is create a polygon from the outline of a stroke. If so wouldn't "outline from stroke", "path from stroke" or "stroke to filled path" not be a better description? Would also be nice if that could happen without destroying the original. The "deconstruct object" sounds more like cutting a path to ribbons from node to node. Something like "segmentate path" might actually be quite handy come to think of it. In combination with a "weld nodes" that is. True, is obtainable with the node editor as well but I like those one click options without keyboard switches. If the circle has no stroke, it is no more than logical it disappears. Cheers, Jelle > > Message: 2 > Date: Sat, 7 May 2016 03:36:19 -0600 > From: "Brynn" <brynn@...3133...> > Subject: Re: [Inkscape-devel] [UI] Name for a new function > To: "Inkscape-Devel" <inkscape-devel(a)lists.sourceforge.net&gt; > Message-ID: <B40A8BBF0C4A40EF9E338A385BCE416B@...3282...> > Content-Type: text/plain; format=flowed; charset="utf-8"; > reply-type=original > > Seeing how it works would help understanding. From a simple user: > > "deconstruct object" sounds like breaking up any object to individual > pieces, maybe like Ungroup, or Break Apart. And I can't imagine how > "stroke > to fill" fits with either of those. ("stroke to fill" sounds like some > kind > of a stripe pattern) > > All best :-) > brynn > > ____________________________ > From: C R > Sent: Saturday, May 07, 2016 3:13 AM > To: Olof Bjarnason > Cc: Inkscape Devel List > Subject: Re: [Inkscape-devel] [UI] Name for a new function > > > Yes please draw some use case diagrams. > (And I like the renaming too. I'm still much more of a user than a > developer > of inkscape and that name (stroke to path) has annoyed me for years!) > > > Will do! And yes, I'm going to recommend renaming it as well. It's always > been a bit of a sticking point in my head as well. > > > -C > > > > On 7 May 2016 11:03, "C R" <cajhne@...400...> wrote: > > I think stroke to path is already a naming convention for a very similar > functionality, so I will keep this name if possible if the feature is not > too different. If a user will receive most of the time the same result I > will try to keep it to avoid confusion. Having too many features with > similar behaviours could be frustrating. > > > Agreed. This is my main reason for proposing a modification to the > behaviour > of Stroke to Path (We can think about renaming it later, however that > may be > confusing to our current user base. As a daily user, I'm all for > changing it > to "Strike to Fill", which is what Stroke to Path actually does. > > I would strongly suggest not to create a new menu option if the > behaviour is > not too different from the expected one if we think the users are going > to > keep using it as they were doing before. > > > To clarify: > 1. Make a red circle with a black stroke > 2. Path > Stroke to Path > > > Watch the red circle vanish > > > Note that I didn't ask Inkscape to throw away the fill, it just does it > because there is no shape to contain it anymore. > Since we have Paint Order in trunk now, this is even more of an issue; > you > don't want Stroke to Path to throw away everything you did to make that > shape look the way it is, which may include a stack of LPEs and markers, > not > to mention the fill may include a complex gradient that you have to copy > and > paste-in-place to recover. The way it has worked has always been a major > workflow bottleneck, and Jabier's new function fixes the problem > entirely. > > > Would folks like to see some use case and work flow diagrams? > If so, I can have them ready tomorrow. > > > -C > > > > > > > > > > Otherwise, reading the feature explanation, "decompose object" or > "deconstruct object"sounds self-explanatory to me. > > > I don't have an answer, but I would raise some questions about how we > think > it is going to be used: what is the purpose, what is the expected outcome > and I would compare to the stroke to path option to ensure that are > enough > different. > > > :) > > > > On Sat, May 7, 2016 at 10:20 AM, Olof Bjarnason > <olof.bjarnason@...400...> > wrote: > > > > > > > > > > Mvh > > > > > /Olof > ----------------- > ?r du systemutvecklare? > Spana in https://cilamp.se > > > > > On 7 May 2016 at 10:14, C R <cajhne@...400...> wrote: > > Basicly, this is how Stroke to Fill should work. > > > How it works now: > Ctrl+Alt+C > Stroke to Path > > > Result: stroke is indeed converted to path, but the fill and all other > parts > of the selection that are not strokes vanish. If any LPEs are applied to > the > path they are thrown out as well (you need to convert object to path > before > this operation to preserve the appearance). > > > > > How it should work (this "deconstruct" alternative): > Ctrl+Alt+C > Stroke to Path > > > Result: All LPE's applied to stroke, then the stroke is converted to > path. > > > My thought is, if we use the convention that a fill is only turned into > an > object if there is a fill set on the object, then we can please anyone > who > prefers the old behaviour. All they have to do is get rid of the fill > colour > on the object before applying Stroke to Path. > > > The current way it's handled is counter-intuitive. Most of the time, all > you > want to do is convert the outline to a fill, not throw away tons of data. > The point is to preserve appearance, and the Jabier's new function does > this > much much better. > > > Thanks, that is a good explanation. However the wording "stroke to path" > isn't that clear to me. > > > Now that I understand what is going on I think "deconstruct" is actually > a > quite good albeit little techy word for the operation. "Decompose"? > "Path to > fills"? > > > The end result is a bunch of filled paths, and the input is what > exactly? I > think "X to Y" is a good but then the X and the Y should be closer to > what > the operation is actually doing ;) > > > > > > My 2p. > -C > > > > > > > > > > > > > On Sat, May 7, 2016 at 9:03 AM, Olof Bjarnason <olof.bjarnason@...400...> > wrote: > > Is there any image giving an example of what the command does...? Like > before/after with arrows and descriptive text? > > > It's kind of hard to understand what is happening from the very brief > description at the top of that thread... > > > > > > > Mvh > > > > > /Olof > ----------------- > ?r du systemutvecklare? > Spana in https://cilamp.se > > > > > On 7 May 2016 at 09:53, Jabiertxo Arraiza Cenoz > <jabier.arraiza@...2893...> > wrote: > > Hi to all UI power! > I Just to know a name for the patch https://bugs.launchpad.net/inkscape > /+bug/1556592 > > See the ScislaC proposal on #5 > Bryce like "Deconstruct object", me too. > > Is ok the name? Another one? > > Cheers, Jabier. > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications > Manager > Applications Manager provides deep performance insights into multiple > tiers > of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications > Manager > Applications Manager provides deep performance insights into multiple > tiers > of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > > > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications > Manager > Applications Manager provides deep performance insights into multiple > tiers > of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > > > > > > > > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications > Manager > Applications Manager provides deep performance insights into multiple > tiers > of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > > > > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > > > > ------------------------------ > > Message: 3 > Date: Sat, 07 May 2016 11:53:57 +0200 > From: Jabiertxo Arraiza Cenoz <jabier.arraiza@...2893...> > Subject: Re: [Inkscape-devel] [UI] Name for a new function > To: C R <cajhne@...400...>, Olof Bjarnason <olof.bjarnason@...400...> > Cc: Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net&gt; > Message-ID: <1462614837.14732.13.camel@...2893...> > Content-Type: text/plain; charset="utf-8" > > I just read the thread. > Olof, the new feature convert the selected items to paths, maybe groups > if have more than one propertye o fill|stroke|marker. > It also retain new paint order. > > So I try to solve one question and now have more :) > In the meet with Josh in IRC he tell is better retain the old stroke to > path (?renaming it?) to old users and add a new item (down stroke to > path) to ?deconstruct object? > > In my point of view, personal only, I think a feature to convert a > "stroke to fill/path" is unnecesary, because "deconstruct object" do > the same with objects with only strokes/markers. > > Cheers, Jabier. > > > El s?b, 07-05-2016 a las 10:13 +0100, C R escribi?: >> > >> > >> > Yes please draw some use case diagrams. >> > >> (And I like the renaming too. I'm still much more of a user than a >> > >> > developer of inkscape and that name (stroke to path) has annoyed me >> > for >> > years!) >> > >> Will do! And yes, I'm going to recommend renaming it as well. It's >> always >> been a bit of a sticking point in my head as well. >> >> -C >> >> >> >> > >> > On 7 May 2016 11:03, "C R" <cajhne@...400...> wrote: >> > >> > I think stroke to path is already a naming convention for a very >> > similar >> > > >> > > functionality, so I will keep this name if possible if the >> > > feature is not >> > > too different. If a user will receive most of the time the same >> > > result I >> > > will try to keep it to avoid confusion. Having too many features >> > > with >> > > similar behaviours could be frustrating. >> > > >> > Agreed. This is my main reason for proposing a modification to the >> > behaviour of Stroke to Path (We can think about renaming it later, >> > however >> > that may be confusing to our current user base. As a daily user, >> > I'm all >> > for changing it to "Strike to Fill", which is what Stroke to Path >> > actually >> > does. >> > >> > >> > > >> > > I would strongly suggest not to create a new menu option if the >> > > behaviour >> > > is not too different from the expected one if we think the users >> > > are going >> > > to keep using it as they were doing before. >> > > >> > To clarify: >> > 1. Make a red circle with a black stroke >> > 2. Path > Stroke to Path >> > >> > Watch the red circle vanish >> > >> > Note that I didn't ask Inkscape to throw away the fill, it just >> > does it >> > because there is no shape to contain it anymore. >> > Since we have Paint Order in trunk now, this is even more of an >> > issue; you >> > don't want Stroke to Path to throw away everything you did to make >> > that >> > shape look the way it is, which may include a stack of LPEs and >> > markers, >> > not to mention the fill may include a complex gradient that you >> > have to >> > copy and paste-in-place to recover. The way it has worked has >> > always been a >> > major workflow bottleneck, and Jabier's new function fixes the >> > problem >> > entirely. >> > >> > Would folks like to see some use case and work flow diagrams? >> > If so, I can have them ready tomorrow. >> > >> > -C >> > >> > >> > >> > >> > >> > > >> > > >> > > >> > > Otherwise, reading the feature explanation, "decompose object" or >> > > "deconstruct object"sounds self-explanatory to me. >> > > >> > > I don't have an answer, but I would raise some questions about >> > > how we >> > > think it is going to be used: what is the purpose, what is the >> > > expected >> > > outcome and I would compare to the stroke to path option to >> > > ensure that are >> > > enough different. >> > > >> > > :) >> > > >> > > On Sat, May 7, 2016 at 10:20 AM, Olof Bjarnason <olof.bjarnason@...1354... >> > > mail.com >> > > > >> > > > wrote: >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > Mvh >> > > > >> > > > >> > > > /Olof >> > > > ----------------- >> > > > ?r du systemutvecklare? >> > > > Spana in https://cilamp.se >> > > > >> > > > >> > > > On 7 May 2016 at 10:14, C R <cajhne@...400...> wrote: >> > > > >> > > > > >> > > > > Basicly, this is how Stroke to Fill should work. >> > > > > >> > > > > How it works now: >> > > > > Ctrl+Alt+C > Stroke to Path >> > > > > >> > > > > Result: stroke is indeed converted to path, but the fill and >> > > > > all other >> > > > > parts of the selection that are not strokes vanish. If any >> > > > > LPEs are applied >> > > > > to the path they are thrown out as well (you need to convert >> > > > > object to path >> > > > > before this operation to preserve the appearance). >> > > > > >> > > > > >> > > > > How it should work (this "deconstruct" alternative): >> > > > > Ctrl+Alt+C > Stroke to Path >> > > > > >> > > > > Result: All LPE's applied to stroke, then the stroke is >> > > > > converted to >> > > > > path. >> > > > > >> > > > > My thought is, if we use the convention that a fill is only >> > > > > turned into >> > > > > an object if there is a fill set on the object, then we can >> > > > > please anyone >> > > > > who prefers the old behaviour. All they have to do is get rid >> > > > > of the fill >> > > > > colour on the object before applying Stroke to Path. >> > > > > >> > > > > The current way it's handled is counter-intuitive. Most of >> > > > > the time, >> > > > > all you want to do is convert the outline to a fill, not >> > > > > throw away tons of >> > > > > data. The point is to preserve appearance, and the Jabier's >> > > > > new function >> > > > > does this much much better. >> > > > > >> > > > Thanks, that is a good explanation. However the wording "stroke >> > > > to path" >> > > > isn't that clear to me. >> > > > >> > > > Now that I understand what is going on I think "deconstruct" is >> > > > actually >> > > > a quite good albeit little techy word for the operation. >> > > > "Decompose"? "Path >> > > > to fills"? >> > > > >> > > > The end result is a bunch of filled paths, and the input is >> > > > what >> > > > exactly? I think "X to Y" is a good but then the X and the Y >> > > > should be >> > > > closer to what the operation is actually doing ;) >> > > > >> > > > >> > > > >> > > > > >> > > > > >> > > > > My 2p. >> > > > > -C >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > On Sat, May 7, 2016 at 9:03 AM, Olof Bjarnason < >> > > > > olof.bjarnason@...400...> wrote: >> > > > > >> > > > > > >> > > > > > Is there any image giving an example of what the command >> > > > > > does...? Like >> > > > > > before/after with arrows and descriptive text? >> > > > > > >> > > > > > It's kind of hard to understand what is happening from the >> > > > > > very brief >> > > > > > description at the top of that thread... >> > > > > > >> > > > > > >> > > > > > >> > > > > > Mvh >> > > > > > >> > > > > > >> > > > > > /Olof >> > > > > > ----------------- >> > > > > > ?r du systemutvecklare? >> > > > > > Spana in https://cilamp.se >> > > > > > >> > > > > > >> > > > > > On 7 May 2016 at 09:53, Jabiertxo Arraiza Cenoz < >> > > > > > jabier.arraiza@...2893...> wrote: >> > > > > > >> > > > > > > >> > > > > > > Hi to all UI power! >> > > > > > > I Just to know a name for the patch >> > > > > > > https://bugs.launchpad.net/inkscape/+bug/1556592 >> <https://bugs.launchpad.net/inkscape/+bug/1556592> >> > > > > > > >> > > > > > > See the ScislaC proposal on #5 >> > > > > > > Bryce like "Deconstruct object", me too. >> > > > > > > >> > > > > > > Is ok the name? Another one? >> > > > > > > >> > > > > > > Cheers, Jabier. >> > > > > > > >> > > > > > > ------------------------------------------------------- >> > > > > > > ----------------------- >> > > > > > > Find and fix application performance issues faster with >> > > > > > > Applications >> > > > > > > Manager >> > > > > > > Applications Manager provides deep performance insights >> > > > > > > into multiple >> > > > > > > tiers of >> > > > > > > your business applications. It resolves application >> > > > > > > problems quickly >> > > > > > > and >> > > > > > > reduces your MTTR. Get your free trial! >> > > > > > > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >> > > > > > > _______________________________________________ >> > > > > > > Inkscape-devel mailing list >> > > > > > > Inkscape-devel(a)lists.sourceforge.net >> > > > > > > https://lists.sourceforge.net/lists/listinfo/inkscape-dev >> > > > > > > el >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > --------------------------------------------------------- >> > > > > > --------------------- >> > > > > > Find and fix application performance issues faster with >> > > > > > Applications >> > > > > > Manager >> > > > > > Applications Manager provides deep performance insights >> > > > > > into multiple >> > > > > > tiers of >> > > > > > your business applications. It resolves application >> > > > > > problems quickly >> > > > > > and >> > > > > > reduces your MTTR. Get your free trial! >> > > > > > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >> > > > > > _______________________________________________ >> > > > > > Inkscape-devel mailing list >> > > > > > Inkscape-devel(a)lists.sourceforge.net >> > > > > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >> > > > > > >> > > > > > >> > > > >> > > > ------------------------------------------------------------- >> > > > ----------------- >> > > > Find and fix application performance issues faster with >> > > > Applications >> > > > Manager >> > > > Applications Manager provides deep performance insights into >> > > > multiple >> > > > tiers of >> > > > your business applications. It resolves application problems >> > > > quickly and >> > > > reduces your MTTR. Get your free trial! >> > > > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >> > > > _______________________________________________ >> > > > Inkscape-devel mailing list >> > > > Inkscape-devel(a)lists.sourceforge.net >> > > > https://lists.sourceforge.net/lists/listinfo/inkscape-devel >> > > > >> > > > >> ------------------------------------------------------------------- >> ----------- >> Find and fix application performance issues faster with Applications >> Manager >> Applications Manager provides deep performance insights into multiple >> tiers of >> your business applications. It resolves application problems quickly >> and >> reduces your MTTR. Get your free trial! >> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z >> _______________________________________________ >> Inkscape-devel mailing list >> Inkscape-devel(a)lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/inkscape-devel >