[Gimp-developer] proposal for usability enhancements for Stroke dialog

[Daniel Falk]

Sven Neumann wrote:
> Hi,
>
> On Sat, 2007-12-08 at 17:51 +0000, William Skaggs wrote:
>
>   
>> 1) The most important is that the dialog should not go away after the Stroke
>> button is pushed.  It often takes several tries to get the settings right, and
>> it is very annoying to have to bring the dialog back each time.  The gain in
>> usability would easily be worth the cost of an extra button-click to close the
>> dialog, in my opinion.
>>     
>
> We don't do this kind of "Apply" thing anywhere in GIMP. I think it
> would be rather inconsistent and confusing if we start to do it for some
> dialogs. Since the dialog already remembers all settings, I don't really
> see what you want to achieve with this change. Perhaps it just needs to
> be made easier to bring up the dialog again?
>   
 From a user perspective, I think the ideal solution would be to treat 
strokes on vectors similar to how Inkscape does it.  For those not 
familiar with Inkscape, it works by attaching line and fill properties 
to the vector, which can be changed at any time.  This is different from 
GIMP, which simply renders a stroke straight into pixels, which is 
somewhat less reversible.  Unlike Inkscape however, GIMP should display 
the stroke and fill in pixels at all times, so the user can preview what 
the rastered result would look like and modify the vector accordingly.

That is basically the reason I'm suggesting that it work this way.  On 
many occasions, people really need to be able to see what a vector will 
look like filled and/or stroked while editing it.  Here's a good 
example: suppose I have a vector with a horizontal or vertical line in 
it.  Normally, you'd want the vector to fall right in the middle of the 
pixel row such that there is no "ghost" line occurring as a result of 
aliasing.  Worst case scenario here is that you've put your vector right 
in between the two pixels and now you have a 2 pixel wide gray stroke 
instead of the 1 pixel black stroke you wanted.

I realize this would be a lot of work to implement, but I'm putting it 
out there as a possible eventual goal and as my answer to the question 
of how to best solve this problem in the long run.

>> 3) The "Dash preset" (or whatever it is called) control is by far the most
>> important in the expander, and should be at the top.  In fact, I think it
>> should be out of the expander, since a user *always* wants to know what type of
>> line will be rendered.
>>     
>
> My guess is that the user almost always wants a line. Using a dash
> pattern is rather uncommon, isn't it? But yes, perhaps moving it to the
> top would help.
>
>   
I agree with Sven that using a dash pattern is uncommon, and do prefer 
that the settings for that be hidden.  Unless the line was changed from 
being solid to dashed before.  Supposing that the dialog remembers the 
last settings, I think I'd like to see that my line is going to be 
dashed and not solid.