I found that a small bug in the Oct 18 build where the opacity for an object was incorrect.
I had two object sharing the same gradient. One object was more opaque than the other even though the opacity for both was 100.
I checked the XML editor and found that whilst both objects had Opacity:1, one of them had fill-opacity:0.71.
I don't know how to reproduce this. It only happened once in an entire drawing.
On a side note, I had been getting very confused when making a stop on a gradient transparent. I would change the Alpha value and the gradient would reflect the change, but later I would see the alpha value would be 255 instead of what I had set and what I saw on the graduent. It took me ages to spot that the alpha value was being replaced with the Master Opacity. Is this something that is still being worked on?
On 10/21/07, microUgly <drworm@...1743...> wrote:
On a side note, I had been getting very confused when making a stop on a gradient transparent. I would change the Alpha value and the gradient would reflect the change, but later I would see the alpha value would be 255 instead of what I had set and what I saw on the graduent. It took me ages to spot that the alpha value was being replaced with the Master Opacity. Is this something that is still being worked on?
What you call "alpha" is actually fill opacity or stroke opacity, depending on what it's applied to. SVG provides them separately from master opacity of object, and Inkscape supports them in Fill&Stroke dialog. But these properties are generally less intuitive and less convenient, and it is recommended to use master opacity wherever possible instead. With gradient stops, the notions of fill and stroke are simply not applicable. For these reasons, some time ago I switched the UI for displaying and changing gradient stop opacity to use the master opacity control. Note that this is also an approximation; what is really used in SVG is "stop-opacity" which is neither (master) "opacity" nor "fill/stroke-opacity". But this convention makes more sense and allows you to e.g. adjust the opacity of a gradient stop using the selected style indicator in the statusbar, without opening the Fill&Stroke dialog.
bulia byak wrote:
But these properties are generally less intuitive and less convenient, and it is recommended to use master opacity wherever possible instead.
As a user and someone who is unfamiliar with the SVG standard, I've always associated the "Master Opacity" with controlling the overall opacity of an object (I'm pretty sure that was its only function in 0.45?). So it's confusing, now, to have to understand that Master Opacity now controls the Opacity of the object and the opacity of colour stops, but not the opacity of solid fills where you should use Alpha.
Just to start: I'm using the latest autobuild which is already quite old. I'm not 100% that what I say still applies, but it seems like it does.
As I understand it, the difference is, _where_ in the XML the opacity is set. Master creates an <alpha> tag, while the other just sets the alpha-value for the colour. Point is: as a user, I don't really care. I cannot help thinking, that "Master opacity" should _always_ set the opacity of the whole object. No matter what is selected. That said the current behaviour is really strange... when selecting a gradient stop and changing its opacity in the alpha-channel, that jumps back to 255 and the master opacity is adjusted instead. Some redesign of the fill and Stroke dialogue is needed. Unfortunately I don't yet have the real solution.
I think That maybe we should have the colour chooser as well in the gradient "tab" of the dialogue and call it Stop colour... which would kind of mean reintegrating the old gradient dialogue.... however, this part of the fill and stroke is a little like that anyways. Talking about this part of the Fill&Stroke, I would also put the radial and linear into the same top level and have a option menu next to the Repeat drop down.
Anyways, that is not the real problem we're talking about. To really achieve everything one might want, the gradient and the pattern fill would need an extra "gradient/pattern opacity" slider, respectively. That slider would adjust the overall opacity of the gradient or pattern. We could also have an overall fill (respectively stroke) opacity for this actually. Well, this approach still doesn't allow me to select multiple stops, though and change their opacity... However, I consider this a problem of the A-slider, kind of. I mean it the dialogue doesn't allow me to change the blue-value of a number of selected stops at the same time, either. It's kin of the same, don't you think?
Well, sorry, for this potpourri of thoughts... I hope it'll help to find some solution.
Take care!
David
On Sat, 2007-10-20 at 22:35 -0700, microUgly wrote:
bulia byak wrote:
But these properties are generally less intuitive and less convenient, and it is recommended to use master opacity wherever possible instead.
As a user and someone who is unfamiliar with the SVG standard, I've always associated the "Master Opacity" with controlling the overall opacity of an object (I'm pretty sure that was its only function in 0.45?). So it's confusing, now, to have to understand that Master Opacity now controls the Opacity of the object and the opacity of colour stops, but not the opacity of solid fills where you should use Alpha.
On 10/21/07, microUgly <drworm@...1743...> wrote:
As a user and someone who is unfamiliar with the SVG standard, I've always associated the "Master Opacity" with controlling the overall opacity of an object (I'm pretty sure that was its only function in 0.45?). So it's confusing, now, to have to understand that Master Opacity now controls the Opacity of the object and the opacity of colour stops,
That's perfectly logical. It controls the opacity of what's selected. When object is selected, it sets the opacity of the object. When a stop is selected, it sets the opacity of the stop.
On 10/21/07, microUgly <drworm@...1743...> wrote:
I had two object sharing the same gradient. One object was more opaque than the other even though the opacity for both was 100.
I checked the XML editor and found that whilst both objects had Opacity:1, one of them had fill-opacity:0.71.
So what is the bug?
bulia byak wrote:
So what is the bug?
Sorry, the bug is that the objects fill was semi opaque when I never set that value and could not reset the value without digging into the XML editor. Everything in the GUI said it should have been solid, when it wasn't.
On 10/21/07, microUgly <drworm@...1743...> wrote:
bulia byak wrote:
So what is the bug?
Sorry, the bug is that the objects fill was semi opaque when I never set that value and could not reset the value without digging into the XML editor. Everything in the GUI said it should have been solid, when it wasn't.
Again, fill-opacity is the "A" slider in fill&stroke dialog. You might have dragged it accidentally.
bulia byak wrote:
Again, fill-opacity is the "A" slider in fill&stroke dialog. You might have dragged it accidentally.
There is no "A" slider when an object has a gradient fill. But perhaps I'm not looking in the right place?
On 10/21/07, microUgly <drworm@...1743...> wrote:
bulia byak wrote:
Again, fill-opacity is the "A" slider in fill&stroke dialog. You might have dragged it accidentally.
There is no "A" slider when an object has a gradient fill. But perhaps I'm not looking in the right place? -- View this message in context: http://www.nabble.com/Opacity-Bug--tf4664986.html#a13326264 Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Gotta admit that this change confused the heck out of me when I was working with some gradients the other day. The fact that the global opacity slider changes behaviour when a stop is/isnt selected without any discernable indication that its done so is confusing as hell. It also doesnt seem to go back to being what its actually labelled as when you deselect all the stops, it stays saying its semi transparent when as a master opacity value for the object it shouldnt be. It also doesnt do what I expect if I have multiple stops selected. if I select all the stops, and change the master opacity I would expect the overall opacity to change but the stops relative opacity to remain the same, not them all to go ot the same one. Over riding something thats already got a well established purpose is a bad idea imo. At least changing the label text for the slider would help. on canvas editing does rock tho :D
Cheers
Sim
john cliff-2 wrote:
Over riding something thats already got a well established purpose is a bad idea imo.
You explained that so much better than I could. Thanks.
On 10/21/07, john cliff <john.cliff@...400...> wrote:
Gotta admit that this change confused the heck out of me when I was working with some gradients the other day. The fact that the global opacity slider changes behaviour when a stop is/isnt selected without any discernable indication that its done so is confusing as hell.
Oh come on - why aren't you saying the same about the color controls? They also reflect either object or gradient stop(s) depending on what is selected, and always did. I just changed the opacity to behave the same, for consistency.
It also doesnt seem to go back to being what its actually labelled as when you deselect all the stops, it stays saying its semi transparent when as a master opacity value for the object it shouldnt be.
Ah, I think I finally understand what you are referring to here. That inadvertent change in object opacity is just a bug and I'll fix it.
It also doesnt do what I expect if I have multiple stops selected. if I select all the stops, and change the master opacity I would expect the overall opacity to change but the stops relative opacity to remain the same, not them all to go ot the same one.
That's 100% consistent with how you change opacity of multiple objects, and with color controls too. They all, with multiple entities selected, set the same color/opacity on all entities. For a "relative" change as you describe you need a different tool (for example Tweak with zero opacity and only the O channnel enabled).
bulia byak wrote:
On 10/21/07, john cliff <john.cliff@...400...> wrote:
Gotta admit that this change confused the heck out of me when I was working with some gradients the other day. The fact that the global opacity slider changes behaviour when a stop is/isnt selected without any discernable indication that its done so is confusing as hell.
Oh come on - why aren't you saying the same about the color controls? They also reflect either object or gradient stop(s) depending on what is selected, and always did. I just changed the opacity to behave the same, for consistency.
First, let me apologize that I just woke up and my brain isn't fully with it yet. ;)
I guess that since I was aware of how it worked when the change was originally committed, it wasn't foreign or strange to me at all and I wouldn't have it any other way. As with so many other things in inkscape, it's selection based and consistent with whatever type of selection you're working with. This is one of the key features that makes gradient editing on canvas as incredibly powerful as it is.
So, that's my .02... it rocks and is consistent with all other selection based controls in inkscape.
And for those who may not use the Opacity widget in the statusbar too much, there are some nice little tricks with it. Middle-clicking the O: label cycles the value to 0, 50, or 100. Also, middle clicking the up and down arrows moves in increments of 10 (so if you have it set at 17 and middle-click the up arrow, it will jump to 27). The only issue I've run into is when you have complex docs like I do, sometimes it jump by 20 instead. ;) And lastly, you can use your mouse scroll wheel on the widget to save some clicking. There may be more, but those are the ones I use all the time.
Since we're talking about gradient editing... is it a bug or feature that snapping to angles with the gradient tool no longer works (when you hold Ctrl and are dragging an end handle). I seriously miss this.
Anyway... a big thank you to Bulia and Johan for making on-canvas gradient editing as easy and efficient as it is.
-Josh
On 10/21/07, bulia byak <buliabyak@...400...> wrote:
On 10/21/07, john cliff <john.cliff@...400...> wrote:
Gotta admit that this change confused the heck out of me when I was working with some gradients the other day. The fact that the global opacity slider changes behaviour when a stop is/isnt selected without any discernable indication that its done so is confusing as hell.
Oh come on - why aren't you saying the same about the color controls? They also reflect either object or gradient stop(s) depending on what is selected, and always did. I just changed the opacity to behave the same, for consistency.
But you havent, you've changed it to behave differently. Every where else the alpha for whats being edited, be it fil/stroke, is controlled by the fourth slider of the color bit, and the opacity of the whole object selected is controlled by the master bit. I think the disconnect here in thinking is what the selection is. As far as I would think about it, the selection is still the object with the gradient applied, I'd expect the master opacity to edit the opacity of that, like it does under every other situation.
It also doesnt seem to go back to being what its actually labelled as when you deselect all the stops, it stays saying its semi transparent when as a master opacity value for the object it shouldnt be.
Ah, I think I finally understand what you are referring to here. That inadvertent change in object opacity is just a bug and I'll fix it.
It also doesnt do what I expect if I have multiple stops selected. if I select all the stops, and change the master opacity I would expect the overall opacity to change but the stops relative opacity to remain the same, not them all to go ot the same one.
That's 100% consistent with how you change opacity of multiple objects, and with color controls too. They all, with multiple entities selected, set the same color/opacity on all entities. For a "relative" change as you describe you need a different tool (for example Tweak with zero opacity and only the O channnel enabled).
john cliff wrote:
On 10/21/07, bulia byak <buliabyak@...400...> wrote:
On 10/21/07, john cliff <john.cliff@...400...> wrote:
Gotta admit that this change confused the heck out of me when I was working with some gradients the other day. The fact that the global opacity slider changes behaviour when a stop is/isnt selected without any discernable indication that its done so is confusing as hell.
Oh come on - why aren't you saying the same about the color controls? They also reflect either object or gradient stop(s) depending on what is selected, and always did. I just changed the opacity to behave the same, for consistency.
But you havent, you've changed it to behave differently. Every where else the alpha for whats being edited, be it fil/stroke, is controlled by the fourth slider of the color bit, and the opacity of the whole object selected is controlled by the master bit. I think the disconnect here in thinking is what the selection is. As far as I would think about it, the selection is still the object with the gradient applied, I'd expect the master opacity to edit the opacity of that, like it does under every other situation.
I think it's matter of perspective. It really makes sense once you look at gradient stops as objects. You mention that the selection is still an object, but just with a gradient applied. Should you only be able to move an actual object (as opposed to conceptual) with arrows keys and therefore not be able to use the arrow keys to move nodes or gradient stops? You can almost look at gradient stops like nodes... should tabbing in the node tool not tab through nodes but instead tab objects? (since they're not really objects... just the node of an object)
You can't currently "select" the fill or stroke of an object with a tool, so performing opacity operations on an object level makes sense (as the object is what's selected). Otherwise how would it know if you're attempting to change the fill's opacity/alpha or that of the stroke? With gradient stops, you can select those "objects" and can therefore change the alpha/opacity of said object(s) with that spinbutton. Even in the gradient tool, if you want the opacity change to be performed on an object level, deselect any selected stops and use the spinbutton... in fact, that treats the object as you say it should... an object with a gradient applied (since you don't have a specific component/stop of said gradient selected).
Would you want it to change the label from O: to A: to reflect the difference in operation behavior? It seems unnecessary, but if people that use inkscape quite a bit (and have for years) have become confused... perhaps that's not a terrible idea? All I know is that my workflow will effectively be trashed if this is taken out, as it's really intuitive once you change how you look at selections.
-Josh
On 10/21/07, Josh Andler <scislac@...400...> wrote:
john cliff wrote:
On 10/21/07, bulia byak <buliabyak@...400...> wrote:
On 10/21/07, john cliff <john.cliff@...400...> wrote:
Gotta admit that this change confused the heck out of me when I was working with some gradients the other day. The fact that the global opacity slider changes behaviour when a stop is/isnt selected without any discernable indication that its done so is confusing as hell.
Oh come on - why aren't you saying the same about the color controls? They also reflect either object or gradient stop(s) depending on what is selected, and always did. I just changed the opacity to behave the same, for consistency.
But you havent, you've changed it to behave differently. Every where else the alpha for whats being edited, be it fil/stroke, is controlled by the fourth slider of the color bit, and the opacity of the whole object selected is controlled by the master bit. I think the disconnect here in thinking is what the selection is. As far as I would think about it, the selection is still the object with the gradient applied, I'd expect the master opacity to edit the opacity of that, like it does under every other situation.
I think it's matter of perspective. It really makes sense once you look at gradient stops as objects. You mention that the selection is still an object, but just with a gradient applied. Should you only be able to move an actual object (as opposed to conceptual) with arrows keys and therefore not be able to use the arrow keys to move nodes or gradient stops? You can almost look at gradient stops like nodes... should tabbing in the node tool not tab through nodes but instead tab objects? (since they're not really objects... just the node of an object)
Never knew you could tab through nodes. thats pretty cool... but thats a different issue, its not the same at all. In all the other modes, the top four sliders affect the fill/stroke thats being edited on screen, the alpha slider is associated to the color being edited, and the master teh wohle object, how is a stop any different, the first 4 are the stop being edited, the master should be the whole object. At the end of the day we still have selection markers shown for the parent object, so the master association should logically be that object.
You can't currently "select" the fill or stroke of an object with a tool, so performing opacity operations on an object level makes sense (as the object is what's selected). Otherwise how would it know if you're attempting to change the fill's opacity/alpha or that of the stroke? With gradient stops, you can select those "objects" and can therefore change the alpha/opacity of said object(s) with that spinbutton. Even in the gradient tool, if you want the opacity change to be performed on an object level, deselect any selected stops and use the spinbutton... in fact, that treats the object as you say it should... an object with a gradient applied (since you don't have a specific component/stop of said gradient selected).
Your changing the alpha of the stop thats selected, I have no problem with that concept, I just dont see why we're making the alpha slider associated with the color useless, and killing the functionality of the master one. we've essentially disabled one to let the other do the same thing, and lost control of the overall object. The last point, is exactly what I'm trying to say, it suddenly switches back to a different function, with no indication whatsoever. If this is all about the little slider at the bottom, have it do something different, I have no great issue with that, although I would change the label dynamically to indicate what its affecting. its why the fill stroke dialog itself suddenly behaves differently that I have issues with, as master opacity stops doing what its labelled as when you select a stop.
Would you want it to change the label from O: to A: to reflect the difference in operation behavior? It seems unnecessary, but if people that use inkscape quite a bit (and have for years) have become confused... perhaps that's not a terrible idea? All I know is that my workflow will effectively be trashed if this is taken out, as it's really intuitive once you change how you look at selections.
The O/A is the little quick pick thing right? I have no issue with that changing dynamically, although I do think a label change to indicte its not master opacity its changing would make sense. I'll chat with you on jabber about htis when gristle is working again. I'm not sure we're talking about 100% the same thing here...
john cliff wrote:
On 10/21/07, Josh Andler <scislac@...400...> wrote:
--snip--
You can't currently "select" the fill or stroke of an object with a tool, so performing opacity operations on an object level makes sense (as the object is what's selected). Otherwise how would it know if you're attempting to change the fill's opacity/alpha or that of the stroke? With gradient stops, you can select those "objects" and can therefore change the alpha/opacity of said object(s) with that spinbutton. Even in the gradient tool, if you want the opacity change to be performed on an object level, deselect any selected stops and use the spinbutton... in fact, that treats the object as you say it should... an object with a gradient applied (since you don't have a specific component/stop of said gradient selected).
Your changing the alpha of the stop thats selected, I have no problem with that concept, I just dont see why we're making the alpha slider associated with the color useless, and killing the functionality of the master one. we've essentially disabled one to let the other do the same thing, and lost control of the overall object. The last point, is exactly what I'm trying to say, it suddenly switches back to a different function, with no indication whatsoever. If this is all about the little slider at the bottom, have it do something different, I have no great issue with that, although I would change the label dynamically to indicate what its affecting. its why the fill stroke dialog itself suddenly behaves differently that I have issues with, as master opacity stops doing what its labelled as when you select a stop.
Ahhhh... now this is making more sense. This is a bug in the F&S dialog rather than the functionality of the opacity spinbutton in the statusbar. A bugfix in the F&S dialog would untie the dialog's "master opacity" slider from the statusbar opacity spinbutton. That way the F&S dialog's "master opacity" slider is working on the object level, since the alpha slider takes care of the stop's color. Is this wrong?
And in addition to that, the O: label changing to A: in the statusbar would help to clarify the context change for that, right? And yeah, jabber has been down for a while, but I think we're on the same page now. :-)
-Josh
Josh Andler wrote:
And in addition to that, the O: label changing to A: in the statusbar would help to clarify the context change for that, right?
But is using the Opacity slider an improvement over using the Alpha colour picker?
I agree that if "Master Opacity" is going to be used to control the opacity of a colour stop then it shouldn't be called "Master" anymore. But what advantage does the Opacity slider offer? It seems like a step backwards to abondon a colour picker that lets you see how transparent it will appear.
It's argued that Opacity makes more sense for colour stops because they are objects. But in my mind they are... stops... of colour - sorry, can't explain it better. I have no concept that they are an object and that should be treated like an object. To me they are just colour and Inkscape has always used RGBA when refering to colour.
If Alpha is going to abondoned for Opacity then the Alpha colour selector has to disappear when a stop is selected. Having it there is only going to cause confusion.
On 10/21/07, microUgly <drworm@...1743...> wrote:
I agree that if "Master Opacity" is going to be used to control the opacity of a colour stop then it shouldn't be called "Master" anymore.
Agreed, it's probably time to drop "master". It was called that when it was first added to the UI, to differentiate it from the fill/stroke opacity. Now it's established itself and largely replaced the fill/stroke opacity, so we can call it simply "opacity", _the_ opacity.
But what advantage does the Opacity slider offer? It seems like a step backwards to abondon a colour picker that lets you see how transparent it will appear.
For flat color, yes, the fill/stroke opacity sliders do allow you to see the color. But for many other situations - such as entire objects if they have gradient or pattern fill - this color preview is not applicable and will in fact be confusing.
It's argued that Opacity makes more sense for colour stops because they are objects. But in my mind they are... stops... of colour - sorry, can't explain it better.
They are not objects. They are just somethings that can be selected just like objects. The general principle of Inkscape UI is to treat similar things in similar ways. Hence, for all somethings that can have opacity, we should use the same opacity controls, command, shortcuts, etc.
If Alpha is going to abondoned for Opacity then the Alpha colour selector has to disappear when a stop is selected. Having it there is only going to cause confusion.
Yes, agreed. Please file a RFE on that when you have time.
Sorry, I'm sure you're growing tired of this converstation :)
bulia byak wrote:
For flat color, yes, the fill/stroke opacity sliders do allow you to see the color. But for many other situations - such as entire objects if they have gradient or pattern fill - this color preview is not applicable and will in fact be confusing.
Like you say, Opacity doesn't need a colour preview because traditionally it was applied to a whole object (stroke and fill). But a single selected stop only has one colour (it is flat) so wouldn't it makes sense to maintain a colour preview of the transparency just like you maintain a colour preview of RGB?
If stops don't need an Alpha color preview, why do flats (solid fill) need an Alpha preview? Why wouldn't flats abondon Alpha for Opacity also? Or is this the intention?
On 10/21/07, microUgly <drworm@...1743...> wrote:
If stops don't need an Alpha color preview, why do flats (solid fill) need an Alpha preview? Why wouldn't flats abondon Alpha for Opacity also? Or is this the intention?
Ideally, yes. This would simplify things. But we can't really do this because SVG has fill-opacity and stroke-opacity properties and we must support them both in rendering and in the UI. However, they are sort of deprecated, simply because in many cases they are redundant and therefore confusing.
bulia byak wrote:
On 10/21/07, microUgly <drworm@...1743...> wrote:
I agree that if "Master Opacity" is going to be used to control the opacity of a colour stop then it shouldn't be called "Master" anymore.
Agreed, it's probably time to drop "master". It was called that when it was first added to the UI, to differentiate it from the fill/stroke opacity. Now it's established itself and largely replaced the fill/stroke opacity, so we can call it simply "opacity", _the_ opacity.
I always understood the infobar opacity to affect all selected objects. If this is true (and the intention is to keep it so), could it not simply be renamed "Selection Opacity" to make sure it's not confused with the fill or stroke opacity? Maybe then the "Master Opacity" slider in the F&S dialog can be removed (since it isn't directly dealing with the fill or stroke properties of anything, necessarily), and a slider place in the infobar by the "Selection Opacity".
But what advantage does the Opacity slider offer? It seems like a step backwards to abondon a colour picker that lets you see how transparent it will appear.
For flat color, yes, the fill/stroke opacity sliders do allow you to see the color. But for many other situations - such as entire objects if they have gradient or pattern fill - this color preview is not applicable and will in fact be confusing.
I think it makes sense to have the alpha preview for a gradient stop; I don't think it makes sense to use the fill and stroke tabs to adjust gradient stop colors. That's really confusing, especially when you see both are available while you have a stop selected, and either can be used to affect the color, and on top of that you can still edit stroke style for the whole object without leaving the gradient stop selection. Hmm...
I think the dialog should change from the 3-tab to the gradient editor when a stop is selected or when using the on canvas gradient editor. That would be much more consistent. Maybe add the gradient editor dialog as a 4th tab? (I know its controls are mostly going to be deprecated, but that would make more sense at least for now.) Then you could blank the other tabs when a stop is selected and move to the gradient editor tab.
(Incidentally, why does the Stroke Style tab only get greyed out when it can't be used, instead of blanked like the other two tabs?)
It's argued that Opacity makes more sense for colour stops because they are objects. But in my mind they are... stops... of colour - sorry, can't explain it better.
They are not objects. They are just somethings that can be selected just like objects. The general principle of Inkscape UI is to treat similar things in similar ways. Hence, for all somethings that can have opacity, we should use the same opacity controls, command, shortcuts, etc.
I think confusion could be avoided in this also by using the "Selection Opacity" label. I think the current setup makes a lot of sense, once the ambiguity of the opacity slider in the F&S dialog is taken care of. (Similarly, the blur slider doesn't make a whole lot of sense there anymore, now that we have other filters, and it doesn't affect either fill or stroke separately. I think the issue is really with making everything present in the F&S dialog deal with either the fill or the stroke, depending on which tab is selected.)
JF
On 10/22/07, Joshua Facemyer <faceman@...1574...> wrote:
I always understood the infobar opacity to affect all selected objects. If this is true (and the intention is to keep it so), could it not simply be renamed "Selection Opacity" to make sure it's not confused with the fill or stroke opacity?
No need for "selection". Almost everything in Inkscape is "selection", so it's redundant. Just "opacity".
Maybe then the "Master Opacity" slider in the F&S dialog can be removed (since it isn't directly dealing with the fill or stroke properties of anything, necessarily), and a slider place in the infobar by the "Selection Opacity".
What is "infobar"? Controls bar of some specific tool? But this needs to be accessible in all tools. The O: control in statusbar works most of the time, the only problem with it is that it's not easily draggable, so that's why we also have a slider. I agree that "fill and stroke" is not the most logical place for it but others seem worse.
I think it makes sense to have the alpha preview for a gradient stop; I don't think it makes sense to use the fill and stroke tabs to adjust gradient stop colors.
If it doesn't make sense to you, don't use it :) Use any other method of setting color. They all work the same. For example clicking on the palette.
That's really confusing, especially when you see both are available while you have a stop selected, and either can be used to affect the color, and on top of that you can still edit stroke style for the whole object without leaving the gradient stop selection. Hmm...
Perhaps just disable most of the dialog when gradient stop is selected - but I don't think it's very useful. Although we should probably disable some parts of it - blur slider and fill/stroke opacity for one.
I think the dialog should change from the 3-tab to the gradient editor
Not to "gradient editor" but to something like "color editor". But I really don't think we need to go that far. Undisabled things still apply to the entire object and they still make sense when you select a stop.
That would be much more consistent. Maybe add the gradient editor dialog as a 4th tab?
No, that would be even less logical than it is now.
(Incidentally, why does the Stroke Style tab only get greyed out when it can't be used, instead of blanked like the other two tabs?)
Because you can't create stroke just by setting width - you need to set color first which is done on another tab.
Opacity" label. I think the current setup makes a lot of sense, once the ambiguity of the opacity slider in the F&S dialog is taken care of. (Similarly, the blur slider doesn't make a whole lot of sense there anymore, now that we have other filters, and it doesn't affect either fill or stroke separately.
I disagree. I'd rather rename the dialog instead to something like "properties". Blur is a fundamental property and needs to be adjustable directly and easily, not via some cumbersome "filters".
I think the issue is really with making everything present in the F&S dialog deal with either the fill or the stroke, depending on which tab is selected.)
Note that opacity and blur are NOT on either fill or stroke tabs, it's below them. So the only inconsistency is with the title of the dialog; if you ignore it, it makes perfect sense.
bulia byak wrote:
On 10/22/07, Joshua Facemyer <faceman@...1574...> wrote:
I always understood the infobar opacity to affect all selected objects. If this is true (and the intention is to keep it so), could it not simply be renamed "Selection Opacity" to make sure it's not confused with the fill or stroke opacity?
No need for "selection". Almost everything in Inkscape is "selection", so it's redundant. Just "opacity".
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.
Maybe then the "Master Opacity" slider in the F&S dialog can be removed (since it isn't directly dealing with the fill or stroke properties of anything, necessarily), and a slider place in the infobar by the "Selection Opacity".
What is "infobar"? Controls bar of some specific tool? But this needs to be accessible in all tools. The O: control in statusbar works most of the time, the only problem with it is that it's not easily draggable, so that's why we also have a slider. I agree that "fill and stroke" is not the most logical place for it but others seem worse.
Sorry, statusbar is what I meant. Then it would be available to all tools, and you wouldn't have to open a dialog for it. If you're going to have a control down there anyway, might as well make it really easy to use and put in a slider. I don't think that idea sounds worse at all :)
I think it makes sense to have the alpha preview for a gradient stop; I don't think it makes sense to use the fill and stroke tabs to adjust gradient stop colors.
If it doesn't make sense to you, don't use it :) Use any other method of setting color. They all work the same. For example clicking on the palette.
But it's not consistent, since they are labelled "fill" and "stroke" and you're editing a "stop" color.
That's really confusing, especially when you see both are available while you have a stop selected, and either can be used to affect the color, and on top of that you can still edit stroke style for the whole object without leaving the gradient stop selection. Hmm...
Perhaps just disable most of the dialog when gradient stop is selected
- but I don't think it's very useful. Although we should probably
disable some parts of it - blur slider and fill/stroke opacity for one.
I think that would be better than it is now, anyways.
I think the dialog should change from the 3-tab to the gradient editor
Not to "gradient editor" but to something like "color editor". But I really don't think we need to go that far. Undisabled things still apply to the entire object and they still make sense when you select a stop.
What I'm saying is to disable the Fill and Stroke widgets, since they don't apply to the entire object. Otherwise, if you don't want to disable them, they should act the same way they do when you have the object selected instead of a stop - change the color for the fill of the object or the stroke of the object, not a stop of a gradient. I'd be fine with a simple "color editor" as you suggest (although I don't see a 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.
That would be much more consistent. Maybe add the gradient editor dialog as a 4th tab?
No, that would be even less logical than it is now.
Why? It would be less logical in the sense that gradients are separate entities from objects (from a programming point of view), but if you rename the whole dialog to "properties", as you mention below, then it would make sense that you could edit properties of gradients and their stops there too, especially since it's the same place you edit object colors, which are very closely related to other object fills.
(Incidentally, why does the Stroke Style tab only get greyed out when it can't be used, instead of blanked like the other two tabs?)
Because you can't create stroke just by setting width - you need to set color first which is done on another tab.
So why does it matter if you can see the controls at all, if you can't use them anyways? No big deal, just curious.
Opacity" label. I think the current setup makes a lot of sense, once the ambiguity of the opacity slider in the F&S dialog is taken care of. (Similarly, the blur slider doesn't make a whole lot of sense there anymore, now that we have other filters, and it doesn't affect either fill or stroke separately.
I disagree. I'd rather rename the dialog instead to something like "properties". Blur is a fundamental property and needs to be adjustable directly and easily, not via some cumbersome "filters".
I think the issue is really with making everything present in the F&S dialog deal with either the fill or the stroke, depending on which tab is selected.)
Note that opacity and blur are NOT on either fill or stroke tabs, it's below them. So the only inconsistency is with the title of the dialog; if you ignore it, it makes perfect sense.
Well, if that's the case, then it should be done, considering that users need the application UI to make sense without having to ignoring parts of it :)
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.
JF
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.
bulia byak wrote:
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.
What are the other ways? I always use the fill tab... or the gradient editor.
On 10/22/07, microUgly <drworm@...1743...> wrote:
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.
What are the other ways? I always use the fill tab... or the gradient editor.
Palette swatches. Paste style. Selected style indicator's right-click commands (these are for black/white only for now but I plan to add a more general facility of color changing to this widget by dragging).
bulia byak wrote:
On 10/22/07, microUgly <drworm@...1743...> wrote:
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.
What are the other ways? I always use the fill tab... or the gradient editor.
Palette swatches. Paste style. Selected style indicator's right-click commands (these are for black/white only for now but I plan to add a more general facility of color changing to this widget by dragging).
Ah, so your statement above is only true if the colour you want to use for a stop already exists. Otherwise, Fill is indeed the only way to define a colour for a stop, currently.
On a side note, when copying a style, the opacity/alpha value does not apply to a colour stop.
On 10/22/07, microUgly <drworm@...1743...> wrote:
Ah, so your statement above is only true if the colour you want to use for a stop already exists.
Palette is not big enough? Plus one more method I forgot: dropper tool also works on a selected stop.
On a side note, when copying a style, the opacity/alpha value does not apply to a colour stop.
It does now. Try latest svn.
bulia byak wrote:
Palette is not big enough?
I think it's fair to say most people do not rely solely on the palette for their selection of colours. Yes, because its not big enough and also because it doesn't allow you to find a colour with a little more red, or a little less green, etc.
bulia byak wrote:
It does now. Try latest svn.
Kewl, thanks.
On 10/22/07, microUgly <drworm@...1743...> wrote:
bulia byak wrote:
Palette is not big enough?
I think it's fair to say most people do not rely solely on the palette for their selection of colours. Yes, because its not big enough and also because it doesn't allow you to find a colour with a little more red, or a little less green, etc.
For that, there's one more method I forgot: color modes of the Tweak tool can apply to parts of gradient and even single colors. And yet another method I just added: color gestures. Both are perfect for finely adjusting a color you approximately selected from the palette.
On 10/21/07, bulia byak <buliabyak@...400...> wrote:
It also doesnt seem to go back to being what its actually labelled as when you deselect all the stops, it stays saying its semi transparent when as a master opacity value for the object it shouldnt be.
Ah, I think I finally understand what you are referring to here. That inadvertent change in object opacity is just a bug and I'll fix it.
Actually, I thought I could reproduce this bug but now I can't. Could you please give detailed steps to reproduce it?
On 10/21/07, microUgly <drworm@...1743...> wrote:
There is no "A" slider when an object has a gradient fill.
Exactly, and that has been a problem since Sodipodi. It just needs to be added. Meanwhile, it's another reason to never use the fill/stroke opacity properties as they are "hidden" for gradients and patterns. Just use master opacity always.
bulia byak wrote:
On 10/21/07, microUgly <drworm@...1743...> wrote:
There is no "A" slider when an object has a gradient fill.
Exactly, and that has been a problem since Sodipodi. It just needs to be added. Meanwhile, it's another reason to never use the fill/stroke opacity properties as they are "hidden" for gradients and patterns. Just use master opacity always.
Ah, I see. I've drawn a shape that probably used my last selected style with a low Alpha value. Then I've added a gradient and the Alpha value remained. After that you can't change the Alpha value back, unless you change back to a flat colour, or dig in the XML editor like I did :)
Would it be possible to reset the Alpha value when assigning a gradient to an object?
participants (6)
-
bulia byak -
David Christian Berg -
john cliff -
Josh Andler -
Joshua Facemyer -
microUgly