Inkscape

Andrew <rugby471@...> writes:

> You can see my findings and my suggestion on the Wiki, but to entice you
> to read it, the mockup is here :)
> 
> http://wiki.inkscape.org/wiki/index.php/Fill_and_Stroke_Dialog_Re-Design
> http://wiki.inkscape.org/wiki/index.php/File:Solution-fillandstrokedialog.png
> 
> Thanks and I would love to hear your comments!
> 

I'm not a developer, just a user (and a UI enthusiast). 
You are correct in that the dialog is too cluttered but you're wrong on some
details. Let;s begin with the fact that fill/stroke is not a window, it's a
dockable inside a window. This means you can drag the gray bar at the top and
move the dockable elsewhere, such as to the main window - or to another window
which aleady has a dockable. At that point the window has two dockables and the
window title changes to "dock #3" or something similar and no longer reflects
the contents of the dockable. So, while ugly, the bar is necessary. If you 
want to solve this issue you'll need to find a different tack. Sadly GTK seems
to not be very flexible so don't expect that to change soon.

Now here's another issue where your design is problematic: You chose to turn
the paint / gradient / pattern selector to a drop-down list, while changing
the color mode tabs to a button row. Now, a button row takes a single click to
change modes, while a drop-down list takes two. So, obviously, we would like
to have the buttons for the more commonly used option, and the drop-down for
the less used command. I don't know about you, but I use these buttons ALL
THE TIME. As for color mode, I rarely change it at all. To me it makes no sense
to give it so much space and skimp on the buttons. It would slow my work
considerably. If anything, move the color mode to a drop down. The buttons
have to stay.

Lastly, a general note: you seem to aim for beginner / casual users.
I believe in the case of Inkscape this is not the right audience. this is 
a vector editor, and most casual users aren't really interested in such an
application. Inkscape is a professional grade program - at least for certain
uses - and your redesing would seriously detract from its usability.

Hey Michael,

> I'm not a developer, just a user (and a UI enthusiast). 
> You are correct in that the dialog is too cluttered but you're wrong on some
> details. Let;s begin with the fact that fill/stroke is not a window, it's a
> dockable inside a window. This means you can drag the gray bar at the top and
> move the dockable elsewhere, such as to the main window - or to another window
> which aleady has a dockable. At that point the window has two dockables and the
> window title changes to "dock #3" or something similar and no longer reflects
> the contents of the dockable. So, while ugly, the bar is necessary. If you 
> want to solve this issue you'll need to find a different tack. Sadly GTK seems
> to not be very flexible so don't expect that to change soon.

Maybe I haven't understood exactly what you have said, but I don't see
the issue. At the moment, because there is a normal GTK Window border,
it appears to me, or a first time user, that this is a normal window,
that the awesome docking functionality that we know exists, does
actually exist. (Plus there is duplication which I mentioned on the wiki
page).

By removing the top border, you remove the preconceived idea that the
user has built up in his/her mind, that all thing with that border are
windows, and such are not dockable. This makes them think again when
they see it, and hopefully through that they will start dragging and
manage to dock it, or use the dock button on the window bar.

I just feel with the GTK Window bar (which can easily be removed), you
remove this chance to learn.

> Now here's another issue where your design is problematic: You chose to turn
> the paint / gradient / pattern selector to a drop-down list, while changing
> the color mode tabs to a button row. Now, a button row takes a single click to
> change modes, while a drop-down list takes two. So, obviously, we would like
> to have the buttons for the more commonly used option, and the drop-down for
> the less used command. I don't know about you, but I use these buttons ALL
> THE TIME. As for color mode, I rarely change it at all. To me it makes no sense
> to give it so much space and skimp on the buttons. It would slow my work
> considerably. If anything, move the color mode to a drop down. The buttons
> have to stay.

This is something I worried about as well. I feel that without the
labels, the icons are not as useful, and it is not that clear that what
they do will affect below. Is using a combobox so hard? In fact it is
still one click, hold down and release on the item you wish to select.

Of course if I receive the same feedback from others, I can always
modify the mockup to have this changed back. I am not saying it is
prefect first time :)

> Lastly, a general note: you seem to aim for beginner / casual users.
> I believe in the case of Inkscape this is not the right audience. this is 
> a vector editor, and most casual users aren't really interested in such an
> application. Inkscape is a professional grade program - at least for certain
> uses - and your redesing would seriously detract from its usability.

I would disagree with this point. Less clutter and better usability
(which I am trying to achieve in this case) benefits all users, whether
they are casual or not; and I feel declaring not to include casual users
in our thinking is a bad move - we were all casual users at one point
were we not?

Thanks for your comments :)

-- 
Andrew

On 08/03/11 08:24, Jasper van de Gronde wrote:

> Are you able to make the changes? If so, please do so (perhaps slightly
> more conservatively, at least at first, to be on the safe side), that
> way we can try it out and see how it works and feels in practice. Don't
> get me wrong, it's good to have some discussion and ask for feedback,
> but often in the end it boils down to nothing happening, and that's a
> shame, especially since I think the general message here is that a lot
> of what you're trying to do would be appreciated. If you're not able to
> make the changes in Inkscape, I would be willing to try, especially if
> you could help me with some of the GTK stuff (you seem to at least know
> a thing or two about that, and despite having coded on Inkscape for
> years it's still mostly a mystery to me).

Sure I think I could make some of them, however my idea was to gage
opinion first, rather than do it and everyone says "Actually we don't
like that..." :)

Maybe I shall wait for a few more opinions and then start to make it
happen (though I might need some pointers as I have never coded in C++  XD )

-- 
Andrew

On 8/3/11 08:34, Andrew wrote:

> On 7/3/11 22:28, Michael Grosberg wrote:
>
>> Now here's another issue where your design is problematic: You chose to turn
>> the paint / gradient / pattern selector to a drop-down list, while changing
>> the color mode tabs to a button row. Now, a button row takes a single click to
>> change modes, while a drop-down list takes two. So, obviously, we would like
>> to have the buttons for the more commonly used option, and the drop-down for
>> the less used command. I don't know about you, but I use these buttons ALL
>> THE TIME. As for color mode, I rarely change it at all. To me it makes no sense
>> to give it so much space and skimp on the buttons. It would slow my work
>> considerably. If anything, move the color mode to a drop down. The buttons
>> have to stay.
> 
> This is something I worried about as well. I feel that without the
> labels, the icons are not as useful, and it is not that clear that what
> they do will affect below. Is using a combobox so hard? In fact it is
> still one click, hold down and release on the item you wish to select.
> 
> Of course if I receive the same feedback from others, I can always
> modify the mockup to have this changed back. I am not saying it is
> prefect first time :)

Both drop-down lists (fill type, fill rule) would slow down my workflow
as well - I prefer to be able to choose with one click between visible
buttons, instead of opening the drop-down to read the each available
option and then choose the right one (or to fiddle with the mouse scroll
wheel each time, and make sure I get the intended option selected).

Like Michael, switching between color modes happens not as frequently as
switching the fill/stroke type, but it's nice to have both settings as
quickly accessible (one click) as currently possible. I mainly
appreciate to be able to quickly toggle between RGB <-> HSL when
exploring different shades of a color.

While the drop-down lists can make a visually "nicer", more compact GUI,
usability IMHO is not improved in all cases.



The nested frames and borders in the 'Fill' and 'Stroke paint' tabs have
been irritating to me, too - depending on the GTK+ theme used. (I have
repeatedly tried to tinker with custom GTK+ theme files to change their
appearance - not with much success yet ;) ). OTOH known focus issues
with docked dialogs [1] affect (and disrupt) the workflow much more than
any visual deficiencies due to nested frames and notebooks, improper
padding, or buttons instead of compact drop-down lists. (Personally I'd
rather see efforts spent on addressing those first and HIG-ify the
dialogs later ;) ).


~suv


[1] focus issues when using docked palettes, e.g.
    <https://bugs.launchpad.net/inkscape/+bug/201203>
    <https://bugs.launchpad.net/inkscape/+bug/505225>

Hi again :)

Okay so after previous feedback, that the comboboxes for the fill type
and fill rule were not optimal (i.e. it is quicker to click a button
than select something from a combobox), I have ammended the mockups,
adding back in the buttons.

I also corrected some padding in places, where I seem to have gone a bit
mad with it :)

Please see the two mockups here
http://wiki.inkscape.org/wiki/index.php/Fill_and_Stroke_Dialog_Re-Design#My_Solution.28s.29

Again I really do welcome feedback, positive or negative :)

-- 
Andrew

On 2011-04-08 12:07, Andrew wrote:
> Hi again :)
>
> Okay so after previous feedback, that the comboboxes for the fill type
> and fill rule were not optimal (i.e. it is quicker to click a button
> than select something from a combobox), I have ammended the mockups,
> adding back in the buttons.
>
> I also corrected some padding in places, where I seem to have gone a bit
> mad with it :)
>
> Please see the two mockups here
> http://wiki.inkscape.org/wiki/index.php/Fill_and_Stroke_Dialog_Re-Design#My_Solution.28s.29
>
> Again I really do welcome feedback, positive or negative :)
Esthetically I prefer the old (non-bevelled) "buttons" for selecting the
fill type and rule (the bevels make it look a bit crowded, as there are
so many options), but other than that I have no complaints and would
absolutely love to see this happen.

On 8/4/11 13:30, Jasper van de Gronde wrote:
> On 2011-04-08 12:07, Andrew wrote:
>
>> Okay so after previous feedback, that the comboboxes for the fill type
>> and fill rule were not optimal (i.e. it is quicker to click a button
>> than select something from a combobox), I have ammended the mockups,
>> adding back in the buttons.
>>
>> I also corrected some padding in places, where I seem to have gone a bit
>> mad with it :)
>>
>> Please see the two mockups here
>> http://wiki.inkscape.org/wiki/index.php/Fill_and_Stroke_Dialog_Re-Design#My_Solution.28s.29
>>
>> Again I really do welcome feedback, positive or negative :)
>
> Esthetically I prefer the old (non-bevelled) "buttons" for selecting the
> fill type and rule (the bevels make it look a bit crowded, as there are
> so many options), but other than that I have no complaints and would
> absolutely love to see this happen.

a) flat buttons
1+ on using flat icons and not 'regular' buttons for the fill/stroke
types (I guess it would not be in accordance to the Gnome HIG? ;) ).
These types of flat buttons are used in other places of the GUI as well,
e.g. in the 'Align & Distribute' dialog.


b) sliders vs spinboxes
I'm not sure about removing the sliders for opacity and blur (the
extension dialogs recently got a new widget to alternatively display
sliders in addition to spinboxes). Many users seem to appreciate sliders
if values don't need to be set to precise values but freely adjusted to
achieve a visually pleasing result (technical vs artistic drawing?).


c) window decoration
Getting rid of the standard GTK Window Bar and replacing it with a
custom one: wouldn't this either have to be done for all dockable
dialogs (once all or most of them have been made dockable, a feature
repeatedly requested by Inkscape users), instead of creating a single
exception how a floating dialog (which is docked with default settings)
looks? Also, does a custom solution work well with different window
managers (and on other platforms, e.g. those which don't use the X11
backend of GTK+)?


d) minimal dialog width
Unrelated (since it was not mentioned in the redesign proposal) question
(but possibly with some relevance when refactoring dialogs?):
What does or should determine the overall minimal (or default) width of
the dialog? At the moment the length of the (translated) strings of the
labels will considerably affect the minimal or default width, e.g.
- the labels of the notebook tabs at the top
  as seen in this screenshot [1] from the inkscape-devel archives [2]
  (has improved since)
- the labels of the various options in the 'Stroke style' tab
  Test yourself with e.g. 'German' as UI language: the labels in
  the 'Stroke style' tab will extend the overall minimal width of
  the dialog unproportionally IMHO.
- names of custom patterns or markers
  seen e.g. with SVG files created by third-party applications [1]
Could this be handled differently in how the dialog is coded, or - with
regard to the translations - is it completely up to the translators?


~suv


[1] <http://dl.dropbox.com/u/1047321/inkscape/fat_ui.png>
[2] <http://article.gmane.org/gmane.comp.graphics.inkscape.devel/30362>
[3]
<https://bugs.launchpad.net/inkscape/+bug/596842/+attachment/1432106/+files/SequenceFlowDefault.svg>

On Fri, Apr 8, 2011 at 2:07 PM, Andrew wrote:

> Please see the two mockups here
> http://wiki.inkscape.org/wiki/index.php/Fill_and_Stroke_Dialog_Re-Design#My_Solution.28s.29

A huge "no" to spinboxes for blur and opacity. They are simply
unusable for tablet users. I was going to bring this up anyway, so
here goes: several applications, one after another, recently switched
to a new type of slider that combines a slider, a label and a spinbox.
Among them are GIMP, darktable and Kdenlive. Here is  a short demo of
the GIMP's one (that triggered others) I did last year:

http://vimeo.com/16616760

In fact I'd love our tools options toolbar to use this kind of widget,
but I can surely see how it could be great for things like opacity in
Fill'n'Stroke dialog as well as well.

Alexandre Prokoudine
http://libregraphicsworld.org

Hi, I like it better than our current dialog, which is visually too crowded.

However, turn the fill type (3) and color model (5) buttons into flat
buttons as other suggested and that would be perfect.

One last detail: in the blur slider you put 'px' as units, but I'm not
quite sure if those units are given in pixels or % of the size of the
blurred object...

Regards.

2011/4/8 Alexandre Prokoudine <alexandre.prokoudine@...>:
> A huge "no" to spinboxes for blur and opacity. They are simply
> unusable for tablet users.

I don't have a tablet, I always use a mouse and don't like spinboxes
either for Opacity and Blur. My aim are artistic drawings, maybe
that's why I prefer them, the visual feedback feels way more natural
using sliders.

On 2011-04-08 15:58, Pajarico wrote:
> Hi, I like it better than our current dialog, which is visually too crowded.
>
> However, turn the fill type (3) and color model (5) buttons into flat
> buttons as other suggested and that would be perfect.
>
> One last detail: in the blur slider you put 'px' as units, but I'm not
> quite sure if those units are given in pixels or % of the size of the
> blurred object...
Good point. % is more appropriate than px (it is relative to the size of
the blurred object). Personally I don't like the current system, as I'm
used to thinking in absolute units, but the idea is that objects blurred
with the same "percentage" of blur more or less look equally blurry. I
think it is currently defined as a percentage of the sum of the width
and height of the bounding box or something like that. If you can think
of a better way to do this you'd make my day :)

Hi,

> Esthetically I prefer the old (non-bevelled) "buttons" for selecting the
> fill type and rule (the bevels make it look a bit crowded, as there are
> so many options), but other than that I have no complaints and would
> absolutely love to see this happen.
>
> a) flat buttons
> 1+ on using flat icons and not 'regular' buttons for the fill/stroke
> types (I guess it would not be in accordance to the Gnome HIG? ;) ).
> These types of flat buttons are used in other places of the GUI as well,
> e.g. in the 'Align & Distribute' dialog.
>
> However, turn the fill type (3) and color model (5) buttons into flat
> buttons as other suggested and that would be perfect.

The trouble is with having the buttons with no 'relief' is that it is
not immediately obvious what they are (i.e. from a first look, how do I
distinguish them from the icons in the bottom left?)

However I totally see your points that having the multiple borders
provides too much visual distraction, in fact I agree with you on some
level :)

Ideally, I would like to have some like in the image
http://bit.ly/gn2q7z , a 'ToggleButtonGroup', alas GTK doesn't have this
widget yet, however that is not to say it would be impossible to create :)

I think for the moment then, I shall remove the relief from the buttons,
as the collective opinion is currently that, however hopefully in the
future this  'ToggleButtonGroup' can become a reality.

> b) sliders vs spinboxes
> I'm not sure about removing the sliders for opacity and blur (the
> extension dialogs recently got a new widget to alternatively display
> sliders in addition to spinboxes). Many users seem to appreciate sliders
> if values don't need to be set to precise values but freely adjusted to
> achieve a visually pleasing result (technical vs artistic drawing?).
>
> A huge "no" to spinboxes for blur and opacity. They are simply
> unusable for tablet users. I was going to bring this up anyway, so
> here goes: several applications, one after another, recently switched
> to a new type of slider that combines a slider, a label and a spinbox.
> Among them are GIMP, darktable and Kdenlive. Here is  a short demo of
> the GIMP's one (that triggered others) I did last year:
> http://vimeo.com/16616760
> In fact I'd love our tools options toolbar to use this kind of widget,
> but I can surely see how it could be great for things like opacity in
> Fill'n'Stroke dialog as well as well.
>
> I don't have a tablet, I always use a mouse and don't like spinboxes
> either for Opacity and Blur. My aim are artistic drawings, maybe
> that's why I prefer them, the visual feedback feels way more natural
> using sliders.

Okay then I guess we prefer sliders :) On the note of that custom widget
GIMP is using, I think that is quite interesting, reminds me (in a good
way) of the volume widget iTunes has on the iPad. Whilst I think the
ideas behind it are great, I don't think it is a polished as it could
be, but definitely something to think about in the future.

> One last detail: in the blur slider you put 'px' as units, but I'm not
> quite sure if those units are given in pixels or % of the size of the
> blurred object...
>
> Good point. % is more appropriate than px (it is relative to the size of
> the blurred object). Personally I don't like the current system, as I'm
> used to thinking in absolute units, but the idea is that objects blurred
> with the same "percentage" of blur more or less look equally blurry. I
> think it is currently defined as a percentage of the sum of the width
> and height of the bounding box or something like that.

I was not entirely sure about this so thanks for bringing it to my
attention. I shall change 'px' to '%'.

> c) window decoration
> Getting rid of the standard GTK Window Bar and replacing it with a
> custom one: wouldn't this either have to be done for all dockable
> dialogs (once all or most of them have been made dockable, a feature
> repeatedly requested by Inkscape users), instead of creating a single
> exception how a floating dialog (which is docked with default settings)
> looks? Also, does a custom solution work well with different window
> managers (and on other platforms, e.g. those which don't use the X11
> backend of GTK+)?

IIRC, all the dialogs are subclassed from a special dialog object that
does all the floating dockable dialog stuff, so changing the code would
mean all the dialog would change.

I think because this is would be a slightly larger task, especially
testing on other platforms, this could wait until later, with just the
improvements to the content of the Fill and Stroke Dialog happening now.

> d) minimal dialog width
> Unrelated (since it was not mentioned in the redesign proposal) question
> (but possibly with some relevance when refactoring dialogs?):
> What does or should determine the overall minimal (or default) width of
> the dialog? At the moment the length of the (translated) strings of the
> labels will considerably affect the minimal or default width, e.g.
> - the labels of the notebook tabs at the top
>   as seen in this screenshot [1] from the inkscape-devel archives [2]
>   (has improved since)
> - the labels of the various options in the 'Stroke style' tab
>   Test yourself with e.g. 'German' as UI language: the labels in
>   the 'Stroke style' tab will extend the overall minimal width of
>   the dialog unproportionally IMHO.
> - names of custom patterns or markers
>   seen e.g. with SVG files created by third-party applications [1]
> Could this be handled differently in how the dialog is coded, or - with
> regard to the translations - is it completely up to the translators?

Since this does not affect me, I am maybe not the best person to ask
about it, however my initial reaction would be to make sure labels are
able to be ellipsized, so that they can be shrunk down, and also check
the translations are optimal in terms of understanding and size (which I
am sure most already are :] )

Thanks for your comments everyone, I shall now create a final draft,
based on the stuff above, and then hopefully I will start work on it
(however exams are coming up so it may be a while, and I am also trying
to get the new OCAL Dialog done XD )

PS: Anyone who hasn't commented yet, please do, there is no deadline as
such :)

Cheers,

-- 
Andrew

2011/4/8 Andrew <rugby471@...>:
> The trouble is with having the buttons with no 'relief' is that it is
> not immediately obvious what they are (i.e. from a first look, how do I
> distinguish them from the icons in the bottom left?)

Those buttons are similar to the mode selection in toolbars (e.g. in
the tweak tool), so if there is a new widget for this, the toolbar
could also benefit.

> Ideally, I would like to have some like in the image
> http://bit.ly/gn2q7z , a 'ToggleButtonGroup', alas GTK doesn't have this
> widget yet, however that is not to say it would be impossible to create :)

This looks very nice, and the widget part would be simple to do, but
I'm not sure how to draw this decoration.

> Okay then I guess we prefer sliders :) On the note of that custom widget
> GIMP is using, I think that is quite interesting, reminds me (in a good
> way) of the volume widget iTunes has on the iPad. Whilst I think the
> ideas behind it are great, I don't think it is a polished as it could
> be, but definitely something to think about in the future.

This "super slider" is very good and we should use it. It's also an
opportunity to introduce another important change: some of the sliders
should have a logarithmic scale. When blurring, precision is not
important when adding a large blur, but essential when adding a small
blur. It allows us to cover a larger range of values while keeping the
slider useful, which is of particular importance in filters.

Regards, Krzysztof

Andrew <rugby471@...> writes:

> 
> Hi again :)
> 
> Okay so after previous feedback, that the comboboxes for the fill type
> and fill rule were not optimal (i.e. it is quicker to click a button
> than select something from a combobox), I have ammended the mockups,
> adding back in the buttons.
> 
> I also corrected some padding in places, where I seem to have gone a bit
> mad with it :)

My biggest problem with the current design was that it took too much horizontal
space. When using Inkscape on Ubuntu, at least, you get mad spacing and padding
everywhere and there's scant little space left for the actual canvas. In that
respect, your new desing show little improvement. I'd favor any design that made
this dialog less wide.

There's a lot of useless padding in your design, and the bottleneck seems to be
the self-intersect button. Move this away from the fill type button row and you
could make the dialog narrower. Perhaps it could be moved between the out of
gamut warning label and the hex code? Not an ideal place, logically, but it
would help with the width issue.

Hi,

> My biggest problem with the current design was that it took too much horizontal
> space. When using Inkscape on Ubuntu, at least, you get mad spacing and padding
> everywhere and there's scant little space left for the actual canvas. In that
> respect, your new desing show little improvement. I'd favor any design that made
> this dialog less wide.

I agree with this, the canvas should have the most screen space, not the
chrome.

> There's a lot of useless padding in your design,

..I wouldn't agree with this, all the padding is in there for a reason,
so elements can easily be distinguished etc.

> and the bottleneck seems to be
> the self-intersect button. Move this away from the fill type button row and you
> could make the dialog narrower. Perhaps it could be moved between the out of
> gamut warning label and the hex code? Not an ideal place, logically, but it
> would help with the width issue.

I should point out that these are only mockups, so the dialog may become
narrower when it is actually implemented.

Regarding your suggestion, I don't think this would make any difference.
It would just mean the width of the dialog would shrink to the width of
the bottom row (with the new intersect buttons in). However that row
would now be quite wide, so as well as not really shrinking, the buttons
are now in an illogical place.

-- 
Andrew

On 4/9/11, Michael Grosberg wrote:

> There's a lot of useless padding in your design, and the bottleneck seems to
> be the self-intersect button.

Tell me, how often do you open "Stroke Style" tab? :)

Alexandre Prokoudine
http://libregraphicsworld.org

On 2011-04-09 17:44, Alexandre Prokoudine wrote:
> On 4/9/11, Michael Grosberg wrote:
>> There's a lot of useless padding in your design, and the bottleneck seems to
>> be the self-intersect button.
> Tell me, how often do you open "Stroke Style" tab? :)
Not sure about others, but I certainly open it all the time. I could
imagine a layout where it would be separate from fill and stroke, but I
think that might be a bit beyond what's currently on the table.

On 4/9/11, Jasper van de Gronde wrote:

>>> There's a lot of useless padding in your design, and the bottleneck seems
>>> to
>>> be the self-intersect button.
>> Tell me, how often do you open "Stroke Style" tab? :)
> Not sure about others, but I certainly open it all the time. I could
> imagine a layout where it would be separate from fill and stroke, but I
> think that might be a bit beyond what's currently on the table.

I was merely referring to the fact that it's the "Stroke Style" tab
that makes the dialog so wide due to combination of labels and
long-ish comboboxes in a single row. The whole dialog adapts it width
to the width of the widest tab's content.

We could actually ditch comboboxes for selecting arrowheads and
introduce a widget similar to GIMP's one for various resources like
brushes, where a button opens a grid/table selector. If we are going
to ever make vector brushes a no-brainer to use, we'll need such
widget anyway.

Likewise we could steal dash pattern editor from GIMP (open Edit >
Stroke selection, expand "Line style", and you'll see it).

Alexandre Prokoudine
http://libregraphicsworld.org

On 9/4/11 22:22, Alexandre Prokoudine wrote:
> On 4/9/11, Jasper van de Gronde wrote:
>>>> There's a lot of useless padding in your design, and the bottleneck seems
>>>> to be the self-intersect button.
>>> Tell me, how often do you open "Stroke Style" tab? :)
>>
>> Not sure about others, but I certainly open it all the time. I could
>> imagine a layout where it would be separate from fill and stroke, but I
>> think that might be a bit beyond what's currently on the table.
> 
> I was merely referring to the fact that it's the "Stroke Style" tab
> that makes the dialog so wide due to combination of labels and
> long-ish comboboxes in a single row. The whole dialog adapts it width
> to the width of the widest tab's content.

For a demonstration, download this file (from an unrelated report in the
bug tracker):
<https://bugs.launchpad.net/inkscape/+bug/596842/+attachment/1432106/+files/SequenceFlowDefault.svg>
open in Inkscape and check the width of the 'Fill & Stroke' dialog...

This is an example for the strings used in the popup lists/comboboxes
for the markers (sample file was created by a third-party application),
the same can happen with custom patterns, and does happen with different
translations which may use longer strings for the labels of the options
or notebook tabs.


~suv

On Sat, Apr 9, 2011 at 1:22 PM, Alexandre Prokoudine <
alexandre.prokoudine@...> wrote:

> On 4/9/11, Jasper van de Gronde wrote:
>
> >>> There's a lot of useless padding in your design, and the bottleneck
> seems
> >>> to
> >>> be the self-intersect button.
> >> Tell me, how often do you open "Stroke Style" tab? :)
> > Not sure about others, but I certainly open it all the time. I could
> > imagine a layout where it would be separate from fill and stroke, but I
> > think that might be a bit beyond what's currently on the table.
>
> I was merely referring to the fact that it's the "Stroke Style" tab
> that makes the dialog so wide due to combination of labels and
> long-ish comboboxes in a single row. The whole dialog adapts it width
> to the width of the widest tab's content.
>

I never knew this tab was the offender... good to be aware of. Shows how
often *I* open it. ;)


> We could actually ditch comboboxes for selecting arrowheads and
> introduce a widget similar to GIMP's one for various resources like
> brushes, where a button opens a grid/table selector. If we are going
> to ever make vector brushes a no-brainer to use, we'll need such
> widget anyway.
>

Agreed.


> Likewise we could steal dash pattern editor from GIMP (open Edit >
> Stroke selection, expand "Line style", and you'll see it).
>

I've never seen that before and I think it's fantastic.

Cheers,
Josh

Alexandre Prokoudine <alexandre.prokoudine@...> writes:

> 
> On 4/9/11, Jasper van de Gronde wrote:
> 
> >>> There's a lot of useless padding in your design, and the bottleneck seems
> >>> to
> >>> be the self-intersect button.
> >> Tell me, how often do you open "Stroke Style" tab? :)
> > Not sure about others, but I certainly open it all the time. I could
> > imagine a layout where it would be separate from fill and stroke, but I
> > think that might be a bit beyond what's currently on the table.
> 
> I was merely referring to the fact that it's the "Stroke Style" tab
> that makes the dialog so wide due to combination of labels and
> long-ish comboboxes in a single row. The whole dialog adapts it width
> to the width of the widest tab's content.

If that is the case, then it is not apparent to a user. 
here's a screenshot of the dialog:
http://www.booki.cc/inkscape-1/_v/1.0/static/Inkscape-StrokeStyle-strokestyle-en.png
There are very long drop-down boxes for markers which coulod be shrunk easily,
and plenty of padding to the right of the labels.
What specifically in the stroke editor inhibits shrinking? 
Perhaps it's something that's only apparent in other languages such as German?
I know the common wisdom is to keep 33% spare space for German in strings.

Have you thought about switching the position of RGB and HSL tabs?
Usability-wise RGB color picker is much harder to use than HSL picker
or color wheel, so I'm not sure why it's the default one.

On Fri, Apr 8, 2011 at 12:07 PM, Andrew <rugby471@...> wrote:
> Hi again :)
>
> Okay so after previous feedback, that the comboboxes for the fill type
> and fill rule were not optimal (i.e. it is quicker to click a button
> than select something from a combobox), I have ammended the mockups,
> adding back in the buttons.
>
> I also corrected some padding in places, where I seem to have gone a bit
> mad with it :)
>
> Please see the two mockups here
> http://wiki.inkscape.org/wiki/index.php/Fill_and_Stroke_Dialog_Re-Design#My_Solution.28s.29
>
> Again I really do welcome feedback, positive or negative :)
>
> --
> Andrew
>

On 4/12/11, Jarek Foksa wrote:
> Have you thought about switching the position of RGB and HSL tabs?
> Usability-wise RGB color picker is much harder to use than HSL picker
> or color wheel, so I'm not sure why it's the default one.

In my not so humble opinion the whole approach needs rethinking. Right
now the only way to stick to a custom color space is to link to
profile in the document and always use the CMS tab. Switching to any
other color model without abandoning selected color space is not
possible. This is rather silly.

Alexandre Prokoudine
http://libregraphicsworld.org

To be quite honest, I really want to be able to use stroke
styles more effectively, but there's something I find extremely
annoying about having to open such a huge tab just to get an
arrow on one end. For that tiny arrow I have to temporarily hide
a third of my workspace, often covering part of the lines I'm
working on (and I have wide screen).

I forgot if this has ever been proposed, but could there ever
be a checkbox in tool options or on the side of the tool control
bar, where you can click and add options onto the tool control
bar?

What I'd like to have is a simple set of three drop-downs + dash:
[ ] [ ] [ ] Dash: [   ]

The drop-downs only show a visual preview of the markers, not the
names. I know many people Don't want it, but want options
completely different from what I want, thus the toggling options,
like "Visible buttons" in Libre Office and other office programs. 
Can this be achieved simply in GTK right now?

On 4/13/11, Valerie wrote:

> To be quite honest, I really want to be able to use stroke
> styles more effectively, but there's something I find extremely
> annoying about having to open such a huge tab just to get an
> arrow on one end. For that tiny arrow I have to temporarily hide
> a third of my workspace, often covering part of the lines I'm
> working on (and I have wide screen).

As far as I recall, the plan was to add arrow heads chooser to
Path/Pen tools options toolbar, but nobody ever did it.

> I forgot if this has ever been proposed, but could there ever
> be a checkbox in tool options or on the side of the tool control
> bar, where you can click and add options onto the tool control
> bar?

We do have a plan of making toolbars (more) configurable, but maybe
not just that configurable. Jon Cruz is your man there.

Alexandre Prokoudine
http://libregraphicsworld.org

> You can see my findings and my suggestion on the Wiki, but to entice you
> to read it, the mockup is here :)
> 
> http://wiki.inkscape.org/wiki/index.php/Fill_and_Stroke_Dialog_Re-Design > http://wiki.inkscape.org/wiki/index.php/File:Solution-fillandstrokedialog.png > 
> Thanks and I would love to hear your comments!
> 

Created a patch and screenshot for this in https://bugs.launchpad.net/inkscape/+bug/1000023