On 10/22/07, Joshua Facemyer <faceman@...1574...> wrote:
But the alpha controls for fill and stroke affect only that part of the selection, so it makes a difference that you know whether you're affecting the opacity of the object or its fill/stroke. I realize that it is fairly intuitive to assume that "opacity" would affect the selection and that the fill part of the selection should have a more particular designation, but that's not necessarily perfectly obvious to everyone.
Again, almost everything in Inkscape works on selection. Fill is the fill of selection. Since we don't have "selection fill opacity", we don't need "selection opacity".
reason not to put the gradient editor there), but it should not be able to be confused with the controls for editing the fill or the stroke colors.
If you are confused with the fact that fill tab sets stop color, again, just don't use it! It's not the only way to set stop color. If a user would find it weird, he'll just never think of the possibility unless directed to it by someone, so it will never confuse him.
Why? It would be less logical in the sense that gradients are separate entities from objects (from a programming point of view),
The tabs must present sibling concepts. "Fill" and "gradients" are not siblings.
Even still, I think my suggestion about putting the selection opacity completely on the status bar would improve usability and intuitive usefulness greatly. Maybe even the blur could go there too.
Sure, that's why I put O: there in the first place, and I plan to add a B: spinbutton there too. But for a full slider, there's simply not enough room there. Why don't you bug GTK so they implement a combined spinbutton+slider widget that would allow dragging and yet be as compact as a spinbutton. I will use it there when it's available.