4:53 p.m.
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.
5:03 p.m.
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
5:14 p.m.
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.
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@...2927....>
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-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
5:20 p.m.
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@...3120.....
> > 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-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
>
>
5:37 p.m.
Hi,
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.
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.
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 <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
6:03 p.m.
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 <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
>
>
6:11 p.m.
> Thanks, that is a good explanation. However the wording "stroke to path"
isn't that clear to me.
Completely agree. I'd use "Stroke to Fill" in place of "Stroke to
Path".
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"?
When we talk about paths, we generally talk about them in terms of
base-shape
geometry; paths and nodes compose the shape geometry.
A "stroke" is the line thickness applied to the path. It can include a
thickness, as well as a myriad of cool Live Path Effects.
This is why the term "Stroke" is more descriptive than "path", and
why
Stroke to Fill is probably the easiest thing to wrap one's mind around
syntactically speaking. :)
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 ;)
Agree. The current behaviour of Stroke to Path has too many side-effects.
The result should be visually identical to the original with no
work-arounds needed.
This is precisely why we should replace the old behaviour with Jabier's.
>
> 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-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
>>
>>
>
5:34 p.m.
For me "Deconstruct" is just fine !
Le Samedi 7 mai 2016 9h54, Jabiertxo Arraiza Cenoz
<jabier.arraiza@...2359...893...> a écrit :
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
2514
days inactive
2514
days old
inkscape-devel@lists.inkscape.org
7 comments
5 participants
participants (5)
-
C R -
Ivan Louette -
Jabiertxo Arraiza Cenoz -
Olof Bjarnason -
Xaviju Julián