Color Tweak - Option to not create new gradient
Is there an option so when you tweak the colours of a gradient it modifies the current gradient rather than makes a copy then modifies it?
I normally reuse gradients on multiple objects to intentially keep them same for if I decide to change colours. I don't know if others feel the same, but my preference would be that when I tweak the gradient on one object, all other objects that also use that gradient should change also. Perhaps a toggle in the tool control bar?
On 10/3/07, microUgly <drworm@...1743...> wrote:
Is there an option so when you tweak the colours of a gradient it modifies the current gradient rather than makes a copy then modifies it?
I normally reuse gradients on multiple objects to intentially keep them same for if I decide to change colours.
Unfortunately this workflow is less supported in the new version. Now, gradients are automatically forked if necessary upon any change, so if you change gradient on one object this never affects any other objects. We found that this is a lot more intuitive for users, because in 99% of cases such change of other objects was unexpected and unwanted. This also gets rid of the "Duplicate" button on gradient toolbar whose purpose was pretty difficult to explain to users.
Wanting to use the same gradient on _different_ objects (otherwise you could just use clones) is a valid requirement, of course, but I think it's quite specialized. Perhaps the best way to support it will be via shared styles when we support them.
bulia byak wrote:
Now, gradients are automatically forked if necessary upon any change, so if you change gradient on one object this never affects any other objects.
Oh, no! I can't express how disappointed I am by this decision. I always felt that being able to easily reuse gradients was one of Inkscapes best features.
It was just revealed to me a method of creating a gradient with one stop for the purpose of being able to change flat colour of multiple objects easily (http://www.inkscapeforum.com/viewtopic.php?f=6&t=248#p1362), and now that trick is void.
I'm really sorry I missed the discussion of this decision. I would have been quite vocal :) I'm constantly tweaking colours in my drawing and I relied on the ability to be able to update them all very easily. Colouring in Inkscape will be very clumsy and tedious now.
I won't argue that people new to Inkscape didn't become confused by the system. I will argue that perhaps not enough thought was put into the solution. Inkscape has lost a feature, not gained one.
microUgly wrote:
bulia byak wrote:
Now, gradients are automatically forked if necessary upon any change, so if you change gradient on one object this never affects any other objects.
Oh, no! I can't express how disappointed I am by this decision. I always felt that being able to easily reuse gradients was one of Inkscapes best features.
Agreed. However, you still can re-use them, it's just a little more time consuming now. When you want to change your gradients as you used to, you can click the "Edit" button on the gradient toolbar to do it via the dialog. That method does not auto-fork and updates all shared gradients on canvas from my testing. Unfortunately it lacks the simplicity and speed of the on-canvas gradient editing though.
It was just revealed to me a method of creating a gradient with one stop for the purpose of being able to change flat colour of multiple objects easily (http://www.inkscapeforum.com/viewtopic.php?f=6&t=248#p1362), and now that trick is void.
Yes, that trick can be very helpful... but what you're really in need of is shared styles as bulia mentioned.
I'm really sorry I missed the discussion of this decision. I would have been quite vocal :) I'm constantly tweaking colours in my drawing and I relied on the ability to be able to update them all very easily. Colouring in Inkscape will be very clumsy and tedious now.
I don't think there was really a discussion about this (unless I happened to have missed it). I'm not too fond of the change myself as I mostly use inkscape for Illustration where this was extremely helpful to my workflow. But, at least we still have SOME way to work around it.
I won't argue that people new to Inkscape didn't become confused by the system. I will argue that perhaps not enough thought was put into the solution. Inkscape has lost a feature, not gained one.
I do think that Bulia is correct that for new users, this is good for usability. And with the way these things have happened in the past, in the end we'll have a better way to do it (the question is when that will be).
The best solution is to get our CSS & Styles up to par internally and have a good UI for that. This should serve your needs. Unfortunately as far as I know, JonCruz is the man with the plan on that and he's doing work to get us supporting color profiles correctly currently. But, from my understanding, the work he's been putting into our handling of "paints" is some of the necessary groundwork for proper CSS support.
Bulia, would it be possible for us to have a toggle button on the gradient toolbar that toggles auto-forking? Obviously we would default it to "on". It seems like it would be possible since the gradient editing dialog still maintains the "shared" workflow, however I'm not sure how much has changed in the actual gradient tool and if that would be a pain to implement. What are your thoughts?
-Josh
On 10/3/07, Joshua A. Andler <joshua@...533...> wrote:
Agreed. However, you still can re-use them, it's just a little more time consuming now. When you want to change your gradients as you used to, you can click the "Edit" button on the gradient toolbar to do it via the dialog. That method does not auto-fork and updates all shared gradients on canvas from my testing. Unfortunately it lacks the simplicity and speed of the on-canvas gradient editing though.
Sorry to disappoint, but this button is also going to disappear when the Gradient Editor is purged. All I need to do for this is add a numeric control for stop position onto the toolbar.
Bulia, would it be possible for us to have a toggle button on the gradient toolbar that toggles auto-forking? Obviously we would default it to "on".
OK, for you power users :) I think I can easily add a toggle to never fork the gradient vectors. It should be easy as it's a change in a single place in the code. But, god forbid, it will NEVER be on the toolbar - we've had enough trouble with people turning on "gradient move" button on the Selector toolbar and forgetting about it, and then complaining about weird behavior. Somewhere deep in the prefs would be OK with me :)
bulia byak wrote:
On 10/3/07, Joshua A. Andler <joshua@...533...> wrote:
Agreed. However, you still can re-use them, it's just a little more time consuming now. When you want to change your gradients as you used to, you can click the "Edit" button on the gradient toolbar to do it via the dialog. That method does not auto-fork and updates all shared gradients on canvas from my testing. Unfortunately it lacks the simplicity and speed of the on-canvas gradient editing though.
Sorry to disappoint, but this button is also going to disappear when the Gradient Editor is purged. All I need to do for this is add a numeric control for stop position onto the toolbar.
No disappointment given the option mentioned below. I don't personally use the gradient editor and I only brought it up because I wondered if it would work around that forking.
I hate to ask for anything additional given your willingness to humor us power users, but, is there any chance you'd be willing to look into adding the "no repeat, repeat, & reflect" combobox from the F&S dialog to the toolbar as well? Or do you not feel it fits there?
Bulia, would it be possible for us to have a toggle button on the gradient toolbar that toggles auto-forking? Obviously we would default it to "on".
OK, for you power users :) I think I can easily add a toggle to never fork the gradient vectors. It should be easy as it's a change in a single place in the code. But, god forbid, it will NEVER be on the toolbar - we've had enough trouble with people turning on "gradient move" button on the Selector toolbar and forgetting about it, and then complaining about weird behavior. Somewhere deep in the prefs would be OK with me :)
You rock! I was going to suggest a preference as opposed to toggle button, for the reason you mentioned (I think those four buttons are responsible for the most commonly reported issues). But, I suggested the toggle for the sake of uniformity with the selector tool & the toggling of handles in the node tool. Thank you for accommodating our workflow!
-Josh
On 10/3/07, Joshua A. Andler <joshua@...533...> wrote:
I hate to ask for anything additional given your willingness to humor us power users, but, is there any chance you'd be willing to look into adding the "no repeat, repeat, & reflect" combobox from the F&S dialog to the toolbar as well? Or do you not feel it fits there?
Oh, of course it must be there. Just forgot to mention it.
bulia byak wrote:
OK, for you power users :) I think I can easily add a toggle to never fork the gradient vectors. It should be easy as it's a change in a single place in the code. But, god forbid, it will NEVER be on the toolbar - we've had enough trouble with people turning on "gradient move" button on the Selector toolbar and forgetting about it, and then complaining about weird behavior. Somewhere deep in the prefs would be OK with me :)
I would certainly appreciate this. Although, making the option less accessible may prevent potential power users from finding it. Out of sight is out of mind. New users may never know it exists unless they are explicitly told.
Although, I agree that a global setting should not be on the toolbar. If you want the best of both worlds you should't have to remember to switch it on and off. I think the ideal situation would be if it could be controlled per gradient - in which case it should be on the toolbar. Each gradient would have a checkbox named "Global". This would allow you to decide which gradients will behave independently. The option would be off by default. I believe this is how Illustrator does it for its swatch palette but the option is well hidden in Illustrator and I didn't know about it until after I discovered Inkscape.
On Wed, 2007-10-03 at 18:25 -0400, bulia byak wrote:
Bulia, would it be possible for us to have a toggle button on the gradient toolbar that toggles auto-forking? Obviously we would default it to "on".
OK, for you power users :) I think I can easily add a toggle to never fork the gradient vectors. It should be easy as it's a change in a single place in the code. But, god forbid, it will NEVER be on the toolbar - we've had enough trouble with people turning on "gradient move" button on the Selector toolbar and forgetting about it, and then complaining about weird behavior. Somewhere deep in the prefs would be OK with me :)
How about a verb? Then power users can adjust their key map to add this where ever they'd like. Or, even their menus if they'd like. Heck, you could even do something like adjust your startup to have a "--verb" in it always if you wanted to force it a particular way.
--Ted
On Wed, 03 Oct 2007 16:36:40 -0700, Ted Gould <ted@...11...> wrote:
How about a verb? Then power users can adjust their key map to add this where ever they'd like. Or, even their menus if they'd like. Heck, you could even do something like adjust your startup to have a "--verb" in it always if you wanted to force it a particular way.
It'd need to be two distinct verbs -- otherwise you'd just be toggling it from one potentially unknown state to another. Or three if you also wanted to have a toggle. I'm not sure it'd be worth it...
-mental
On Thu, 2007-10-04 at 10:58 -0700, MenTaLguY wrote:
On Wed, 03 Oct 2007 16:36:40 -0700, Ted Gould <ted@...11...> wrote:
How about a verb? Then power users can adjust their key map to add this where ever they'd like. Or, even their menus if they'd like. Heck, you could even do something like adjust your startup to have a "--verb" in it always if you wanted to force it a particular way.
It'd need to be two distinct verbs -- otherwise you'd just be toggling it from one potentially unknown state to another. Or three if you also wanted to have a toggle. I'm not sure it'd be worth it...
I think verbs are small and that for power users they'd probably want this feature adjustable by hot key. But, I have no intention of implementing it, to the implementer go the design decisions :)
--Ted
On 10/3/07, bulia byak <buliabyak@...400...> wrote:
OK, for you power users :) I think I can easily add a toggle to never fork the gradient vectors. It should be easy as it's a change in a single place in the code. But, god forbid, it will NEVER be on the toolbar - we've had enough trouble with people turning on "gradient move" button on the Selector toolbar and forgetting about it, and then complaining about weird behavior. Somewhere deep in the prefs would be OK with me :)
Done:
However, to accommodate the needs of users who have relied on sharing the same gradient definition across objects, this behavior can be optionally suppressed. The Prevent sharing of gradient definitions checkbox on the Misc tab of Inkscape Preferences is by default checked; if you uncheck it, Inkscape does not automatically copy gradient definitions for new objects, which means that copy/pasting, duplicating, pasting style, and explicit assignment of a gradient to an object via the Gradient tool controls results in a shared gradient definition, so that changing the colors or mid-stop positions of the gradient on one object (but not changing the coordinates of the end handles) affects all other objects that share the same definition.
On 10/3/07, microUgly <drworm@...1743...> wrote:
It was just revealed to me a method of creating a gradient with one stop for the purpose of being able to change flat colour of multiple objects easily (http://www.inkscapeforum.com/viewtopic.php?f=6&t=248#p1362), and now that trick is void.
Well, you're calling it a trick yourself. Which is exactly what it is. Every feature must be intuitive and easy to discover and explain. This one was not. It was very non-obvious, with high surprise factor, and very difficult to explain in documentation. We take usability seriously. Even if we're to reenable this feature, its UI must be reworked completely so it's always painfully obvious what I'm going to change.
By the way, this "feature" made more sense when we had a separate Gradient Editor dialog. But that dialog is also going to be removed. And when you edit a gradient on canvas, having other objects change is even less intuitive.
And if you need to replace one color by another in the entire drawing, just use the Replace color extension - much easier, no need for unnatural tricks :)
I'm really sorry I missed the discussion of this decision. I would have been quite vocal :) I'm constantly tweaking colours in my drawing and I relied on the ability to be able to update them all very easily. Colouring in Inkscape will be very clumsy and tedious now.
Try the color paint mode in the Tweak tool - it might be what you need, and a lot more intuitive.
bulia byak wrote:
Well, you're calling it a trick yourself. Which is exactly what it is. ... And if you need to replace one color by another in the entire drawing, just use the Replace color extension - much easier, no need for unnatural tricks :)
For arguements sake, I would suggest a script that does a find and replace is more of trick than an SVG supported method that doesn't require any scripting or programming. I called it a trick purely because Inkscape can't create a gradient with a single node. But it's a valid and viable SVG method. And since it's named you can be confident that objects using the same colour with a different name will not be effected.
Having said all that, this is perhaps a discussion for a different topic. And I appreciate what ever effort you can make to bring back named gradients for those who want to use it.
On 10/3/07, microUgly <drworm@...1743...> wrote:
bulia byak wrote:
Well, you're calling it a trick yourself. Which is exactly what it is. ... And if you need to replace one color by another in the entire drawing, just use the Replace color extension - much easier, no need for unnatural tricks :)
For arguements sake, I would suggest a script that does a find and replace is more of trick than an SVG supported method that doesn't require any scripting or programming.
Well, then in your interpretation the entire Inkscape is a "trick", as it uses programming to create and change SVG :)
As for SVG validity, there are lot of valid SVG files that are horrendously designed and really very weird - but valid. To me, not only the one-stop-gradient method is an extremely unnatural trick, but the very idea of gradients being able to chain and inherit from each other is an unnecessary complication in the SVG standard. I don't know what problem they were trying to solve by this; perhaps it was just a way to make SVG more compact. In most cases though, the size savings are quite small, yet the amount of code we had to write to implement this behavior (and make it behave sensibly during interactive editing) is huge.
On Oct 3, 2007, at 3:13 PM, bulia byak wrote:
On 10/3/07, microUgly <drworm@...1743...> wrote:
It was just revealed to me a method of creating a gradient with one stop for the purpose of being able to change flat colour of multiple objects easily (http://www.inkscapeforum.com/viewtopic.php?f=6&t=248#p1362), and now that trick is void.
Well, you're calling it a trick yourself. Which is exactly what it is. Every feature must be intuitive and easy to discover and explain. This one was not. It was very non-obvious, with high surprise factor, and very difficult to explain in documentation. We take usability seriously. Even if we're to reenable this feature, its UI must be reworked completely so it's always painfully obvious what I'm going to change.
Actually it's not so much of a "trick" as it is a design intent of SVG 1.1, just one that was poorly communicated.
Although the main thing is that I agree wholeheartedly that the UI must be reworked completely. I do have it on my list of things to do once this CMS stuff settles down. I'll probably start testing a few things, and Bulia will give feedback on things until I get it acceptable.
So there is long-term intention to leverage that SVG feature, but it won't become user visible until a new UI is working. So to an end user it might appear that one feature goes away and then a new feature shows up after.
On 10/3/07, Jon A. Cruz <jon@...18...> wrote:
So there is long-term intention to leverage that SVG feature, but it won't become user visible until a new UI is working. So to an end user it might appear that one feature goes away and then a new feature shows up after.
Can you name a user-visible feature that can only be enabled by gradient sharing and not by CSS style sharing? In other words, why spend time on gradients when we can work on something more general and powerful instead?
On Oct 3, 2007, at 6:05 PM, bulia byak wrote:
On 10/3/07, Jon A. Cruz <jon@...18...> wrote:
So there is long-term intention to leverage that SVG feature, but it won't become user visible until a new UI is working. So to an end user it might appear that one feature goes away and then a new feature shows up after.
Can you name a user-visible feature that can only be enabled by gradient sharing and not by CSS style sharing? In other words, why spend time on gradients when we can work on something more general and powerful instead?
The quick answer is "Why, we will need both, of course".
Full answer will take a little more.
On Oct 3, 2007, at 6:12 PM, Jon A. Cruz wrote:
Can you name a user-visible feature that can only be enabled by gradient sharing and not by CSS style sharing? In other words, why spend time on gradients when we can work on something more general and powerful instead?
The quick answer is "Why, we will need both, of course".
Full answer will take a little more.
AHA!!! Remembered the first one
SVG Tiny SVG Basic SVG Mobile
I'll try to get a few more things covered in more detail.
Jon A. Cruz wrote:
On Oct 3, 2007, at 6:05 PM, bulia byak wrote:
On 10/3/07, Jon A. Cruz <jon@...18... mailto:jon@...18...> wrote:
So there is long-term intention to leverage that SVG feature, but it won't
become user visible until a new UI is working. So to an end user it might
appear that one feature goes away and then a new feature shows up after.
Can you name a user-visible feature that can only be enabled by
gradient sharing and not by CSS style sharing? In other words, why
spend time on gradients when we can work on something more general and
powerful instead?
The quick answer is "Why, we will need both, of course".
Full answer will take a little more.
I also reuse gradients in a large number of my projects, so I would be missing a "feature" as well.
However, style sharing sounds like a huge benefit over the current way, and for more than just gradients. Looking forward to it.
In the meantime, though, thank you Bulia, for putting the non-forking gradients option in :)
JF
On Thursday, October 4, 2007, 3:05:51 AM, bulia wrote:
bb> On 10/3/07, Jon A. Cruz <jon@...18...> wrote:
So there is long-term intention to leverage that SVG feature, but it won't become user visible until a new UI is working. So to an end user it might appear that one feature goes away and then a new feature shows up after.
bb> Can you name a user-visible feature that can only be enabled by bb> gradient sharing and not by CSS style sharing? In other words, why bb> spend time on gradients when we can work on something more general and bb> powerful instead?
SVG Tiny 1.1, and SVG Tiny 1.2, don't use CSS selectors and don't support the style attribute, style element, or external style sheets. Instead they use presentational attributes. So an SVG Tiny file can share gradients.
However.
From an authoring perspective, there is nothing wrong with creating named, shared styles, and then (at save/export time) choosing between exporting them as CSS or as presentational attributes, just like one chooses between pure SVG and inkscape-roundtrippable SVG now.
(An option to use presentational attributes would make inkscape usable for mobile web development, and I would strongly encourage adding that feature. Since inkscape doesn't seem to use any tricksy features of the style attribute like repeated property assignments, mixing shorthand and non-shorthand versions of the same property, inline comments, etc it should be straightforward).
On 10/4/07, Chris Lilley <chris@...157...> wrote:
SVG Tiny 1.1, and SVG Tiny 1.2, don't use CSS selectors and don't support the style attribute, style element, or external style sheets. Instead they use presentational attributes. So an SVG Tiny file can share gradients.
However.
From an authoring perspective, there is nothing wrong with creating named, shared styles, and then (at save/export time) choosing between exporting them as CSS or as presentational attributes, just like one chooses between pure SVG and inkscape-roundtrippable SVG now.
Exactly. That's how I envisioned this. There's absolutely no need to cripple our internal representation or utilize redundant SVG tricks when we can just use CSS add an SVG Tiny export filter.
(An option to use presentational attributes would make inkscape usable for mobile web development, and I would strongly encourage adding that feature. Since inkscape doesn't seem to use any tricksy features of the style attribute like repeated property assignments, mixing shorthand and non-shorthand versions of the same property, inline comments, etc it should be straightforward).
I think I even had an XSLT stylesheet for breaking style= attributes to presentation attributes. Now that we support XSLT extensions, I'll look into adding it into Inkscape.
On Thursday, October 4, 2007, 2:53:19 AM, Jon wrote:
JAC> On Oct 3, 2007, at 3:13 PM, bulia byak wrote:
JAC> On 10/3/07, microUgly <drworm@...1743...> wrote: JAC> JAC> It was just revealed to me a method of creating a gradient with one stop for JAC> JAC> the purpose of being able to change flat colour of multiple objects easily JAC> JAC> (http://www.inkscapeforum.com/viewtopic.php?f=6&t=248#p1362), and now that JAC> JAC> trick is void. JAC>
JAC> Well, you're calling it a trick yourself. Which is exactly what it is. JAC> JAC> Every feature must be intuitive and easy to discover and explain. This JAC> JAC> one was not. It was very non-obvious, with high surprise factor, and JAC> JAC> very difficult to explain in documentation. We take usability JAC> JAC> seriously. Even if we're to reenable this feature, its UI must be JAC> JAC> reworked completely so it's always painfully obvious what I'm going to JAC> JAC> change. JAC>
JAC> Actually it's not so much of a "trick" as it is a design intent JAC> of SVG 1.1, just one that was poorly communicated.
Yes.
From a spec-writing perspective, its a logical result that comes from
having to explain how a gradient should render if it has only one stop defined. Much more useful to say that it gives a solid color than say 'you must have a miimum of two stops defined else your gradient has no effect'.
From an authoring perspective, its counter intuitive (and in fact I
more often see people defining a gradient with two stops, and 0 and 100%, with the same color).
This is why SVG 1.2 added the solidColor element - its a sharable paint server that defines a single solid color. http://www.w3.org/TR/SVGMobile12/painting.html#SolidColorElement works just the same as a gradient with a single stop, without the need to specify things (unit space, pad method, etc) that do affect a multicolor gradient but can't affect a single solid color.
(incidentally that also solves the commonly requested feature of 'user named colors').
bulia byak wrote:
By the way, this "feature" made more sense when we had a separate Gradient Editor dialog. But that dialog is also going to be removed. And when you edit a gradient on canvas, having other objects change is even less intuitive.
And if you need to replace one color by another in the entire drawing, just use the Replace color extension - much easier, no need for unnatural tricks :)
Hello,
I would like to express my opposition to the idea of removing the gradient editor completely. In my opinion, it should be kept and enhanced to allow the easier editing and previewing of complex gradients with emphasis on transparency. This is particularly important when working with multiple overlaid gradients which are useful for photorealism. The on-canvas gradient editing is great, but I think as a GUI it fails to address complex situations and it lacks transparency-related functionality. A while ago, I proposed a design for the gradient dialog, hoping that someone would like it enough to implement it (see attachments for a reminder of my proposed design).
If you agree to keep the dialog, I'm volunteering to implement my proposed enhancements. I am going to need some help before I can start doing this though, I'm completely unfamiliar with the inkscape codebase, so I will probably need some hand-holding initially. The benefit is that hopefully the community will have gained another contributor :-)
What do people think?
Stathis
I honestly don't see a point to keeping the parts of the gradient dialog which exist today. Setting stop color, for example, can be handled from the "fill and stroke" dialog when a stop is selected.
The new portion of the dialog you introduce at the top might be useful as a dialog/panel in its own right, however. Would you be interested in implementing just that part?
-mental
MenTaLguY wrote:
I honestly don't see a point to keeping the parts of the gradient dialog which exist today. Setting stop color, for example, can be handled from the "fill and stroke" dialog when a stop is selected.
The new portion of the dialog you introduce at the top might be useful as a dialog/panel in its own right, however. Would you be interested in implementing just that part?
-mental
Yes, when I was proposing the addition to the dialog I wasn't aware of the plan to get rid of it altogether... I like would like to see the widget I proposed, but I don't feel any particular attachment to the rest of the dialog :-)
Stathis Sideris wrote:
I would like to express my opposition to the idea of removing the gradient editor completely. In my opinion, it should be kept and enhanced to allow the easier editing and previewing of complex gradients with emphasis on transparency. This is particularly important when working with multiple overlaid gradients which are useful for photorealism. The on-canvas gradient editing is great, but I think as a GUI it fails to address complex situations and it lacks transparency-related functionality. A while ago, I proposed a design for the gradient dialog, hoping that someone would like it enough to implement it (see attachments for a reminder of my proposed design).
It does have transparency related functionality... when you have a gradient stop selected on-canvas you use the same Opacity spinbutton in the statusbar (the same one that you use for objects/selection). I can agree that in some complex situations an editor could still be beneficial.
If you agree to keep the dialog, I'm volunteering to implement my proposed enhancements. I am going to need some help before I can start doing this though, I'm completely unfamiliar with the inkscape codebase, so I will probably need some hand-holding initially. The benefit is that hopefully the community will have gained another contributor :-)
I think it's hard to turn down a new contributor. I do know that for this to even be considered you would have to not only be willing to do your coding, but also be willing to maintain it. In addition to that, know that people will probably have a number of suggestions or requirements as well.
And Mental just chimed in with some thoughts I had too... with our docking dialogs, the upper portion of the dialog that is the real guts of your idea rocks, but some of the old parts are outdated and will be redundant.
-Josh
Joshua A. Andler wrote:
Stathis Sideris wrote:
The on-canvas gradient editing is great, but I think as a GUI it fails to address complex situations and it lacks transparency-related functionality. A while ago, I proposed a design for the gradient dialog, hoping that someone would like it enough to implement it (see attachments for a reminder of my proposed design).
It does have transparency related functionality... when you have a gradient stop selected on-canvas you use the same Opacity spinbutton in the statusbar (the same one that you use for objects/selection). I can agree that in some complex situations an editor could still be beneficial.
Well, I think I need to explain what I mean a bit more explicitely: I do realise that all functionality is already accessible through the on-canvas editing, but I think that the widget that I'm proposing has the advantage of showing you the entire gradient in a neutral state (i.e. not in the context of the drawing where the colour can affected by the background or overlaid gradients etc). Also, I think such an approach has the advantage of providing a very clear overview of the makeup of the whole gradient at a glance (with or without the checkerboard background), by presenting the colour and transparency of all stops explicitely and allowing their editing with minimal effort to switch between them.
It's true what the transparency can be changed through the on-canvas editing, but it's a two-step process as it is: the user has to switch between stops to modify each of them, and they would also have to cycle through them to see how the transparency changes in the gradient.
I think it's hard to turn down a new contributor. I do know that for this to even be considered you would have to not only be willing to do your coding, but also be willing to maintain it. In addition to that, know that people will probably have a number of suggestions or requirements as well.
And Mental just chimed in with some thoughts I had too... with our docking dialogs, the upper portion of the dialog that is the real guts of your idea rocks, but some of the old parts are outdated and will be redundant.
Agreed and agreed, I do realise that contributing to an open source project is not a "fire and forget" situation, and I do know that one needs to document and maintain their efforts, and I will do my best :-)
Stathis
On 10/6/07, Stathis Sideris <im@...1741...> wrote:
Well, I think I need to explain what I mean a bit more explicitely: I do realise that all functionality is already accessible through the on-canvas editing, but I think that the widget that I'm proposing has the advantage of showing you the entire gradient in a neutral state (i.e. not in the context of the drawing where the colour can affected by the background or overlaid gradients etc).
That makes sense, but now that purpose is fulfilled by the swatch in the gradient controls bar above the canvas. So my proposal is simple: what if we replace that small static swatch with your larger dynamic widget? I think that will be the best place for it, logically. The only problem is its increased height which will push the entire toolbar.
bulia byak wrote:
On 10/6/07, Stathis Sideris <im@...1741...> wrote:
Well, I think I need to explain what I mean a bit more explicitely: I do realise that all functionality is already accessible through the on-canvas editing, but I think that the widget that I'm proposing has the advantage of showing you the entire gradient in a neutral state (i.e. not in the context of the drawing where the colour can affected by the background or overlaid gradients etc).
That makes sense, but now that purpose is fulfilled by the swatch in the gradient controls bar above the canvas. So my proposal is simple: what if we replace that small static swatch with your larger dynamic widget? I think that will be the best place for it, logically. The only problem is its increased height which will push the entire toolbar.
What if the swatch remained, but clicking the swatch opened a small dialog with the proposed widget? You would still have a dialog, and though it would not be necessary for regular gradient editing, it would be available for more advanced editing.
JF
On Oct 6, 2007, at 9:49 AM, Joshua Facemyer / Impressus Art wrote:
What if the swatch remained, but clicking the swatch opened a small dialog with the proposed widget? You would still have a dialog, and though it would not be necessary for regular gradient editing, it would be available for more advanced editing.
That sounds to me like the minimum we'd need to support. We could probably expand things from there.
It also brings up one thing I was thinking... we might want to try to split gradients into two concepts. First there is the patter and stops themselves. Second there is how it is applied.
So then linear vs. radial, user vs. object coords, and spread method belong to the *application* of a gradient, while the sequence of colors is the gradient itself.
Among other things, breaking the concepts apart will allow for simple sharing of gradients with other apps like GIMP, Krita, etc. It also seems like a more user-friendly way of dealing with them.
On 10/6/07, Jon A. Cruz wrote:
It also brings up one thing I was thinking... we might want to try to split gradients into two concepts. First there is the patter and stops themselves. Second there is how it is applied.
So then linear vs. radial, user vs. object coords, and spread method belong to the *application* of a gradient, while the sequence of colors is the gradient itself.
Among other things, breaking the concepts apart will allow for simple sharing of gradients with other apps like GIMP, Krita, etc. It also seems like a more user-friendly way of dealing with them.
Please have a look at http://rosros-3.blogspot.com/2007/09/example-n0-3.html too.
Alexandre
On 10/6/07, Jon A. Cruz <jon@...18...> wrote:
It also brings up one thing I was thinking... we might want to try to split gradients into two concepts. First there is the patter and stops themselves. Second there is how it is applied.
That's exactly how it is done now. The drop-down contains color vectors. Other things control the linear/radial distinction. Everything is pretty orthogonal.
Joshua Facemyer / Impressus Art wrote:
bulia byak wrote:
That makes sense, but now that purpose is fulfilled by the swatch in the gradient controls bar above the canvas. So my proposal is simple: what if we replace that small static swatch with your larger dynamic widget? I think that will be the best place for it, logically. The only problem is its increased height which will push the entire toolbar.
What if the swatch remained, but clicking the swatch opened a small dialog with the proposed widget? You would still have a dialog, and though it would not be necessary for regular gradient editing, it would be available for more advanced editing.
JF
My thoughts exactly! Ok, I'll start writing a prototype and annoy Jon Cruz with questions as I go.
:-)
Stathis
On 10/4/07, Stathis Sideris <im@...1741...> wrote:
photorealism. The on-canvas gradient editing is great, but I think as a GUI it fails to address complex situations
Can you give an example?
and it lacks transparency-related functionality.
Not at all, the transparency of the selected stop is viewable and settable via the Opacity setting in the statusbar or in fill&stroke dialog.
If you agree to keep the dialog, I'm volunteering to implement my proposed enhancements. I am going to need some help before I can start doing this though, I'm completely unfamiliar with the inkscape codebase, so I will probably need some hand-holding initially. The benefit is that hopefully the community will have gained another contributor :-)
I'm all for new contributors, I just honestly don't understand what is the benefit of this compared to on-canvas editing.
bulia byak wrote:
Can you give an example? Not at all, the transparency of the selected stop is viewable and settable via the Opacity setting in the statusbar or in fill&stroke dialog
Please refer to my reply to Joshua Andler. If you think this is not satisfactory/convincing I can try and show you some SVG files that I think would benefit from my approach.
Thanks,
Stathis
On Oct 4, 2007, at 2:26 PM, Stathis Sideris wrote:
If you agree to keep the dialog, I'm volunteering to implement my proposed enhancements. I am going to need some help before I can start doing this though, I'm completely unfamiliar with the inkscape codebase, so I will probably need some hand-holding initially. The benefit is that hopefully the community will have gained another contributor :-)
What do people think?
I can lend a hand with getting you going. I've also been looking into gradients recently with the CREATE efforts on unifying things.
On 10/4/07, Jon A. Cruz <jon@...18...> wrote:
I can lend a hand with getting you going. I've also been looking into gradients recently with the CREATE efforts on unifying things.
I think what we need for CREATE is a gradient/pattern/symbol gallery, not a gradient properties dialog. I think Joel was working on something like this.
On Oct 5, 2007, at 9:32 AM, bulia byak wrote:
On 10/4/07, Jon A. Cruz <jon@...18...> wrote:
I can lend a hand with getting you going. I've also been looking into gradients recently with the CREATE efforts on unifying things.
I think what we need for CREATE is a gradient/pattern/symbol gallery, not a gradient properties dialog. I think Joel was working on something like this.
What is currently being worked on is a swatch format. Current discussion is that artist would need more than just bare RGB colors, and could extend to palettes and gradients.
As part of supporting that view (that we should follow traditional artist & designer terminology for 'swatch') I went through and researched the other main apps gradients, including a full technical breakdown of GIMP's format and UI.
On 10/5/07, bulia byak wrote:
On 10/4/07, Jon A. Cruz wrote:
I can lend a hand with getting you going. I've also been looking into gradients recently with the CREATE efforts on unifying things.
I think what we need for CREATE is a gradient/pattern/symbol gallery, not a gradient properties dialog. I think Joel was working on something like this.
Discussion of new swatch file format in the CREATE mailing lists started from the idea to setup an Open Clip Art/Open Font Library like server for swatches, gradients etc., so that we could let users interact and share data in a new way.
This actually means that those galleries, if we agree on functionality, will have to support remote ccHost based data storages, tags, metadata and all that jazz. For which we already have underlying infrastructure (well, partly).
I'm not sure, who is Joel, but I hope that he takes it into account :)
And while we are at this, I'm curious, if Inkscape could handle local Open Clip Art collections, once downloadable, just like it handles remote collection via ccHost API. Consider shared clipart used within one design company on a plain network storage (in case Intranet-based ccHost instance is not possible).
Alexandre
On 10/5/07, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
This actually means that those galleries, if we agree on functionality, will have to support remote ccHost based data storages, tags, metadata and all that jazz. For which we already have underlying infrastructure (well, partly).
Excellent, that's what I had in mind actually. In any event, this bears no relation to the Gradient Editor dialog.
I'm not sure, who is Joel, but I hope that he takes it into account :)
Joel Holdsworth, who's now working on native Windows dialogs, I think he mentioned some gallery work he was planning to do as well.
On 10/5/07, bulia byak <buliabyak@...400...> wrote:
On 10/4/07, Jon A. Cruz <jon@...18...> wrote:
I can lend a hand with getting you going. I've also been looking into gradients recently with the CREATE efforts on unifying things.
I think what we need for CREATE is a gradient/pattern/symbol gallery, not a gradient properties dialog. I think Joel was working on something like this.
I'm pretty sure I added some basic support for CREATE paths a while back. Including gradient/pattern/symbol, I'll have to go back and double check it's been a while. Has CREATE released a final spec yet? Nothing to do with making them appear in Swatches/galleries though.
Jon A. Cruz wrote:
On Oct 4, 2007, at 2:26 PM, Stathis Sideris wrote:
If you agree to keep the dialog, I'm volunteering to implement my proposed enhancements. I am going to need some help before I can start doing this though, I'm completely unfamiliar with the inkscape codebase, so I will probably need some hand-holding initially. The benefit is that hopefully the community will have gained another contributor :-)
What do people think?
I can lend a hand with getting you going. I've also been looking into gradients recently with the CREATE efforts on unifying things.
Thanks a lot, I greatly appreciate it :-)
But let's see if I will actually need to do anything after all...
participants (11)
-
Alexandre Prokoudine -
bulia byak -
Chris Lilley -
Jon A. Cruz -
Joshua A. Andler -
Joshua Blocher -
Joshua Facemyer / Impressus Art -
MenTaLguY -
microUgly -
Stathis Sideris -
Ted Gould