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,