Hey Bulia!

[...]

I cannot reproduce this. Please send me the file.

hmm, I didn't save, since I was just playing around... let me try to reproduce... Wow, it's harder than I thought it would be... it's http://home.tu-clausthal.de/~dcb/gradient.svg

[...]

Will you be willing to maintain your and probably others' icon files in the distribution? This might include:

[...]

If you (or anyone else) volunteer, I'll set you up with permisstions etc.

I'm sorry, I can't commit that much (even though it's not all that much work)... My problem is that I actually do the things I said I would do. And I'm really busy with students government and ESTIEM design coordination as well as studying (it's exams period over here in Germany). So I just am working on icons and stuff when I really don't feel like doing anything else... for relaxing basically. K, for now there aren't all that many themes... two maybe :) so it shouldn't be any trouble at all, still, right now I really don't want to commit myself that much.

Sorry again. Hope someone has the time to work on this.

David

Hi Bulia, great job on making the gradient editor happen. Few notes on the interface. David was faster than me expressing pretty much my thoughts.

* Gradient editing in other tools. As David suggested, adding the gradient editing capability to tools like node editing adds unnecessary visual clutter and has gotten in my way a couple of times. Since tool toggling is pretty much instant with shortcuts, having gradient editing in an exclusive tool makes absolute sense to me. Gradient editing in other tools feels very redundant. Adding stuff somewhere because you can, doesn't lead to a nice interface. * Stroke/Fill separation. Coming from Illustrator, one would think I don't give a damn about having gradients on strokes and especially having both fill and stroke using different gradients. Well I have grown to love that possibility and use it a lot. Also there is now no indication which vector is for the stroke gradient and which for fill. Initially I was going to propose only having different color for these. However, a different approach could solve the problem of not being able to use different gradients on fill/stroke with the current UI. The tool would actually work in the two modes and not edit both at the same time. Advantages: * gradient selector per mode - possible to select different * clearer canvas - you can get a lot better picture of what you're editing The disadvantage you may see is not being able to lock both and define the vector for both at the same time, but I would consider having the need for absolute precision in this case a much more rare case than wanting to have a different gradient on both stroke and fill. I still suggest using different color for the handles so it gives better feedback on what you're editing. * Linear/radial toggle. Having this affect only a newly defined gradient feels rather unnatural to me. I would think a toolbar click of the type button would immediately affect the canvas.

Keep up the great work!

cheers

Mahlzeit!

...

The gradient-selection should always show the gradient of the toggled button, either stroke or fill.

No. It shows all gradients in selection, both stroke and fill (if any) and for any selected objects (if more than one). I think it's logical.

True, with this interface you cannot assign different gradients _from the list_ to stroke and fill of the same object. But do you really need that? Gradient on stroke is pretty rare anyway, and combining them is even rarer. And you can always emulate that by separating it into two objects, one for fill and one for stroke. And finally, this limitation will become almost irrelevant when you can assign colors to the selected gradient handle, thus editing the colors of the gradients without selecting a gradient definition from the list.

Now, _I_ think that it's even rarer a use case to assign the _same_ gradient to fill and stroke, while might be a common use case to assign the same gradient for stroke as well as the same gradient for fill to multiple objects. So as I said, I'd still go with showing either stroke of fill gradient in the list, depending on what is toggled. When multiple objects are selected, the gradient list will show multiple, when there are different fill gradients respectively different stroke gradients -- that'd be how I expect it to work... Furthermore, when I click one specific gradient on canvas it should be _selected_ in some way and I can chose a different gradient for it.

The fill/stroke switch is in the "New:" part, so it only affects the newly created gradients. The "Change:" part affects all gradients in selection.

Hmmm, that is something else, that surprised me... why is it a "new" button? If I have a linar gradient assigned, I should be able to toggle it to radial just like in the fill-and-stroke dialogue imho. Maybe this fill dialog might even be expanded to have all the features of the fill and stroke dialogue... I still have to think about it though, cause I'm not 100% sure, how to differentiate between fill and stroke in the toolbar.

...

Furthermore I think that the gradient-tool should exclusively edit gradients and no nodes and that node editing should not edit gradients... but I guess that's planned anyways, ain't it?

No. I see absolutely no harm in other tools being able to edit gradient handles. Just like most tools can edit handles of any shapes. If you don't like it, you can disable gradient editing for any tool (except gradient tool, of course) in the preferences.

The harm is that you sometimes have a huge number of nodes on canvas which is confusing. It's nice to have it in the prefs, but for some reason the gradient tool will always show the nodes for rectangle editing.

Take care!

David