Inkscape

2010/7/27 Thorsten Wilms <t_w_@...>:
> Hi!
>
> Please have a look at 2 mockups about tightening up the Fill and Stroke
> Panel:
> http://thorwil.wordpress.com/2010/07/27/inkscape-fill-and-stroke-panel/

You essentially want to incorporate the gradient editor into the fill
and stroke dialog. As far as I know, the plan was to remove the
gradient editor entirely, and instead use on-canvas editing, once we
come up with a way of specifying a numeric offset for a gradient stop
on the canvas.

My thought was that right click could bring up a small floating
toolbar with a spinbox and an "apply" button that could be used to set
this. It would disappear when the user presses Enter, when it loses
focus or when the user presses the "apply" button. Tab would move to
the next gradient stop, rather than moving focus to the apply button.
The same principle (toolbar with spinbox appears when right-clicking)
could be used for other control points (nodes, handles, rectangle
corners...) as well.

The vertical combo box in your proposal is not supported by GTK.

Regards, Krzysztof

On 7/28/10, Thorsten Wilms wrote:

> Please have a look at 2 mockups about tightening up the Fill and Stroke
> Panel:
> http://thorwil.wordpress.com/2010/07/27/inkscape-fill-and-stroke-panel/

Hi Thorsten,

It's a nice try, but since on-canvas gradient editor is in place,
there is no turning back, I'm afraid.

But since you redid blur/opacity sliders, why stop at that? There is a
nice custom slider written in C and created especially for darktable,
with Blender's widgets in mind. It doesn't need an extra spinbox
widget, because you can right-click and input precise value right in
the middle of the slider, then press Enter to confirm or Esc to
cancel. It also has modificators to control step of a change -- for
tablet users.

Alexandre Prokoudine
http://libregraphicsworld.org

On Wed, 2010-07-28 at 00:14 +0200, Krzysztof Kosiński wrote:

> > http://thorwil.wordpress.com/2010/07/27/inkscape-fill-and-stroke-panel/

> You essentially want to incorporate the gradient editor into the fill
> and stroke dialog.

That's only the second idea, the post is about
http://thorwil.files.wordpress.com/2010/07/inkscape_fill_and_stroke_layout_hsla.png
as much.

Roughly 328 x 354 instead of 354 x 458 px.


> As far as I know, the plan was to remove the
> gradient editor entirely, and instead use on-canvas editing, once we
> come up with a way of specifying a numeric offset for a gradient stop
> on the canvas.

You also should have obvious ways to add and delete gradient stops.

As long as you have to use the slider/wheel section of the Fill and
Stroke panel to define colors of stops, you have to indicate what that
section refers to (a specific stop of a gradient). Only a small step
left to include a complete gradient stop section.

The gradient editor can shorten mouse travel tremendously, with
stop-selection as close as possible to the color sliders/wheel.


> My thought was that right click could bring up a small floating
> toolbar with a spinbox and an "apply" button that could be used to set
> this. It would disappear when the user presses Enter, when it loses
> focus or when the user presses the "apply" button. Tab would move to
> the next gradient stop, rather than moving focus to the apply button.
> The same principle (toolbar with spinbox appears when right-clicking)
> could be used for other control points (nodes, handles, rectangle
> corners...) as well.

Having to use right-click and dealing with a floating toolbar that would
be bound to sometimes cover what you want to see does not promise
increased comfort.


> The vertical combo box in your proposal is not supported by GTK.

I'm aware of that. I think there could be a better set of widgets
especially for building control panels. Having separate mode selection
and legend feels so redundant ... I guess you could get away with having
just a normal combobox and no labels for the sliders.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

On Wed, 2010-07-28 at 10:50 +0400, Alexandre Prokoudine wrote:

> But since you redid blur/opacity sliders, why stop at that? There is a
> nice custom slider written in C and created especially for darktable,
> with Blender's widgets in mind. It doesn't need an extra spinbox
> widget, because you can right-click and input precise value right in
> the middle of the slider, then press Enter to confirm or Esc to
> cancel. It also has modificators to control step of a change -- for
> tablet users.

Because how to edit numerically should be obvious.

Also, since showing the numbers on the color sliders is not feasible, I
didn't want to have them outside there and inside the slider elsewhere.

BTW, a mockup of such sliders, not caring about any existing theme:
http://thorwil.files.wordpress.com/2010/07/sliders.png
Just lacks +/- buttons.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

Thorsten Wilms wrote:
> Hi!
> 
> Please have a look at 2 mockups about tightening up the Fill and Stroke
> Panel:
> http://thorwil.wordpress.com/2010/07/27/inkscape-fill-and-stroke-panel/

I definitely like some of the things you're showing and would welcome a 
patch to try it out (even if it starts with some of the simpler things, 
like merging the fill rule buttons into one).

2010/7/28 Jasper van de Gronde <th.v.d.gronde@...>:
> I definitely like some of the things you're showing and would welcome a
> patch to try it out (even if it starts with some of the simpler things,
> like merging the fill rule buttons into one).

No, merging the fill rule buttons is a mistake. It makes the interface
more confusing instead of less.

Improving the sliders and making the dialog more compact is a better idea.

2010/7/28 Thorsten Wilms <t_w_@...>:
> You also should have obvious ways to add and delete gradient stops.

1. Select the gradient tool
2. Double click on the line connecting the endpoints of a gradient to add a stop
3. Select the stop and press delete to remove it

At the moment it does not work in the node editor though, which should be fixed.

However, there are more irregularities in the fill and stroke dialog.
For example when I select a gradient stop and drag the blur slider,
the entire object is blurred. When I try to adjust the alpha value of
the color of the stop, some weird thing happens to the opacity slider
instead.

Regards, Krzysztof

On Wed, Jul 28, 2010 at 4:42 AM, Thorsten Wilms <t_w_@...> wrote:
> You also should have obvious ways to add and delete gradient stops.

You have all the same many ways you use for adding/deleting nodes in
Node tool, except for toolbar buttons. Which should be added along
with the distance control, but to the toolbar, not any dialog.

> As long as you have to use the slider/wheel section of the Fill and
> Stroke panel to define colors of stops, you have to indicate what that
> section refers to (a specific stop of a gradient). Only a small step
> left to include a complete gradient stop section.

Gradient stops on canvas are selectable, so you can apply color to any
one or multiple ones easier. No need for a dialog.

> The gradient editor can shorten mouse travel tremendously, with
> stop-selection as close as possible to the color sliders/wheel.

Mouse travel is not everything. If it were so important, we would be
designing the entire SVG in a dialog. There are things where spatial
placement, alignment, overall effect are more importanrt, which is why
we have zoomable and pannable canvas. Gradient stops are exactly this
kind of canvas thing, not dialog thing. Just as no one suggests to
add/edit nodes on a path via a dialog.

-- 
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

On Wed, 2010-07-28 at 17:48 +0200, Krzysztof Kosiński wrote:

> No, merging the fill rule buttons is a mistake. It makes the interface
> more confusing instead of less.

When the 2 fill rule buttons got my attention, I looked at the icons and
had no clue what they would be about. I read both tooltips and only then
could make a guess what it was about in practical terms: to fill or not
fill an area where the path overlaps it selfs.

(This is after years of experience, including using Freehand,
Illustrator, Corel Draw.)

Formulated this way, it's a clear candidate for a single option.
Especially as I bet it's touched seldom, probably never by a number of
users.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

On Wed, 2010-07-28 at 13:27 -0300, bulia byak wrote:

> > As long as you have to use the slider/wheel section of the Fill and
> > Stroke panel to define colors of stops, you have to indicate what that
> > section refers to (a specific stop of a gradient). Only a small step
> > left to include a complete gradient stop section.
> 
> Gradient stops on canvas are selectable, so you can apply color to any
> one or multiple ones easier. No need for a dialog.

And where do I define/edit the colors, if not on the Fill and Stroke
panel? Direct access to the color sliders/wheel is pretty much a must
for the color-decisions and tweaking stages of graphic design.


> > The gradient editor can shorten mouse travel tremendously, with
> > stop-selection as close as possible to the color sliders/wheel.
> 
> Mouse travel is not everything. If it were so important, we would be
> designing the entire SVG in a dialog. There are things where spatial
> placement, alignment, overall effect are more importanrt, which is why
> we have zoomable and pannable canvas. Gradient stops are exactly this
> kind of canvas thing, not dialog thing. Just as no one suggests to
> add/edit nodes on a path via a dialog.

Of course it's not everything, but it is a factor.

Currently I use both selecting stops on the canvas and the stops dialog,
depending on the density/number/spread of the stops.

I'm usually all for doing things right in place, inline, fluid. But you
have to see that on-canvas editing is miss-click prone and can be
laborious.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

2010/7/28 Thorsten Wilms <t_w_@...>:
> And where do I define/edit the colors, if not on the Fill and Stroke
> panel? Direct access to the color sliders/wheel is pretty much a must
> for the color-decisions and tweaking stages of graphic design.

There are other ways.
a) Click on the palette.
b) Paste style.
c) Drag the fill color on the current style widget in the bottom left corner.

The trips to the F&S dialog are a little cumbersome though. For
example I often go there just to adjust the alpha value of a color.
There could be a color wheel with an alpha slider that pops up when
you click on the fill color in the bottom left.

> I'm usually all for doing things right in place, inline, fluid. But you
> have to see that on-canvas editing is miss-click prone and can be
> laborious.

The most important advantage of on-canvas editing is that it gives you
direct visual feedback.

Regards, Krzysztof

On Wed, 2010-07-28 at 18:55 +0200, Thorsten Wilms wrote:
> I'm usually all for doing things right in place, inline, fluid. But you
> have to see that on-canvas editing is miss-click prone and can be
> laborious.

Tab & Shift+Tab could probably augment your on-canvas workflow nicely
when you miss-click.

Cheers,
Josh

On 7/28/10, Krzysztof Kosiński wrote:

> The trips to the F&S dialog are a little cumbersome though. For
> example I often go there just to adjust the alpha value of a color.
> There could be a color wheel with an alpha slider that pops up when
> you click on the fill color in the bottom left.

Yes, the GIMP team is currently experimenting with on-canvas dialogs.
Some of the is available in 2.7.1 (dialogs of color tools in
fullscreen mode, options for Text tool on canvas in any mode). Might
be worth following?

Alexandre Prokoudine
http://libregraphicsworld.org

On Wed, 2010-07-28 at 09:53 +0200, Thorsten Wilms wrote:
> Because how to edit numerically should be obvious.

It should be, but we still can't see, let along edit, the angles or
lengths of path lines and connectors.

It would be great if the same logic was applied equally to calculated
data as it is to direct properties.

Martin,