Re: [Inkscape-devel] [UI] Name for a new function

7 May 2016

      ...

Re: [UI] Name for a new function (Brynn)
Re: [UI] Name for a new function (Jabiertxo Arraiza Cenoz)

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@lists.sourceforge.net
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:

Make a red circle with a black stroke
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@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@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@lists.sourceforge.net
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:

Make a red circle with a black stroke
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@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@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@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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Re: [Inkscape-devel] [UI] Name for a new function

jelle

/Olof

/Olof

/Olof