4:57 a.m.
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?
--
View this message in context:
http://www.nabble.com/Color-Tweak---Option-to-not-create-new-gradient-tf4...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
9:10 a.m.
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
Inkscape. Draw Freely.
http://www.inkscape.org
2:25 p.m.
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.
--
View this message in context:
http://www.nabble.com/Color-Tweak---Option-to-not-create-new-gradient-tf4...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
3:10 p.m.
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
3:25 p.m.
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
Inkscape. Draw Freely.
http://www.inkscape.org
3:42 p.m.
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
4:16 p.m.
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
Inkscape. Draw Freely.
http://www.inkscape.org
4:02 p.m.
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.
--
View this message in context:
http://www.nabble.com/Color-Tweak---Option-to-not-create-new-gradient-tf4...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
4:36 p.m.
New subject: Color Tweak - Option to not create new gradient
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
10:58 a.m.
New subject: Color Tweak - Option to not create new gradient
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
2:36 p.m.
New subject: Color Tweak - Option to not create new gradient
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
9:43 a.m.
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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
3:13 p.m.
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
Inkscape. Draw Freely.
http://www.inkscape.org
4:33 p.m.
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.
--
View this message in context:
http://www.nabble.com/Color-Tweak---Option-to-not-create-new-gradient-tf4...
Sent from the Inkscape - Dev mailing list archive at Nabble.com.
6:02 p.m.
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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
5:53 p.m.
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.
6:05 p.m.
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?
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
6:12 p.m.
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.
6:40 p.m.
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.
8:05 p.m.
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
11:18 p.m.
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).
--
Chris Lilley mailto:chris@...157...
Interaction Domain Leader
Co-Chair, W3C SVG Working Group
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG
8:17 a.m.
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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
11:26 p.m.
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').
--
Chris Lilley mailto:chris@...157...
Interaction Domain Leader
Co-Chair, W3C SVG Working Group
W3C Graphics Activity Lead
Co-Chair, W3C Hypertext CG
2:26 p.m.
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
2:36 p.m.
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
5:18 a.m.
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 :-)
2:41 p.m.
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
5:18 a.m.
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
7:46 a.m.
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
Inkscape. Draw Freely.
http://www.inkscape.org
9:49 a.m.
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
12:25 p.m.
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.
12:32 p.m.
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
12:35 p.m.
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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
12:43 p.m.
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
2:45 p.m.
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
Inkscape. Draw Freely.
http://www.inkscape.org
5:19 a.m.
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
8:48 p.m.
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.
9:32 a.m.
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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
10:06 a.m.
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.
10:34 a.m.
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
10:44 a.m.
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.
--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org
11:36 a.m.
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.
4:55 a.m.
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...
5895
days inactive
5903
days old
inkscape-devel@lists.inkscape.org
42 comments
11 participants
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