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_h... 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.