Paint-order attribute needs to be put in stroke properties dialogue
We need a checkbox for it in the stroke properties tab. Currently I think it's a compile-time flag, which means it's unusable for most users.
I'd love to highlight this feature in the Inkscape video at LGM.
Can someone add this?
For reference as to what it does, look here: https://plus.google.com/+inkscape/posts/QBxB6CDhNzZ
Thanks. :)
-C
We need a checkbox for it in the stroke properties tab.
I think we need more than a checkbox. Anyway I have a question to simplify the final UX developer implementer:
Is a problem the "paint-order" always have three values in selected order -fill, strokes and marker- if edited in the UI?
Cheers, Jabier.
On Sun, 2016-03-06 at 17:10 +0000, C R wrote:
We need a checkbox for it in the stroke properties tab. Currently I think it's a compile-time flag, which means it's unusable for most users.
I'd love to highlight this feature in the Inkscape video at LGM.
Can someone add this?
Inkscape trunk supports rendering of the 'paint-order' property. It is not behind a compiler flag. I didn't add a GUI as it wasn't widely supported by other SVG renderers. You can add it using the XML editor. I would not appose someone adding it to the GUI. Both Firefox and Chrome support it now. The other two major browsers are quite slow in updating. And in the case of Edge, unless they see it being used, they are unlikely to implement it. If it is something we want then we need to be the egg and get content out there that does use it. Tav
Well, you know my vote. :) I say we add it to the UI.
Inkscape pioneering adherence to SVG 2.0 is not really anything new... however if Chrome and Firefox support it already, it's already well supported imho.
Correct if I'm wrong, but the paint order applies to only three things: Fill, Stroke, and Markers.
The default is Fill frist, stroke second, markers third.
For me, there is only one other order than makes any sense:
Stroke First, Fill Second, markers third.
I can't envision any situation where you wouldn't want markers drawn over the top of the shape, so I recommend just two icons:
The default state: http://www.opendesignstudio.org/inkscape/paint_order_feature_default_state.p...
And the Stroke Under Fill State: http://www.opendesignstudio.org/inkscape/paint_order_feature_stroke_under_st...
The default can be the same as it's always been if we want to maintain the status quo. Note the red triangle appears when the "stroke under fill" option is selected. If the user mouses over this the tooltip can read something like: "Currently only supported by some browsers".
Thoughts?
-C
On Sun, Mar 6, 2016 at 7:37 PM, Tavmjong Bah <tavmjong@...8...> wrote:
On Sun, 2016-03-06 at 17:10 +0000, C R wrote:
We need a checkbox for it in the stroke properties tab. Currently I think it's a compile-time flag, which means it's unusable for most users.
I'd love to highlight this feature in the Inkscape video at LGM.
Can someone add this?
Inkscape trunk supports rendering of the 'paint-order' property. It is not behind a compiler flag. I didn't add a GUI as it wasn't widely supported by other SVG renderers. You can add it using the XML editor.
I would not appose someone adding it to the GUI. Both Firefox and Chrome support it now. The other two major browsers are quite slow in updating. And in the case of Edge, unless they see it being used, they are unlikely to implement it. If it is something we want then we need to be the egg and get content out there that does use it.
Tav
Am Sonntag, 6. März 2016, 21:48:32 schrieb C R:
[...]
I can't envision any situation where you wouldn't want markers drawn over the top of the shape, so I recommend just two icons:
The problem is, what when a document is loaded with another order? How should the GUI reflect that?
[...]
Tobias
Note the red triangle appears when the "stroke under fill" option is selected. If the user mouses over this the tooltip can read something like: "Currently only supported by some browsers".
Thinking about this design I figure we could create a much nicer layout with:
https://inkscape.org/en/~doctormo/%E2%98%85paint-order-design
I've re-ordered the items here so they collate into a nice 3x3 grid. And attempted to reuse the style of the other icons.
I believe having three of the possible six as common buttons will be useful for a few reasons. 1. it allows us to iconify the option, so showing users unfamiliar with paint order what this means. 2. It cuts down on what would be really verbose drop-down or more complex ui element 3. It won't cause too much choice anxiety and 4. it looks aesthetic.
Martin,
Thinking about this design I figure we could create a much nicer layout with:
https://inkscape.org/en/~doctormo/%E2%98%85paint-order-design
I've re-ordered the items here so they collate into a nice 3x3 grid. And attempted to reuse the style of the other icons.
Looks good to me. I still don't know why people would want to hide the markers behind the shape, however. Do we want the potential confusion it might cause people reading in the document elsewhere? Do we want to offer up a button that will allow this undesirable thing to happen more regularly?
I agree about the aesthetics, though. It does look nicer.
-C
Martin,
On Mon, 2016-03-07 at 01:36 -0500, Martin Owens wrote:
Note the red triangle appears when the "stroke under fill" option is selected. If the user mouses over this the tooltip can read something like: "Currently only supported by some browsers".
Thinking about this design I figure we could create a much nicer layout with:
https://inkscape.org/en/~doctormo/%E2%98%85paint-order-design
I've re-ordered the items here so they collate into a nice 3x3 grid. And attempted to reuse the style of the other icons.
I believe having three of the possible six as common buttons will be useful for a few reasons. 1. it allows us to iconify the option, so showing users unfamiliar with paint order what this means. 2. It cuts down on what would be really verbose drop-down or more complex ui element 3. It won't cause too much choice anxiety and 4. it looks aesthetic.
I like the reordered layout although it does rely on a tooltip to explain the use of the miter-length selector.
You never know what uses people will find for putting markers behind the stroke so I would just go ahead and put icons for all six combinations (two rows of three), making the marker in the icon a bit larger so it sticks out.
Tav
You never know what uses people will find for putting markers behind the stroke so I would just go ahead and put icons for all six combinations (two rows of three), making the marker in the icon a bit larger so it sticks out.
True. I recommend putting the three suggested by Martin on top, though.
-C
On Mon, 2016-03-07 at 09:01 +0100, Tavmjong Bah wrote:
I like the reordered layout although it does rely on a tooltip to explain the use of the miter-length selector.
You never know what uses people will find for putting markers behind the stroke so I would just go ahead and put icons for all six combinations (two rows of three), making the marker in the icon a bit larger so it sticks out.
That's true, I've made a draft stab at some actual icons here:
https://inkscape.org/en/~doctormo/%E2%98%85paint-order-icons
If anyone wants to have a crack at it, these ones are based on the strait line and the order of the items is the order they paint. So it should signify the effect pretty clearly.
Martin,
Am 07.03.2016 um 17:53 schrieb Martin Owens:
If anyone wants to have a crack at it, these ones are based on the strait line and the order of the items is the order they paint. So it should signify the effect pretty clearly.
Actually I'd keep a constant order (and also size and position) of all items and just change the layering...
The idea to use item order to visualize paint order is nice, but it's too hard to figure out what stroke and fill are when items are moving around (especially given the small size), so the intended effect is not achieved and it actually gets harder to figure out the paint order.
Regards, Eduard
JFYI, I've almost finished implementing a GUI for paint-order.
Tav
On Mon, 2016-03-07 at 18:12 +0100, Eduard Braun wrote:
Am 07.03.2016 um 17:53 schrieb Martin Owens:
If anyone wants to have a crack at it, these ones are based on the strait line and the order of the items is the order they paint. So it should signify the effect pretty clearly.
Actually I'd keep a constant order (and also size and position) of all items and just change the layering...
The idea to use item order to visualize paint order is nice, but it's too hard to figure out what stroke and fill are when items are moving around (especially given the small size), so the intended effect is not achieved and it actually gets harder to figure out the paint order.
Regards, Eduard
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
JFYI, I've almost finished implementing a GUI for paint-order.
Tav
Neat... what does it look like? :D Do you still need icons for it? Does the implementation use icons? :)
-C
On Mon, 2016-03-07 at 18:12 +0100, Eduard Braun wrote:
Am 07.03.2016 um 17:53 schrieb Martin Owens:
If anyone wants to have a crack at it, these ones are based on the strait line and the order of the items is the order they paint. So it should signify the effect pretty clearly.
Actually I'd keep a constant order (and also size and position) of all items and just change the layering...
The idea to use item order to visualize paint order is nice, but it's too hard to figure out what stroke and fill are when items are moving around (especially given the small size), so the intended effect is not achieved and it actually gets harder to figure out the paint order.
Regards, Eduard
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Here's my stab at a complete set of icons, the style consistent with the ones above (maybe something other than red for a fill though).
http://www.opendesignstudio.org/inkscape/paint_order_feature_icons.png
I think it helps to have "markers" that remind the user what "markers" are, which is why I included two. Visually, this is a bit easier to sort through than just the edge of the line and a single marker, I think.
Thoughts? -C
On Mon, Mar 7, 2016 at 6:55 PM, C R <cajhne@...400...> wrote:
JFYI, I've almost finished implementing a GUI for paint-order.
Tav
Neat... what does it look like? :D Do you still need icons for it? Does the implementation use icons? :)
-C
On Mon, 2016-03-07 at 18:12 +0100, Eduard Braun wrote:
Am 07.03.2016 um 17:53 schrieb Martin Owens:
If anyone wants to have a crack at it, these ones are based on the strait line and the order of the items is the order they paint. So it should signify the effect pretty clearly.
Actually I'd keep a constant order (and also size and position) of all items and just change the layering...
The idea to use item order to visualize paint order is nice, but it's too hard to figure out what stroke and fill are when items are moving around (especially given the small size), so the intended effect is not achieved and it actually gets harder to figure out the paint order.
Regards, Eduard
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I find these to be much more easily understandable, thank you, CR! Having them go around a corner helps.
But maybe both markers should be identical as they would be in reality? Arrows are easier to understand as being a symbol for a 'marker' than the dots, at least for me. If the markers could be made bigger (not by much), it could be easier to spot the difference between some of the icons.
Maren
Am 07.03.2016 um 20:42 schrieb C R:
Here's my stab at a complete set of icons, the style consistent with the ones above (maybe something other than red for a fill though).
http://www.opendesignstudio.org/inkscape/paint_order_feature_icons.png
I think it helps to have "markers" that remind the user what "markers" are, which is why I included two. Visually, this is a bit easier to sort through than just the edge of the line and a single marker, I think.
Thoughts? -C
On Mon, Mar 7, 2016 at 6:55 PM, C R <cajhne@...400... mailto:cajhne@...400...> wrote:
JFYI, I've almost finished implementing a GUI for paint-order. Tav Neat... what does it look like? :D Do you still need icons for it? Does the implementation use icons? :) -C On Mon, 2016-03-07 at 18:12 +0100, Eduard Braun wrote: > Am 07.03.2016 um 17:53 schrieb Martin Owens: > > > > If anyone wants to have a crack at it, these ones are based on the > > strait line and the order of the items is the order they paint. So > > it > > should signify the effect pretty clearly. > Actually I'd keep a constant order (and also size and position) of > all > items and just change the layering... > > The idea to use item order to visualize paint order is nice, but > it's > too hard to figure out what stroke and fill are when items are > moving > around (especially given the small size), so the intended effect is > not > achieved and it actually gets harder to figure out the paint order. > > Regards, > Eduard > > ------------------------------------------------------------------- > ----------- > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://makebettercode.com/inteldaal-eval > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel@lists.sourceforge.net <mailto:Inkscape-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/inkscape-devel ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net <mailto:Inkscape-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Actually, there's a less cluttered way I just thought of...
How about putting a "Fill on top" and "Fill on bottom" icon pair in the "Fill" tab... And put a "Stroke on top" "Markers on top" icon pair in the Stroke tab?
That covers the four most likely states, leaving out the odd ones where you have the fill sammiched inbetween the marker and the line stroke (which makes the line look off center, and would almost certainly be an error). Moreover, from a UI perspective it keeps "fill ordering" in the fill tab and markers and lines in the stroke tab, with all the other stroke and marker properties.
-C
On Mon, Mar 7, 2016 at 7:42 PM, C R <cajhne@...400...> wrote:
Here's my stab at a complete set of icons, the style consistent with the ones above (maybe something other than red for a fill though).
http://www.opendesignstudio.org/inkscape/paint_order_feature_icons.png
I think it helps to have "markers" that remind the user what "markers" are, which is why I included two. Visually, this is a bit easier to sort through than just the edge of the line and a single marker, I think.
Thoughts? -C
On Mon, Mar 7, 2016 at 6:55 PM, C R <cajhne@...400...> wrote:
JFYI, I've almost finished implementing a GUI for paint-order.
Tav
Neat... what does it look like? :D Do you still need icons for it? Does the implementation use icons? :)
-C
On Mon, 2016-03-07 at 18:12 +0100, Eduard Braun wrote:
Am 07.03.2016 um 17:53 schrieb Martin Owens:
If anyone wants to have a crack at it, these ones are based on the strait line and the order of the items is the order they paint. So it should signify the effect pretty clearly.
Actually I'd keep a constant order (and also size and position) of all items and just change the layering...
The idea to use item order to visualize paint order is nice, but it's too hard to figure out what stroke and fill are when items are moving around (especially given the small size), so the intended effect is not achieved and it actually gets harder to figure out the paint order.
Regards, Eduard
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I find these to be much more easily understandable, thank you, CR! Having them go around a corner helps.
Thanks Maren. I'm glad you like them!
But maybe both markers should be identical as they would be in reality? Arrows are easier to understand as being a symbol for a 'marker' than the dots, at least for me. If the markers could be made bigger (not by much), it could be easier to spot the difference between some of the icons.
In reality, you can choose start and end markers to be different. :) This is why I chose the arrow and circle ends, as I use these two all the time in product design documents. I scaled the markers down a little because they were starting to look a bit cluttered, and it was hard to see enough of the line to show the shape well. It's a very small space, but if you want to improve upon it, feel free. :)
Download the source file here and have a play if you like:
http://www.opendesignstudio.org/inkscape/paint_order_feature.svg
-C
Maren
Am 07.03.2016 um 20:42 schrieb C R:
Here's my stab at a complete set of icons, the style consistent with the ones above (maybe something other than red for a fill though).
http://www.opendesignstudio.org/inkscape/paint_order_feature_icons.png
I think it helps to have "markers" that remind the user what "markers" are, which is why I included two. Visually, this is a bit easier to sort through than just the edge of the line and a single marker, I think.
Thoughts? -C
On Mon, Mar 7, 2016 at 6:55 PM, C R <cajhne@...400... mailto:cajhne@...400...> wrote:
JFYI, I've almost finished implementing a GUI for paint-order. Tav Neat... what does it look like? :D Do you still need icons for it? Does the implementation use icons? :) -C On Mon, 2016-03-07 at 18:12 +0100, Eduard Braun wrote: > Am 07.03.2016 um 17:53 schrieb Martin Owens: > > > > If anyone wants to have a crack at it, these ones are based on the > > strait line and the order of the items is the order they paint. So > > it > > should signify the effect pretty clearly. > Actually I'd keep a constant order (and also size andposition) of
> all > items and just change the layering... > > The idea to use item order to visualize paint order is nice,but
> it's > too hard to figure out what stroke and fill are when items are > moving > around (especially given the small size), so the intended effect is > not > achieved and it actually gets harder to figure out the paint order. > > Regards, > Eduard > >
> ----------- > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://makebettercode.com/inteldaal-eval > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel@lists.sourceforge.net <mailto:Inkscape-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net <mailto:Inkscape-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, Mar 7, 2016 at 11:59 AM, C R <cajhne@...400...> wrote:
Actually, there's a less cluttered way I just thought of...
How about putting a "Fill on top" and "Fill on bottom" icon pair in the "Fill" tab... And put a "Stroke on top" "Markers on top" icon pair in the Stroke tab?
I don't think splitting them up is a good idea. It would make things less obvious imho as you can have options that are not currently visible be toggled off. So, it could be you're on the Fill tab, set something there, switch to the Stroke tab, set something there, toggle back to the Fill tab and the user would be more likely to think "Hey, I set that option before, what happened?"
Cheers, Josh
Some user feedback;
Why does every icon need to be shown?
It takes quite some screen estate.
It could be a drop down instead as exactly one of the orders is active at a time.
Also the icons relate to both fill and stroke not only stroke. Why are they on stroke style tab and not close to opacity/blur which relate to both fill and stroke? On 7 Mar 2016 21:08, "C R" <cajhne@...400...> wrote:
I find these to be much more easily understandable, thank you, CR!
Having them go around a corner helps.
Thanks Maren. I'm glad you like them!
But maybe both markers should be identical as they would be in reality? Arrows are easier to understand as being a symbol for a 'marker' than the dots, at least for me. If the markers could be made bigger (not by much), it could be easier to spot the difference between some of the icons.
In reality, you can choose start and end markers to be different. :) This is why I chose the arrow and circle ends, as I use these two all the time in product design documents. I scaled the markers down a little because they were starting to look a bit cluttered, and it was hard to see enough of the line to show the shape well. It's a very small space, but if you want to improve upon it, feel free. :)
Download the source file here and have a play if you like:
http://www.opendesignstudio.org/inkscape/paint_order_feature.svg
-C
Maren
Am 07.03.2016 um 20:42 schrieb C R:
Here's my stab at a complete set of icons, the style consistent with the ones above (maybe something other than red for a fill though).
http://www.opendesignstudio.org/inkscape/paint_order_feature_icons.png
I think it helps to have "markers" that remind the user what "markers" are, which is why I included two. Visually, this is a bit easier to sort through than just the edge of the line and a single marker, I think.
Thoughts? -C
On Mon, Mar 7, 2016 at 6:55 PM, C R <cajhne@...400... mailto:cajhne@...400...> wrote:
JFYI, I've almost finished implementing a GUI for paint-order. Tav Neat... what does it look like? :D Do you still need icons for it? Does the implementation use icons?:)
-C On Mon, 2016-03-07 at 18:12 +0100, Eduard Braun wrote: > Am 07.03.2016 um 17:53 schrieb Martin Owens: > > > > If anyone wants to have a crack at it, these ones are based on the > > strait line and the order of the items is the order they paint. So > > it > > should signify the effect pretty clearly. > Actually I'd keep a constant order (and also size andposition) of
> all > items and just change the layering... > > The idea to use item order to visualize paint order is nice,but
> it's > too hard to figure out what stroke and fill are when items are > moving > around (especially given the small size), so the intended effect is > not > achieved and it actually gets harder to figure out the paint order. > > Regards, > Eduard > >
> ----------- > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://makebettercode.com/inteldaal-eval > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel@lists.sourceforge.net <mailto:Inkscape-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net <mailto:Inkscape-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I don't think splitting them up is a good idea. It would make things less obvious imho as you can have options that are not currently visible be toggled off. So, it could be you're on the Fill tab, set something there, switch to the Stroke tab, set something there, toggle back to the Fill tab and the user would be more likely to think "Hey, I set that option before, what happened?"
If there were three toggles, yes, but since there are only two in each tab, this would not happen. The fill toggle would make the fill either always on top or always on the bottom. Nothing you do to the stroke/markers tab toggle would change that, and vice-versa.
-C
On Mon, Mar 7, 2016 at 12:12 PM, C R <cajhne@...400...> wrote:
I don't think splitting them up is a good idea. It would make things less
obvious imho as you can have options that are not currently visible be toggled off. So, it could be you're on the Fill tab, set something there, switch to the Stroke tab, set something there, toggle back to the Fill tab and the user would be more likely to think "Hey, I set that option before, what happened?"
If there were three toggles, yes, but since there are only two in each tab, this would not happen. The fill toggle would make the fill either always on top or always on the bottom. Nothing you do to the stroke/markers tab toggle would change that, and vice-versa.
Okay, I hear you. I'm just still not sure it would visually make sense. With all of the options grouped like they were in your example, you can discern what is going on there. It still seems like it would be less obvious to a user with the current icons proposed if they were split up. Am I missing something that makes it more obvious? Maybe my confusion is a bad sign. :P
Cheers, Josh
Why does every icon need to be shown?
I personally think only four should be shown. The two where the fill is between the line and the markers is always going to look wrong. :) The point of showing icons is to show the user at a glance what the result will be. If we have a dropdown that says:
It could be a drop down instead as exactly one of the orders is active at a
time.
Sure, but then so could the others values in this dialogue. Also, dragging down 6 vertically stacked icons may be less of a nice thing than two stacked layers of three. The other options vanish once you select something, and if you selected the wrong thing, you have to click again before you can see the other options once more.
Also the icons relate to both fill and stroke not only stroke. Why are they on stroke style tab and not close to opacity/blur which relate to both fill and stroke?
Because it can be seen as stroke property, and if, like me, your whole goal is to get the stroke to go behind the fill in text, then the stroke tab is a natural place to look for it. I'd rather not have the option hanging out all the time with the blur and opacity sliders. If it's tabbed, at least it isn't around using up screen realestate when you aren't concerned with it.
My 2p. -C
On 7 Mar 2016 21:08, "C R" <cajhne@...400...> wrote:
I find these to be much more easily understandable, thank you, CR!
Having them go around a corner helps.
Thanks Maren. I'm glad you like them!
But maybe both markers should be identical as they would be in reality? Arrows are easier to understand as being a symbol for a 'marker' than the dots, at least for me. If the markers could be made bigger (not by much), it could be easier to spot the difference between some of the icons.
In reality, you can choose start and end markers to be different. :) This is why I chose the arrow and circle ends, as I use these two all the time in product design documents. I scaled the markers down a little because they were starting to look a bit cluttered, and it was hard to see enough of the line to show the shape well. It's a very small space, but if you want to improve upon it, feel free. :)
Download the source file here and have a play if you like:
http://www.opendesignstudio.org/inkscape/paint_order_feature.svg
-C
Maren
Am 07.03.2016 um 20:42 schrieb C R:
Here's my stab at a complete set of icons, the style consistent with
the
ones above (maybe something other than red for a fill though).
http://www.opendesignstudio.org/inkscape/paint_order_feature_icons.png
I think it helps to have "markers" that remind the user what "markers" are, which is why I included two. Visually, this is a bit easier to sort through than just the edge of
the
line and a single marker, I think.
Thoughts? -C
On Mon, Mar 7, 2016 at 6:55 PM, C R <cajhne@...400... mailto:cajhne@...400...> wrote:
JFYI, I've almost finished implementing a GUI for paint-order. Tav Neat... what does it look like? :D Do you still need icons for it? Does the implementation use icons?:)
-C On Mon, 2016-03-07 at 18:12 +0100, Eduard Braun wrote: > Am 07.03.2016 um 17:53 schrieb Martin Owens: > > > > If anyone wants to have a crack at it, these ones are based on the > > strait line and the order of the items is the order they paint. So > > it > > should signify the effect pretty clearly. > Actually I'd keep a constant order (and also size andposition) of
> all > items and just change the layering... > > The idea to use item order to visualize paint order is nice,but
> it's > too hard to figure out what stroke and fill are when itemsare
> moving > around (especially given the small size), so the intended effect is > not > achieved and it actually gets harder to figure out the paint order. > > Regards, > Eduard > >
> ----------- > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://makebettercode.com/inteldaal-eval > _______________________________________________ > Inkscape-devel mailing list > Inkscape-devel@lists.sourceforge.net <mailto:Inkscape-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net <mailto:Inkscape-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
If there were three toggles, yes, but since there are only two in each
tab, this would not happen. The fill toggle would make the fill either always on top or always on the bottom. Nothing you do to the stroke/markers tab toggle would change that, and vice-versa.
Okay, I hear you. I'm just still not sure it would visually make sense. With all of the options grouped like they were in your example, you can discern what is going on there. It still seems like it would be less obvious to a user with the current icons proposed if they were split up. Am I missing something that makes it more obvious? Maybe my confusion is a bad sign. :P
I think the problem is that "Paint Order" is the programatic term for doing two different functional things (at least from the user perspective): 1.It's making the makers (which are a property of the line, not the fill) either on top of the line or bellow it. 2.It's making the fill either on top of the line/marker or below it.
It's also doing a third thing, which I'd bet no one will ever want to do, and that's putting the fill between the marker and the line... not only is this confusing, it's *ugly as hell*. :) You remember when they got rid of the "blink" property in HTML? Yea, that kind of ugly. :)
So what would really make sense is to control the top or bottom positioning of the fill in the fill dialogue, and the relation of the markers to the line in the line dialogue.
Consider this: I'm drawing map with lines and I'm using markers as station endpoints. I've decided I want my markers under the line, so people can see the line continue through the marker unbroken.
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. I have to worry about where the fill is going to land too, and if I don't have a fill yet, I may be revisiting this 6 icon cluster again shortly.
Case 2: I choose one of the two options in stroke, one that clearly shows the stroke on top of the marker. Done.
Now that I've done that, I decide I'm going to use a fill on that markered line, which is something that usually happens accidentally. But for whatever reason I want it. The only thing I have to decide is if the fill is going on the top or the bottom, so...
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. But now I have to worry about messing up the order of my markers too! Trying to do too many things all at once. :)
Case 2: I choose one of the two options in stroke, one that clearly shows the fill on top of the marker. Done.
I vote Case 2. Two options bite it for now, but they aren't even good options. :)
-C
Am Montag, 7. März 2016, 20:44:53 schrieb C R:
[...]
I think the problem is that "Paint Order" is the programatic term for doing two different functional things (at least from the user perspective): 1.It's making the makers (which are a property of the line, not the fill) either on top of the line or bellow it. 2.It's making the fill either on top of the line/marker or below it.
It's also doing a third thing, which I'd bet no one will ever want to do, and that's putting the fill between the marker and the line... not only is this confusing, it's *ugly as hell*. :) You remember when they got rid of the "blink" property in HTML? Yea, that kind of ugly. :)
As I already said earlier, it doesn't matter if it's ugly or not. If Inkscape chooses to show the paint order from the document via a button state it has to deal with all possible settings. Otherwise the consequences will be much worse: Multiple document settings that are shown the same in the GUI. And no way for the user to discern them.
Tobias
[...]
Am 07.03.2016 um 19:04 schrieb Tavmjong Bah:
JFYI, I've almost finished implementing a GUI for paint-order.
Tav
Just tested revision 14693 - Great work Tav! Also the icons turned out very nice - they're clear and good to distinguish while being very similar to the rest of the UI.
Only nitpicking: One might think about recoloring the markers to make them stand out more against the stroke.
Regards, Eduard
Well, Tav settled it with a commit. :)
Cheers, Josh
On Mon, Mar 7, 2016 at 12:44 PM, C R <cajhne@...400...> wrote:
If there were three toggles, yes, but since there are only two in each
tab, this would not happen. The fill toggle would make the fill either always on top or always on the bottom. Nothing you do to the stroke/markers tab toggle would change that, and vice-versa.
Okay, I hear you. I'm just still not sure it would visually make sense. With all of the options grouped like they were in your example, you can discern what is going on there. It still seems like it would be less obvious to a user with the current icons proposed if they were split up. Am I missing something that makes it more obvious? Maybe my confusion is a bad sign. :P
I think the problem is that "Paint Order" is the programatic term for doing two different functional things (at least from the user perspective): 1.It's making the makers (which are a property of the line, not the fill) either on top of the line or bellow it. 2.It's making the fill either on top of the line/marker or below it.
It's also doing a third thing, which I'd bet no one will ever want to do, and that's putting the fill between the marker and the line... not only is this confusing, it's *ugly as hell*. :) You remember when they got rid of the "blink" property in HTML? Yea, that kind of ugly. :)
So what would really make sense is to control the top or bottom positioning of the fill in the fill dialogue, and the relation of the markers to the line in the line dialogue.
Consider this: I'm drawing map with lines and I'm using markers as station endpoints. I've decided I want my markers under the line, so people can see the line continue through the marker unbroken.
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. I have to worry about where the fill is going to land too, and if I don't have a fill yet, I may be revisiting this 6 icon cluster again shortly.
Case 2: I choose one of the two options in stroke, one that clearly shows the stroke on top of the marker. Done.
Now that I've done that, I decide I'm going to use a fill on that markered line, which is something that usually happens accidentally. But for whatever reason I want it. The only thing I have to decide is if the fill is going on the top or the bottom, so...
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. But now I have to worry about messing up the order of my markers too! Trying to do too many things all at once. :)
Case 2: I choose one of the two options in stroke, one that clearly shows the fill on top of the marker. Done.
I vote Case 2. Two options bite it for now, but they aren't even good options. :)
-C
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Neat... what does it look like? :D
-C
On Mon, Mar 7, 2016 at 10:00 PM, Josh Andler <scislac@...400...> wrote:
Well, Tav settled it with a commit. :)
Cheers, Josh
On Mon, Mar 7, 2016 at 12:44 PM, C R <cajhne@...400...> wrote:
If there were three toggles, yes, but since there are only two in each
tab, this would not happen. The fill toggle would make the fill either always on top or always on the bottom. Nothing you do to the stroke/markers tab toggle would change that, and vice-versa.
Okay, I hear you. I'm just still not sure it would visually make sense. With all of the options grouped like they were in your example, you can discern what is going on there. It still seems like it would be less obvious to a user with the current icons proposed if they were split up. Am I missing something that makes it more obvious? Maybe my confusion is a bad sign. :P
I think the problem is that "Paint Order" is the programatic term for doing two different functional things (at least from the user perspective): 1.It's making the makers (which are a property of the line, not the fill) either on top of the line or bellow it. 2.It's making the fill either on top of the line/marker or below it.
It's also doing a third thing, which I'd bet no one will ever want to do, and that's putting the fill between the marker and the line... not only is this confusing, it's *ugly as hell*. :) You remember when they got rid of the "blink" property in HTML? Yea, that kind of ugly. :)
So what would really make sense is to control the top or bottom positioning of the fill in the fill dialogue, and the relation of the markers to the line in the line dialogue.
Consider this: I'm drawing map with lines and I'm using markers as station endpoints. I've decided I want my markers under the line, so people can see the line continue through the marker unbroken.
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. I have to worry about where the fill is going to land too, and if I don't have a fill yet, I may be revisiting this 6 icon cluster again shortly.
Case 2: I choose one of the two options in stroke, one that clearly shows the stroke on top of the marker. Done.
Now that I've done that, I decide I'm going to use a fill on that markered line, which is something that usually happens accidentally. But for whatever reason I want it. The only thing I have to decide is if the fill is going on the top or the bottom, so...
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. But now I have to worry about messing up the order of my markers too! Trying to do too many things all at once. :)
Case 2: I choose one of the two options in stroke, one that clearly shows the fill on top of the marker. Done.
I vote Case 2. Two options bite it for now, but they aren't even good options. :)
-C
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I was hovering over the bottom left one to show what the tooltips are like. http://imgur.com/assneFS
On Mon, Mar 7, 2016 at 2:09 PM, C R <cajhne@...400...> wrote:
Neat... what does it look like? :D
-C
On Mon, Mar 7, 2016 at 10:00 PM, Josh Andler <scislac@...400...> wrote:
Well, Tav settled it with a commit. :)
Cheers, Josh
On Mon, Mar 7, 2016 at 12:44 PM, C R <cajhne@...400...> wrote:
If there were three toggles, yes, but since there are only two in
each tab, this would not happen. The fill toggle would make the fill either always on top or always on the bottom. Nothing you do to the stroke/markers tab toggle would change that, and vice-versa.
Okay, I hear you. I'm just still not sure it would visually make sense. With all of the options grouped like they were in your example, you can discern what is going on there. It still seems like it would be less obvious to a user with the current icons proposed if they were split up. Am I missing something that makes it more obvious? Maybe my confusion is a bad sign. :P
I think the problem is that "Paint Order" is the programatic term for doing two different functional things (at least from the user perspective): 1.It's making the makers (which are a property of the line, not the fill) either on top of the line or bellow it. 2.It's making the fill either on top of the line/marker or below it.
It's also doing a third thing, which I'd bet no one will ever want to do, and that's putting the fill between the marker and the line... not only is this confusing, it's *ugly as hell*. :) You remember when they got rid of the "blink" property in HTML? Yea, that kind of ugly. :)
So what would really make sense is to control the top or bottom positioning of the fill in the fill dialogue, and the relation of the markers to the line in the line dialogue.
Consider this: I'm drawing map with lines and I'm using markers as station endpoints. I've decided I want my markers under the line, so people can see the line continue through the marker unbroken.
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. I have to worry about where the fill is going to land too, and if I don't have a fill yet, I may be revisiting this 6 icon cluster again shortly.
Case 2: I choose one of the two options in stroke, one that clearly shows the stroke on top of the marker. Done.
Now that I've done that, I decide I'm going to use a fill on that markered line, which is something that usually happens accidentally. But for whatever reason I want it. The only thing I have to decide is if the fill is going on the top or the bottom, so...
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. But now I have to worry about messing up the order of my markers too! Trying to do too many things all at once. :)
Case 2: I choose one of the two options in stroke, one that clearly shows the fill on top of the marker. Done.
I vote Case 2. Two options bite it for now, but they aren't even good options. :)
-C
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Excellent work Tav,
I've pushed r14694 which contains my suggested design for having the buttons together and the miter limit inline. Give it a try and see if it's something everyone could get used to.
Martin,
On Mon, 2016-03-07 at 22:47 +0100, Eduard Braun wrote:
Am 07.03.2016 um 19:04 schrieb Tavmjong Bah:
JFYI, I've almost finished implementing a GUI for paint-order.
Tav
Just tested revision 14693 - Great work Tav! Also the icons turned out very nice - they're clear and good to distinguish while being very similar to the rest of the UI.
Only nitpicking: One might think about recoloring the markers to make them stand out more against the stroke.
Regards, Eduard
Works for me. :) Thanks Tav! (And thanks Josh for showing it off) :)
-C On 7 Mar 2016 10:21 pm, "Josh Andler" <scislac@...400...> wrote:
I was hovering over the bottom left one to show what the tooltips are like. http://imgur.com/assneFS
On Mon, Mar 7, 2016 at 2:09 PM, C R <cajhne@...400...> wrote:
Neat... what does it look like? :D
-C
On Mon, Mar 7, 2016 at 10:00 PM, Josh Andler <scislac@...400...> wrote:
Well, Tav settled it with a commit. :)
Cheers, Josh
On Mon, Mar 7, 2016 at 12:44 PM, C R <cajhne@...400...> wrote:
> If there were three toggles, yes, but since there are only two in each tab, this would not happen. The fill toggle would make the fill either always on top or always on the bottom. Nothing you do to the stroke/markers tab toggle would change that, and vice-versa.
Okay, I hear you. I'm just still not sure it would visually make sense. With all of the options grouped like they were in your example, you can discern what is going on there. It still seems like it would be less obvious to a user with the current icons proposed if they were split up. Am I missing something that makes it more obvious? Maybe my confusion is a bad sign. :P
I think the problem is that "Paint Order" is the programatic term for doing two different functional things (at least from the user perspective): 1.It's making the makers (which are a property of the line, not the fill) either on top of the line or bellow it. 2.It's making the fill either on top of the line/marker or below it.
It's also doing a third thing, which I'd bet no one will ever want to do, and that's putting the fill between the marker and the line... not only is this confusing, it's *ugly as hell*. :) You remember when they got rid of the "blink" property in HTML? Yea, that kind of ugly. :)
So what would really make sense is to control the top or bottom positioning of the fill in the fill dialogue, and the relation of the markers to the line in the line dialogue.
Consider this: I'm drawing map with lines and I'm using markers as station endpoints. I've decided I want my markers under the line, so people can see the line continue through the marker unbroken.
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. I have to worry about where the fill is going to land too, and if I don't have a fill yet, I may be revisiting this 6 icon cluster again shortly.
Case 2: I choose one of the two options in stroke, one that clearly shows the stroke on top of the marker. Done.
Now that I've done that, I decide I'm going to use a fill on that markered line, which is something that usually happens accidentally. But for whatever reason I want it. The only thing I have to decide is if the fill is going on the top or the bottom, so...
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. But now I have to worry about messing up the order of my markers too! Trying to do too many things all at once. :)
Case 2: I choose one of the two options in stroke, one that clearly shows the fill on top of the marker. Done.
I vote Case 2. Two options bite it for now, but they aren't even good options. :)
-C
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I think what C R says makes a lot of sense from an artistic point of view: the most important use-case is clearly the one where you choose to put "fill" on top of "stroke", a reverse of the current order (stroke on top of fill).
Then these arcane end-markers (which I seem to never use for quality work, just for quick infogfx/mockups, they're so obnoxious to work with) come and make things complicated :)
Having just a toggle for fill/stroke order (defaulting to current order) on the fill tab would be lovely. Then the Marker/stroke toggle could be on the stroke tab. I'd actually prefer if the "advanced/crazy" order of marker-fill-stroke and stroke-fill-marker would be a case of "edit the xml" or as a not-in-the-way button/widget on the stroke tab.
This results in: - For 99% of time, I just use the fill/stroke order toggle on the Fill tab. - For 1%, I use the more hidden away stroke/marker ordering "thing" on the Stroke tab.
Mvh
/Olof ----------------- 3-5-åriga småttingar i närheten? Lek & lär siffror och bokstäver via mobilen m.h.a. Alfamem till Android. https://play.google.com/store/search?q=alfamem
On 7 March 2016 at 21:44, C R <cajhne@...400...> wrote:
If there were three toggles, yes, but since there are only two in each
tab, this would not happen. The fill toggle would make the fill either always on top or always on the bottom. Nothing you do to the stroke/markers tab toggle would change that, and vice-versa.
Okay, I hear you. I'm just still not sure it would visually make sense. With all of the options grouped like they were in your example, you can discern what is going on there. It still seems like it would be less obvious to a user with the current icons proposed if they were split up. Am I missing something that makes it more obvious? Maybe my confusion is a bad sign. :P
I think the problem is that "Paint Order" is the programatic term for doing two different functional things (at least from the user perspective): 1.It's making the makers (which are a property of the line, not the fill) either on top of the line or bellow it. 2.It's making the fill either on top of the line/marker or below it.
It's also doing a third thing, which I'd bet no one will ever want to do, and that's putting the fill between the marker and the line... not only is this confusing, it's *ugly as hell*. :) You remember when they got rid of the "blink" property in HTML? Yea, that kind of ugly. :)
So what would really make sense is to control the top or bottom positioning of the fill in the fill dialogue, and the relation of the markers to the line in the line dialogue.
Consider this: I'm drawing map with lines and I'm using markers as station endpoints. I've decided I want my markers under the line, so people can see the line continue through the marker unbroken.
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. I have to worry about where the fill is going to land too, and if I don't have a fill yet, I may be revisiting this 6 icon cluster again shortly.
Case 2: I choose one of the two options in stroke, one that clearly shows the stroke on top of the marker. Done.
Now that I've done that, I decide I'm going to use a fill on that markered line, which is something that usually happens accidentally. But for whatever reason I want it. The only thing I have to decide is if the fill is going on the top or the bottom, so...
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. But now I have to worry about messing up the order of my markers too! Trying to do too many things all at once. :)
Case 2: I choose one of the two options in stroke, one that clearly shows the fill on top of the marker. Done.
I vote Case 2. Two options bite it for now, but they aren't even good options. :)
-C
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Regardless of the pros/cons of the implementation, I'd like to say the work Tav and everyone else did to make this happen so quickly is amazing. I've been wanting this feature for ages, and it's just so cool to see it made possible overnight. :D Thankyouthankyouthankyou!
There's something to be said for trying it out this way for now.
Maybe giving better stacking access to the parts will make people more interested in producing custom markers (in all variations).
I'm going to use it extensively as-is, and take notes about the experience.
It's also going in the video, btw, so folks at LGM will be able to see it, and get their own ideas about how to play with it.
So excited!
-C
On Tue, Mar 8, 2016 at 8:06 AM, Olof Bjarnason <olof.bjarnason@...400...> wrote:
I think what C R says makes a lot of sense from an artistic point of view: the most important use-case is clearly the one where you choose to put "fill" on top of "stroke", a reverse of the current order (stroke on top of fill).
Then these arcane end-markers (which I seem to never use for quality work, just for quick infogfx/mockups, they're so obnoxious to work with) come and make things complicated :)
Having just a toggle for fill/stroke order (defaulting to current order) on the fill tab would be lovely. Then the Marker/stroke toggle could be on the stroke tab. I'd actually prefer if the "advanced/crazy" order of marker-fill-stroke and stroke-fill-marker would be a case of "edit the xml" or as a not-in-the-way button/widget on the stroke tab.
This results in:
- For 99% of time, I just use the fill/stroke order toggle on the Fill tab.
- For 1%, I use the more hidden away stroke/marker ordering "thing" on the
Stroke tab.
Mvh
/Olof
3-5-åriga småttingar i närheten? Lek & lär siffror och bokstäver via mobilen m.h.a. Alfamem till Android. https://play.google.com/store/search?q=alfamem
On 7 March 2016 at 21:44, C R <cajhne@...400...> wrote:
If there were three toggles, yes, but since there are only two in each
tab, this would not happen. The fill toggle would make the fill either always on top or always on the bottom. Nothing you do to the stroke/markers tab toggle would change that, and vice-versa.
Okay, I hear you. I'm just still not sure it would visually make sense. With all of the options grouped like they were in your example, you can discern what is going on there. It still seems like it would be less obvious to a user with the current icons proposed if they were split up. Am I missing something that makes it more obvious? Maybe my confusion is a bad sign. :P
I think the problem is that "Paint Order" is the programatic term for doing two different functional things (at least from the user perspective): 1.It's making the makers (which are a property of the line, not the fill) either on top of the line or bellow it. 2.It's making the fill either on top of the line/marker or below it.
It's also doing a third thing, which I'd bet no one will ever want to do, and that's putting the fill between the marker and the line... not only is this confusing, it's *ugly as hell*. :) You remember when they got rid of the "blink" property in HTML? Yea, that kind of ugly. :)
So what would really make sense is to control the top or bottom positioning of the fill in the fill dialogue, and the relation of the markers to the line in the line dialogue.
Consider this: I'm drawing map with lines and I'm using markers as station endpoints. I've decided I want my markers under the line, so people can see the line continue through the marker unbroken.
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. I have to worry about where the fill is going to land too, and if I don't have a fill yet, I may be revisiting this 6 icon cluster again shortly.
Case 2: I choose one of the two options in stroke, one that clearly shows the stroke on top of the marker. Done.
Now that I've done that, I decide I'm going to use a fill on that markered line, which is something that usually happens accidentally. But for whatever reason I want it. The only thing I have to decide is if the fill is going on the top or the bottom, so...
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. But now I have to worry about messing up the order of my markers too! Trying to do too many things all at once. :)
Case 2: I choose one of the two options in stroke, one that clearly shows the fill on top of the marker. Done.
I vote Case 2. Two options bite it for now, but they aren't even good options. :)
-C
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 8 March 2016 at 09:33, C R <cajhne@...400...> wrote:
Regardless of the pros/cons of the implementation, I'd like to say the work Tav and everyone else did to make this happen so quickly is amazing. I've been wanting this feature for ages, and it's just so cool to see it made possible overnight. :D Thankyouthankyouthankyou!
There's something to be said for trying it out this way for now.
Maybe giving better stacking access to the parts will make people more interested in producing custom markers (in all variations).
Sorry for going Off-topic, but I think this topic is interesting (might deserve it's own thread)....
If the markers got some 'love' from the community, they might eventually turn into something useful! So that's a good point imho.
I noticed just now that in 0.91 you can 'explode' paths with end markers into filled paths, so that you can manipulate the marker structures simpler, something I remember from the pre 0.48 days was not-so-simple (or do I remember wrong?)
Only thing left then, to make markers usable, would be to enable scaling them / setting their size just like stroke width.
Is there some limit in the SVG format that requires markers to be fixed size, or is this just 'not yet implemented' in Inkscape?
I'm going to use it extensively as-is, and take notes about the experience.
It's also going in the video, btw, so folks at LGM will be able to see it, and get their own ideas about how to play with it.
So excited!
-C
On Tue, Mar 8, 2016 at 8:06 AM, Olof Bjarnason <olof.bjarnason@...400...> wrote:
I think what C R says makes a lot of sense from an artistic point of view: the most important use-case is clearly the one where you choose to put "fill" on top of "stroke", a reverse of the current order (stroke on top of fill).
Then these arcane end-markers (which I seem to never use for quality work, just for quick infogfx/mockups, they're so obnoxious to work with) come and make things complicated :)
Having just a toggle for fill/stroke order (defaulting to current order) on the fill tab would be lovely. Then the Marker/stroke toggle could be on the stroke tab. I'd actually prefer if the "advanced/crazy" order of marker-fill-stroke and stroke-fill-marker would be a case of "edit the xml" or as a not-in-the-way button/widget on the stroke tab.
This results in:
- For 99% of time, I just use the fill/stroke order toggle on the Fill
tab.
- For 1%, I use the more hidden away stroke/marker ordering "thing" on
the Stroke tab.
Mvh
/Olof
3-5-åriga småttingar i närheten? Lek & lär siffror och bokstäver via mobilen m.h.a. Alfamem till Android. https://play.google.com/store/search?q=alfamem
On 7 March 2016 at 21:44, C R <cajhne@...400...> wrote:
If there were three toggles, yes, but since there are only two in
each tab, this would not happen. The fill toggle would make the fill either always on top or always on the bottom. Nothing you do to the stroke/markers tab toggle would change that, and vice-versa.
Okay, I hear you. I'm just still not sure it would visually make sense. With all of the options grouped like they were in your example, you can discern what is going on there. It still seems like it would be less obvious to a user with the current icons proposed if they were split up. Am I missing something that makes it more obvious? Maybe my confusion is a bad sign. :P
I think the problem is that "Paint Order" is the programatic term for doing two different functional things (at least from the user perspective): 1.It's making the makers (which are a property of the line, not the fill) either on top of the line or bellow it. 2.It's making the fill either on top of the line/marker or below it.
It's also doing a third thing, which I'd bet no one will ever want to do, and that's putting the fill between the marker and the line... not only is this confusing, it's *ugly as hell*. :) You remember when they got rid of the "blink" property in HTML? Yea, that kind of ugly. :)
So what would really make sense is to control the top or bottom positioning of the fill in the fill dialogue, and the relation of the markers to the line in the line dialogue.
Consider this: I'm drawing map with lines and I'm using markers as station endpoints. I've decided I want my markers under the line, so people can see the line continue through the marker unbroken.
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. I have to worry about where the fill is going to land too, and if I don't have a fill yet, I may be revisiting this 6 icon cluster again shortly.
Case 2: I choose one of the two options in stroke, one that clearly shows the stroke on top of the marker. Done.
Now that I've done that, I decide I'm going to use a fill on that markered line, which is something that usually happens accidentally. But for whatever reason I want it. The only thing I have to decide is if the fill is going on the top or the bottom, so...
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. But now I have to worry about messing up the order of my markers too! Trying to do too many things all at once. :)
Case 2: I choose one of the two options in stroke, one that clearly shows the fill on top of the marker. Done.
I vote Case 2. Two options bite it for now, but they aren't even good options. :)
-C
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Well, it's going in the LGM video, so I'll try to come up with a demo that shows how it looks good (maybe with custom markers) :) Then we can toss it around the community and people can go nuts.
-C
On Tue, Mar 8, 2016 at 9:30 AM, Olof Bjarnason <olof.bjarnason@...400...> wrote:
On 8 March 2016 at 09:33, C R <cajhne@...400...> wrote:
Regardless of the pros/cons of the implementation, I'd like to say the work Tav and everyone else did to make this happen so quickly is amazing. I've been wanting this feature for ages, and it's just so cool to see it made possible overnight. :D Thankyouthankyouthankyou!
There's something to be said for trying it out this way for now.
Maybe giving better stacking access to the parts will make people more interested in producing custom markers (in all variations).
Sorry for going Off-topic, but I think this topic is interesting (might deserve it's own thread)....
If the markers got some 'love' from the community, they might eventually turn into something useful! So that's a good point imho.
I noticed just now that in 0.91 you can 'explode' paths with end markers into filled paths, so that you can manipulate the marker structures simpler, something I remember from the pre 0.48 days was not-so-simple (or do I remember wrong?)
Only thing left then, to make markers usable, would be to enable scaling them / setting their size just like stroke width.
Is there some limit in the SVG format that requires markers to be fixed size, or is this just 'not yet implemented' in Inkscape?
I'm going to use it extensively as-is, and take notes about the experience.
It's also going in the video, btw, so folks at LGM will be able to see it, and get their own ideas about how to play with it.
So excited!
-C
On Tue, Mar 8, 2016 at 8:06 AM, Olof Bjarnason <olof.bjarnason@...400...> wrote:
I think what C R says makes a lot of sense from an artistic point of view: the most important use-case is clearly the one where you choose to put "fill" on top of "stroke", a reverse of the current order (stroke on top of fill).
Then these arcane end-markers (which I seem to never use for quality work, just for quick infogfx/mockups, they're so obnoxious to work with) come and make things complicated :)
Having just a toggle for fill/stroke order (defaulting to current order) on the fill tab would be lovely. Then the Marker/stroke toggle could be on the stroke tab. I'd actually prefer if the "advanced/crazy" order of marker-fill-stroke and stroke-fill-marker would be a case of "edit the xml" or as a not-in-the-way button/widget on the stroke tab.
This results in:
- For 99% of time, I just use the fill/stroke order toggle on the Fill
tab.
- For 1%, I use the more hidden away stroke/marker ordering "thing" on
the Stroke tab.
Mvh
/Olof
3-5-åriga småttingar i närheten? Lek & lär siffror och bokstäver via mobilen m.h.a. Alfamem till Android. https://play.google.com/store/search?q=alfamem
On 7 March 2016 at 21:44, C R <cajhne@...400...> wrote:
> If there were three toggles, yes, but since there are only two in each tab, this would not happen. The fill toggle would make the fill either always on top or always on the bottom. Nothing you do to the stroke/markers tab toggle would change that, and vice-versa.
Okay, I hear you. I'm just still not sure it would visually make sense. With all of the options grouped like they were in your example, you can discern what is going on there. It still seems like it would be less obvious to a user with the current icons proposed if they were split up. Am I missing something that makes it more obvious? Maybe my confusion is a bad sign. :P
I think the problem is that "Paint Order" is the programatic term for doing two different functional things (at least from the user perspective): 1.It's making the makers (which are a property of the line, not the fill) either on top of the line or bellow it. 2.It's making the fill either on top of the line/marker or below it.
It's also doing a third thing, which I'd bet no one will ever want to do, and that's putting the fill between the marker and the line... not only is this confusing, it's *ugly as hell*. :) You remember when they got rid of the "blink" property in HTML? Yea, that kind of ugly. :)
So what would really make sense is to control the top or bottom positioning of the fill in the fill dialogue, and the relation of the markers to the line in the line dialogue.
Consider this: I'm drawing map with lines and I'm using markers as station endpoints. I've decided I want my markers under the line, so people can see the line continue through the marker unbroken.
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. I have to worry about where the fill is going to land too, and if I don't have a fill yet, I may be revisiting this 6 icon cluster again shortly.
Case 2: I choose one of the two options in stroke, one that clearly shows the stroke on top of the marker. Done.
Now that I've done that, I decide I'm going to use a fill on that markered line, which is something that usually happens accidentally. But for whatever reason I want it. The only thing I have to decide is if the fill is going on the top or the bottom, so...
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. But now I have to worry about messing up the order of my markers too! Trying to do too many things all at once. :)
Case 2: I choose one of the two options in stroke, one that clearly shows the fill on top of the marker. Done.
I vote Case 2. Two options bite it for now, but they aren't even good options. :)
-C
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, 2016-03-08 at 10:44 +0000, C R wrote:
Well, it's going in the LGM video, so I'll try to come up with a demo that shows how it looks good (maybe with custom markers) :) Then we can toss it around the community and people can go nuts.
Text is probably the most important use of putting the stroke behind fill.
Tav
Looks very clear! Nice work. Looking forward to trying this out...
Mvh
/Olof ----------------- 3-5-åriga småttingar i närheten? Lek & lär siffror och bokstäver via mobilen m.h.a. Alfamem till Android. https://play.google.com/store/search?q=alfamem
On 8 March 2016 at 07:24, C R <cajhne@...400...> wrote:
Works for me. :) Thanks Tav! (And thanks Josh for showing it off) :)
-C On 7 Mar 2016 10:21 pm, "Josh Andler" <scislac@...400...> wrote:
I was hovering over the bottom left one to show what the tooltips are like. http://imgur.com/assneFS
On Mon, Mar 7, 2016 at 2:09 PM, C R <cajhne@...400...> wrote:
Neat... what does it look like? :D
-C
On Mon, Mar 7, 2016 at 10:00 PM, Josh Andler <scislac@...400...> wrote:
Well, Tav settled it with a commit. :)
Cheers, Josh
On Mon, Mar 7, 2016 at 12:44 PM, C R <cajhne@...400...> wrote:
>> If there were three toggles, yes, but since there are only two in > each tab, this would not happen. > The fill toggle would make the fill either always on top or always > on the bottom. > Nothing you do to the stroke/markers tab toggle would change that, > and vice-versa. >
Okay, I hear you. I'm just still not sure it would visually make sense. With all of the options grouped like they were in your example, you can discern what is going on there. It still seems like it would be less obvious to a user with the current icons proposed if they were split up. Am I missing something that makes it more obvious? Maybe my confusion is a bad sign. :P
I think the problem is that "Paint Order" is the programatic term for doing two different functional things (at least from the user perspective): 1.It's making the makers (which are a property of the line, not the fill) either on top of the line or bellow it. 2.It's making the fill either on top of the line/marker or below it.
It's also doing a third thing, which I'd bet no one will ever want to do, and that's putting the fill between the marker and the line... not only is this confusing, it's *ugly as hell*. :) You remember when they got rid of the "blink" property in HTML? Yea, that kind of ugly. :)
So what would really make sense is to control the top or bottom positioning of the fill in the fill dialogue, and the relation of the markers to the line in the line dialogue.
Consider this: I'm drawing map with lines and I'm using markers as station endpoints. I've decided I want my markers under the line, so people can see the line continue through the marker unbroken.
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. I have to worry about where the fill is going to land too, and if I don't have a fill yet, I may be revisiting this 6 icon cluster again shortly.
Case 2: I choose one of the two options in stroke, one that clearly shows the stroke on top of the marker. Done.
Now that I've done that, I decide I'm going to use a fill on that markered line, which is something that usually happens accidentally. But for whatever reason I want it. The only thing I have to decide is if the fill is going on the top or the bottom, so...
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. But now I have to worry about messing up the order of my markers too! Trying to do too many things all at once. :)
Case 2: I choose one of the two options in stroke, one that clearly shows the fill on top of the marker. Done.
I vote Case 2. Two options bite it for now, but they aren't even good options. :)
-C
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Just a note to say I'm really enjoying the Paint Order implementation. It's one of my most-used features these days, and makes my advertising graphics work much easier!
Thanks again, everyone!
-C
On Tue, Mar 8, 2016 at 4:30 PM, Olof Bjarnason <olof.bjarnason@...400...> wrote:
Looks very clear! Nice work. Looking forward to trying this out...
Mvh
/Olof
3-5-åriga småttingar i närheten? Lek & lär siffror och bokstäver via mobilen m.h.a. Alfamem till Android. https://play.google.com/store/search?q=alfamem
On 8 March 2016 at 07:24, C R <cajhne@...400...> wrote:
Works for me. :) Thanks Tav! (And thanks Josh for showing it off) :)
-C On 7 Mar 2016 10:21 pm, "Josh Andler" <scislac@...400...> wrote:
I was hovering over the bottom left one to show what the tooltips are like. http://imgur.com/assneFS
On Mon, Mar 7, 2016 at 2:09 PM, C R <cajhne@...400...> wrote:
Neat... what does it look like? :D
-C
On Mon, Mar 7, 2016 at 10:00 PM, Josh Andler <scislac@...400...> wrote:
Well, Tav settled it with a commit. :)
Cheers, Josh
On Mon, Mar 7, 2016 at 12:44 PM, C R <cajhne@...400...> wrote:
>>> If there were three toggles, yes, but since there are only two in >> each tab, this would not happen. >> The fill toggle would make the fill either always on top or always >> on the bottom. >> Nothing you do to the stroke/markers tab toggle would change that, >> and vice-versa. >> > > Okay, I hear you. I'm just still not sure it would visually make > sense. With all of the options grouped like they were in your example, you > can discern what is going on there. It still seems like it would be less > obvious to a user with the current icons proposed if they were split up. Am > I missing something that makes it more obvious? Maybe my confusion is a bad > sign. :P >
I think the problem is that "Paint Order" is the programatic term for doing two different functional things (at least from the user perspective): 1.It's making the makers (which are a property of the line, not the fill) either on top of the line or bellow it. 2.It's making the fill either on top of the line/marker or below it.
It's also doing a third thing, which I'd bet no one will ever want to do, and that's putting the fill between the marker and the line... not only is this confusing, it's *ugly as hell*. :) You remember when they got rid of the "blink" property in HTML? Yea, that kind of ugly. :)
So what would really make sense is to control the top or bottom positioning of the fill in the fill dialogue, and the relation of the markers to the line in the line dialogue.
Consider this: I'm drawing map with lines and I'm using markers as station endpoints. I've decided I want my markers under the line, so people can see the line continue through the marker unbroken.
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. I have to worry about where the fill is going to land too, and if I don't have a fill yet, I may be revisiting this 6 icon cluster again shortly.
Case 2: I choose one of the two options in stroke, one that clearly shows the stroke on top of the marker. Done.
Now that I've done that, I decide I'm going to use a fill on that markered line, which is something that usually happens accidentally. But for whatever reason I want it. The only thing I have to decide is if the fill is going on the top or the bottom, so...
Case 1: I look through the set of 6 icons, and click what I think is the right one. If it's not lovely, I click again, and again, and again until I find the one I want. But now I have to worry about messing up the order of my markers too! Trying to do too many things all at once. :)
Case 2: I choose one of the two options in stroke, one that clearly shows the fill on top of the marker. Done.
I vote Case 2. Two options bite it for now, but they aren't even good options. :)
-C
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, 2016-04-08 at 09:26 +0100, C R wrote:
Just a note to say I'm really enjoying the Paint Order implementation. It's one of my most-used features these days, and makes my advertising graphics work much easier!
Would you like to make a blog post/new article and we'll post it on the website to highlight development work for the next version?
Martin,
Sure, I can do that at the hackfest if you like. :)
-C
On Fri, Apr 8, 2016 at 10:12 AM, Martin Owens <doctormo@...400...> wrote:
On Fri, 2016-04-08 at 09:26 +0100, C R wrote:
Just a note to say I'm really enjoying the Paint Order implementation. It's one of my most-used features these days, and makes my advertising graphics work much easier!
Would you like to make a blog post/new article and we'll post it on the website to highlight development work for the next version?
Martin,
Very cool and useful indeed ! Is there any chance that in the future the Stroke to Path feature inherits from what is seen on screen too ? ivan
Le Vendredi 8 avril 2016 11h14, Martin Owens <doctormo@...400...> a écrit :
On Fri, 2016-04-08 at 09:26 +0100, C R wrote:
Just a note to say I'm really enjoying the Paint Order implementation. It's one of my most-used features these days, and makes my advertising graphics work much easier!
Would you like to make a blog post/new article and we'll post it on the website to highlight development work for the next version?
Martin,
------------------------------------------------------------------------------ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Ivan here are the bug[1], by a Josh proposal I do a Pach that work with fills markers and strokes and paint order.
Im waiting to know his name for the menu because stroke to path dont full cover its features, anyway maybe is beter retain his name because users know it.
[1]https://bugs.launchpad.net/inkscape/+bug/1556592
Cheers, Jabier.
El vie, 08-04-2016 a las 11:35 +0000, Ivan Louette escribió:
Very cool and useful indeed ! Is there any chance that in the future the Stroke to Path feature inherits from what is seen on screen too ? ivan
Le Vendredi 8 avril 2016 11h14, Martin Owens <doctormo@...400...> a écrit :
On Fri, 2016-04-08 at 09:26 +0100, C R wrote:
Just a note to say I'm really enjoying the Paint Order implementation. It's one of my most-used features these days, and makes my advertising graphics work much easier!
Would you like to make a blog post/new article and we'll post it on the website to highlight development work for the next version?
Martin,
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Excellent ! I am very impatient to see it at work ! ivan
Le Vendredi 8 avril 2016 13h44, Jabier Arraiza <jabier.arraiza@...3120.....> a écrit :
Hi Ivan here are the bug[1], by a Josh proposal I do a Pach that work with fills markers and strokes and paint order.
Im waiting to know his name for the menu because stroke to path dont full cover its features, anyway maybe is beter retain his name because users know it.
[1]https://bugs.launchpad.net/inkscape/+bug/1556592
Cheers, Jabier.
El vie, 08-04-2016 a las 11:35 +0000, Ivan Louette escribió:
Very cool and useful indeed ! Is there any chance that in the future the Stroke to Path feature inherits from what is seen on screen too ? ivan
Le Vendredi 8 avril 2016 11h14, Martin Owens <doctormo@...400...> a écrit :
On Fri, 2016-04-08 at 09:26 +0100, C R wrote:
Just a note to say I'm really enjoying the Paint Order implementation. It's one of my most-used features these days, and makes my advertising graphics work much easier!
Would you like to make a blog post/new article and we'll post it on the website to highlight development work for the next version?
Martin,
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (11)
-
C R -
Eduard Braun -
Ivan Louette -
Jabier Arraiza -
Jabiertxo Arraiza Cenoz -
Josh Andler -
Maren Hachmann -
Martin Owens -
Olof Bjarnason -
Tavmjong Bah -
Tobias Ellinghaus