> 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
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:
> 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  from the inkscape-devel archives 
> (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 
> 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