UI - Better Gradient Window

[Sean J MacIsaac]

http://www.seanjmacisaac.com/2D/interface/inkscape/gradient_editor_2.png

This is a way to make the gradient window better.

the (X) allows for the deleting of the gradient.
(#) Shows the number of objects connected to that gradient.

[su_v (suv-lp)]

Related feature requests:
Bug #170305 “Gradient editor window does not show the gradients name”
Bug #171466 “UI improvements for Gradient editor”
Bug #321840 “UI inconsistency on gradient editing”
Bug #395354 “No easy way to use palettes in gradient dialog”
Bug #516108 “Tool to re-map and delete a gradient”

Very similar to the mockup proposed in bug #321840.

[Sean J MacIsaac (seanjmacisaac-deactivatedaccount)]

suv: similar, only I think mine is simpler and IMO, more straightforward.

[Sean J MacIsaac (seanjmacisaac-deactivatedaccount)]

Some more changes to the design:

http://www.seanjmacisaac.com/2D/interface/inkscape/gradient_editor_3.png

Related to questions posed my original post on inkscape.org:
http://www.inkscapeforum.com/viewtopic.php?f=28&t=8709&p=31538#p31538

[Pablo Trabajos (pajarico)]

Very nice. Please, consider merging all related bugs into a Blueprint.

[Sean J MacIsaac (seanjmacisaac-deactivatedaccount)]

Pablo, is there something on the wiki to create a Blueprint?

[Pablo Trabajos (pajarico)]

> Pablo, is there something on the wiki to create a Blueprint?
I can't find anything.

Start creating the blueprint [1]. Look at some examples for inspiration [2]. It's common to create a wiki page like this one [3]. I start from a template [4].

I think that by looking at them you will get an idea.

[1] https://blueprints.launchpad.net/inkscape/+addspec
[2] https://blueprints.launchpad.net/inkscape/+spec/tech-drawing
[3] http://wiki.inkscape.org/wiki/index.php/BlueprintGeometricAndTechDrawing
[4] http://wiki.inkscape.org/wiki/index.php/User:Pajarico/BlueprintTemplate

[Sean J MacIsaac (seanjmacisaac-deactivatedaccount)]

Started a Blueprint on the Wiki
http://wiki.inkscape.org/wiki/index.php/BlueprintUIGradientFill#Discussion

[Pablo Trabajos (pajarico)]

Nice. You should register the blueprint in Launchpad too. This helps developers keep order on the bugs, code and releases related to this blueprint.

https://blueprints.launchpad.net/inkscape/+addspec

You can fill the form with the same information from the wiki page. "Specification URL" is the link to the wiki page. Set "Definition Status" as "Drafting" if you've something to add or "Review" if you feel it's finished. In "Drafter" put your Launchpad nickname.
Leave "Assignee", "Approver" and "Propose for sprint" empty.

[Sean J MacIsaac (seanjmacisaac-deactivatedaccount)]

Registered: https://blueprints.launchpad.net/inkscape/+spec/ui-gradient-window

[Pablo Trabajos (pajarico)]

I've linked this bug with the blueprint, which is the last step. Thanks for your contribution.

[John Smith (john-smithi)]

@Sean, very nice proposal, i've tried to implement some of the ideas here.

There are essentially 2 components to working with Gradients
1. A list/menu/swatch of gradients - that shows all the gradients. How about we call this the "Gradient Manager"
2. A "Gradient editor" to modify a single gradient - currently there are 2 (the Gradient tool and the Gradient Editor dialog)

Attached is a screenshot of an implementation of 1. "Gradient Manager" only, including some other requested features around "managing" gradients
* Merging of gradients (bug #170214)
* Re-map and delete a gradient (bug #516108)

Features include :
* Sort by color, name or usage
* Inline renaming of gradients
* Merge gradients - The idea here is you can selects multiple gradients, then click the merge button to change all references to those gradients to a single (most used?) gradient and deletes the other gradients. This would work well when combined with the sort by color.
* Delete gradients

Any thoughts or ideas to improve on this ?

[Sean J MacIsaac (seanjmacisaac-deactivatedaccount)]

Hi John,

Looking good. A way to select the objects affected by the selected
gradient would be useful. So that you can make massive gradient
re-assignments.

I've attached my suggestions--mostly just adding padding to beautify the
presentation, reduced the size of the gradients. Should be pretty clear
to tell based on looking at it.

Thank you John!

Sean

On 3/6/2012 8:27 PM, John Smith wrote:
> @Sean, very nice proposal, i've tried to implement some of the ideas
> here.
>
> There are essentially 2 components to working with Gradients
> 1. A list/menu/swatch of gradients - that shows all the gradients. How about we call this the "Gradient Manager"
> 2. A "Gradient editor" to modify a single gradient - currently there are 2 (the Gradient tool and the Gradient Editor dialog)
>
> Attached is a screenshot of an implementation of 1. "Gradient Manager" only, including some other requested features around "managing" gradients
> * Merging of gradients (bug #170214)
> * Re-map and delete a gradient (bug #516108)
>
> Features include :
> * Sort by color, name or usage
> * Inline renaming of gradients
> * Merge gradients - The idea here is you can selects multiple gradients, then click the merge button to change all references to those gradients to a single (most used?) gradient and deletes the other gradients. This would work well when combined with the sort by color.
> * Delete gradients
>
> Any thoughts or ideas to improve on this ?
>
> ** Attachment added: "gradientManager.png"
> https://bugs.launchpad.net/inkscape/+bug/722017/+attachment/2827244/+files/gradientManager.png
>

[John Smith (john-smithi)]

> A way to select the objects affected by the selected gradient would be useful
This probably applies to all the Fill and Stroke types (not just gradient) - see bug #170378. Not sure of the best UI for this .. somewhere in the Fill and Stroke dialog or in the main menu Edit->Select->....

> adding padding to beautify the presentation
Yes good idea

[ScislaC (scislac)]

Looking very nice... this would actually justify the gradient types belonging in the Fill & Stroke dialog. :P (I can't say I ever go in there other than to change the Repeat/Spread type)

[Sean J MacIsaac (seanjmacisaac-deactivatedaccount)]

The padding is important for esthetics.

I look forward to trying it. This will make gradient management better than illustrator!

Sean

On Mar 12, 2012, at 4:33 PM, ScislaC <email address hidden> wrote:

> Looking very nice... this would actually justify the gradient types
> belonging in the Fill & Stroke dialog. :P (I can't say I ever go in
> there other than to change the Repeat/Spread type)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/722017
>
> Title:
> UI - Better Gradient Window
>
> Status in Inkscape: A Vector Drawing Tool:
> New
>
> Bug description:
> http://www.seanjmacisaac.com/2D/interface/inkscape/gradient_editor_2.png
>
> This is a way to make the gradient window better.
>
> the (X) allows for the deleting of the gradient.
> (#) Shows the number of objects connected to that gradient.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/inkscape/+bug/722017/+subscriptions

[John Smith (john-smithi)]

Here is a patch to try out the basic features ...

* Sort by color, name or usage # (the color sort is based on the 'HHSSLL' value of the first stop)
* Usage # is the total of both fill and stroke usage - should this be just fill or stroke ?
* Inline renaming of gradients
* Repeat combobox has been removed - it is now available in the Gradient toolbar
* Select all objects with the same gradient is now available from the main menu Edit->Select Same->Fill color / Stroke color (or context menu Select Same Fill and Stroke).

All suggestions for changes welcome ...

[ScislaC (scislac)]

I like it so far. However, if the Edit button is going to open the Gradient Editor dialog, the Gradient Editor dialog needs to be redone. :-/ I see a couple viable options, make the Edit button either A) temporarily show editing specific widgets in the F&S dialog which would go away when done editing, or B) launch a reworked GE dialog (new dialog would require a new widget that we don't have in Inkscape, which is a traditional gradient editing widget you see in other software).

[John Smith (john-smithi)]

I suggest we remove the Edit button (and retire the Gradient Editor) in favor of "on canvas" editing.

Since the Gradient tool toolbar now has the same functionality as the Gradient Editor, the only reason (suggested by ~suv i think) for keeping the Gradient Editor was editing of gradients/swatches not used "on canvas" but still in the document.
To me it doesnt seem like a big enough issue to justify needing to have 2 different Gradient Editing methods.

[ScislaC (scislac)]

I am personally with you about favoring one method (on canvas). There is another issue though with the current implementation, editing the gradient if it's applied to multiple objects. If this is solveable in a sane way you can think of, awesome.

I have an idea about how this could be achieved with on-canvas editing, but it would definitely be "different". In effect, it would create a temporary overlay on top of the existing drawing with a temporary object and temporarily switch to the gradient tool, you do your "edit", when finished the temporary object is destroyed, canvas is back to how you expect, and previous tool is switched back to (meanwhile, all objects with said gradient reflect the new gradient). I can't do a mockup right now, but will see about it tonight or tomorrow if you're interested.

[ScislaC (scislac)]

Okay, did a hack job real quick. This is before initiating "edit".

[ScislaC (scislac)]

And here's what you could be presented with while editing. (no I didn't bother with the returning to normal workflow)

Anyway, I think at the very least, yes, the edit button should be removed currently until a better solution for single-stop gradient editing and gradient applied to multiple object editing is implemented. As it stands, I think the changes to the F&S dialog offer more value currently than the old gradient editor does. Don't remove the old gradient editor code BTW, I have a feeling JonCruz may want to fight for it, just remove that edit button.

[John Smith (john-smithi)]

> multiple object editing
How about a simple checkbox/checkbutton on the gradient toolbar labelled "Master" or "Linked" ?
When checked you are editing all the linked gradients (Gradient Editor behavior). When not checked you are only editing the selected gradient (Gradient toolbar behavior).
Perhaps this coversation should move over to bug #950677 ?

> F&S dialog changes
Maybe we can leave the Edit button there until the issue is sorted, so that no functionality is removed.

[ScislaC (scislac)]

I think a toggle button for linked in the gradient tool does sound like a sensible way to handle it (we can wrangle up icons for both states if one doesn't exist in icons.svg), and I won't disagree about leaving the edit button tucked away in the dialog.

[John Smith (john-smithi)]

Added a patch over in bug #950677 for toggle buttons to link/unlink multiple objects gradients.
Please take a look if you can.

[v1nce (vincent-pennec)]

#19 I can't second that

canvas editing sucks when you want to edit gradients with overlapping nodes (to get sharp color changes) such as

rgba(255,255,255,128) 0%
rgba(255,255,255,0) 50%
rgba(0,0,0,128) 50%
rgba(0,0,0,0) 100%

[v1nce (vincent-pennec)]

Is there any cooperation planned with gimp dev team to unify gradient editing (and maybe sahre code) ?

[John Smith (john-smithi)]

@Vincent, how do you handle editing overlapping nodes now ?

Do you use the Gradient dialog's slider bar or spinbuttons to precisely set the values ?
The spinbuttons are available on the gradient toolbar now, does this give you the same control ?

I dont know of any code sharing going on right now, do you prefer gimps gradient editing ?

[Mark Crutch (markc-qsiuk)]

I suspect Vincent was referring to editing the colours of the stops when they're co-located.

In order to change the colours of co-located stops, I assume that it would be possible to select one stop then TAB to select the next one, and so on. Tthe addition of "Select Previous Atop" and "Select Next Stop" buttons on the toolbar would be more discoverable, though.

FWIW I'm a frequent user of the Gradient Editor dialogue to set my stop colours and to create/delete new stops, but use on-canvas editing to set the stop positions and the gradient angle. I find that on-canvas editing can become cluttered in a complex document, especially with selection boxes and handles displayed, whereas making adjustments in a separate dialogue allows me to easily adjust the gradient without having to compromise on selections or zoom levels in the main window. I understand the desire to reduce the amount of code redundancy, but I hope that some consideration is being made of the effects of this UI in a complex and cluttered drawing, rather than just in test drawings with a handful of large objects.

[John Smith (john-smithi)]

@Marc, in the latest development version (see http://inkscape.org/download/) the Gradient toolbar should now have all the functions of the Gradient dialog.

You can
* Select individual stops for colour editing (via the toolbar dropdown combobox and Tab key)
* Add and Remove stops (via the toolbar buttons and Insert/Delete keys)
* Precisely set the stop offset
* Change the repeat pattern
* Reverse the gradient, and
* Lock or unlock the gradient so that all related gradients are editing together or not

See attached...

If you think there is some functionality in the Gradient dialog - that is not in the Gradient toolbar - we are happy to add it.

[v1nce (vincent-pennec)]

>@Vincent, how do you handle editing overlapping nodes now ?
>
>Do you use the Gradient dialog's slider bar or spinbuttons to precisely set the values ?
>The spinbuttons are available on the gradient toolbar now, does this give you the same control ?

@John Smith:
In 0.48.2 I use the gradient editor, dropdown the color and set the position using the slider or
directly on canvas I move away a node then set his properties (and of the other node that was "under" it) and move it back.
Quite boring indeed.
I suppose that if spinbuttons are on a gradient toolbar I could use it instead of the gradient editor.

By the way : Is the gradient toolbar supposed to work in 0.48.2 ?
              Selection works ok but radial/linear and stroke/fill buttons have no effect.

> I find that on-canvas editing can become cluttered in a complex document

@Mark Crutch:
I second that :
 zooming in to edit a gradient can be really painfull if some shapes have filters on it
 (= the more you zoom the more filters are slow to render
 (even if those filters are not visible in the area you're zoomin in))

 Sometimes you simply can't add stops because of
 https://bugs.launchpad.net/inkscape/+bug/179830
 (Sorry don't have tried the fix)

> I dont know of any code sharing going on right now, do you prefer gimps gradient editing ?

@John Smith:
Both are awfull ;)
But what matters is that they are inconsistent. You can't use what you learnt in inkscape for gimp.
You'll see lots of tutorials on the net that combines Illustrator and Photoshop.
Those both apps use the same terms/icons/UI.
I feel like there's no such thing between Inkscape and gimp and it's a pity.

[v1nce (vincent-pennec)]

What is this discussion all about ?

A) Is this only about "moving" gradient editor features in a toolbar ?
Or is it
B) Anything cool you can think of to make gradient editing better ?

If B then
Can I suggest new features for the toolbar

 https://bugs.launchpad.net/inkscape/+bug/509891 comment#2
 See my proposal discussed @ http://www.inkscapeforum.com/viewtopic.php?f=28&t=11934
 preview http://img580.imageshack.us/img580/1790/gridgradient.jpg

[v1nce (vincent-pennec)]

About #30

Why do mix text and icon ?
Using only icons with tooltips will allow some gain of space.

Can't we replace the two buttons linear / radial with one button with two states
Remove "Select:" text. It is quite obvious what we are talking about.

I join my proposal for stops editing.
A popup toggles when you click edit
(maybe we can remove the edit text and makes the popup appears when you click the arrow at the right of stop name)
It allows easy editing of colocated stops.
I didn't add a way to rename the stops.
One could add a textbox above the color chooser but...
Does someone really care about naming the stops ?
Naming gradient makes sense (silver, gold, italian flag...) but stops ?
=> Do we need to bloat file size (and UI) with info nobody cares of ?
 => So do we need an input method for naming stops

[su_v (suv-lp)]

> What is this discussion all about ?

@v1nce - the recent enhancements for the gradient tool and its tool bar are tracked in
Bug #950677 "Gradient toolbar enhancements / disable gradient editor"

This report (bug #722017) is more about additional features to _manage_ gradients in the Fill & Stroke dialog - see comment #17 for a summary of the proposed changes.

[John Smith (john-smithi)]

@v1nce, thanks for your comments, please see below:
As ~suv mentioned this discussion should be over in bug #950677 ...

> Selection works ok but radial/linear and stroke/fill buttons have no effect.
The buttons only apply to new gradients - click radial and the next gradient you draw should be radial.
I like the idea of the buttons changing existing gradients as well .. let me take a look.

> Sometimes you simply can't add stops because of https://bugs.launchpad.net/inkscape/+bug/179830
That bug should be fixed now in the development version (see http://inkscape.org/download/)

> Can't we replace the two buttons linear / radial with one button with two states
There will soon be a third gradient mode - Mesh radients. So one button will not be enough for Linear/Radial/Mesh.

> Remove "Select:" text. It is quite obvious what we are talking about.
Agreed, this could be removed

> Colocated stops
The issue with colocated stops is partially solved by having the dropdown list of stops on the toolbar. It should be fairly easy to select any stop and adjust it on canvas or via the offset spinbuttons on the toolbar. Have you tried the latest development version with these toolbar enhancements ?

As an alternative how about if when you click on a colocated stop, both the colocated stops are selected ? Then you could easily change the location or color of both at once.

> Does someone really care about naming the stops ?
Probably not a priority.

[su_v (suv-lp)]

Testing Inkscape 0.48+devel r11359 + 722017.v1.patch
(OS X 10.7.4, FSF GCC 4.6.3, Gtk+/X11 2.24.10, Glib 2.32.2)

Inconsistent 'ID' <--> 'inkscape:label' relation: Forked gradients get a new ID but the newly introduced 'inkscape:label' attribute is not consistently updated -> the list of gradients in the Fill&Stroke dialog, and on the gradients toolbar, can show multiple gradients with the same "name" showing different stops (actually the gradient definitions have different IDs but the same label) .

Steps to reproduce (new default preferences):
1) open new document
2) draw a rectangle (defaults to flat blue fill)
3) open Fill&Stroke, change flat fill to linear gradient
3) copy & paste the rectangle (gradient is forked with new ID)
4) change a gradient stop color of the pasted rectangle

-> the list of gradients now displays two gradients with the same name (label) but different colors.

The inconsistent behavior seems to depend on whether the 'Fill&Stroke' dialog has been opened in the current session or not before editing a newly forked gradient: if 'Fill&Stroke' has not been opened, and the changes are done with the gradient tool alone (using the color palette to assign new stop colors), the label seems to get updated (renamed) at the moment the forked gradient is edited for the first time.

[su_v (suv-lp)]

The new list needs more error checking - I have seen several crashes with
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000059
> 0x0000000100385199 in SPGradientSelector::onTreeChange ()

(no 'steps to reproduce' at the moment - I'll provide more details once I have an up-to-date debug build which includes the patch)

[John Smith (john-smithi)]

@suv, RE comments #36

> the list of gradients in the Fill&Stroke dialog, and the gradients toolbar, can show multiple gradients with the same "name"

Just to clarify the terms here:
1) The Gradient has an "id" (example linearGradient1547) - this is assigned by Inkscape
2) The Gradient can optionally have a label "inkscape:label" (example blue) - this is optionally set by the user
3) The Gradient "Name" as appaers in the Fill&Stroke dialog and Gradient toolbar is either:
      a) The label (2) if is exists
      b) Or, a simplified version of the id (1) (example linearGradient1547 will show as "#1547)

Case 1:
When you draw a new rectangle with a new gradient, it should have no label, only an id - hence the "name" should be like the id.
When you copy/paste that , the gradient should be forked, a new id assigned and the new id should appear in the "name".

Case 2:
If the user sets the name of a gradient in the Fill Stroke dialog, they are really setting the label (for example blue)
Then if you copy/paste that, the gradient should be forked with a new id, but with the *same* label, and the name in the dialog with be the same as the other gradient.

> the gradient definitions have different IDs but the same label

1. Is this not the correct behavior ?
2. Is this not the same behavior you see in the trunk (ie without this patch) ?

[su_v (suv-lp)]

@John - Please take a look at the list of gradient names in the Fill&Stroke dialog of the attached screenshot: none of them has been manually edited - it is simply the result of the steps to reproduce described in comment #36.

[su_v (suv-lp)]

Now repeat the same using the gradient tool, and only open the Fill & Stroke dialog after having edited the gradient of the copy&pasted rectangle: the gradient names listed in the Fill&Stroke dialog now show unique names (this is the expected behavior IMHO: by default create unique names (labels)).

[John Smith (john-smithi)]

OK understood, I see the issue now.
There is a bug in the v1 patch where the id is mistakenly being set as the label.

This should be fixed in the attached v2 patch.

But just to clarify how you think it should work :

*If the user creates a gradient, then copy/pastes, the id and hence the name will be different.
*If the user creates a gradient, then sets a label/name for the gradient (by editing the name in the Fill/Stroke dialog) , then copy/pastes, the label and hence the name should stay the same ? Or do you think the label and the name should be automatically changed as well ?

[su_v (suv-lp)]

Inkscape 0.48+devel r11364 + 722017.v2.patch crashes in step 4 (change a gradient stop color of the pasted rectangle):

0) rm -r ~/.config/inkscape
1) open new document
2) draw a rectangle (defaults to flat blue fill)
3) open Fill&Stroke, change flat fill to linear gradient
3) copy & paste the rectangle (gradient is forked with new ID)
4) change a gradient stop color of the pasted rectangle

Crash:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000000000002a5
0x0000000103cb2443 in gtk_tree_view_get_selection ()

[su_v (suv-lp)]

Inkscape 0.48+devel r11364 + 722017.v2.patch also crashes with these steps:

0) rm -r ~/.config/inkscape
1) open new document
2) draw a rectangle (defaults to flat blue fill)
3) open Fill&Stroke, change flat fill to linear gradient
4) Duplicate the rectangle (Ctrl+D)
5) move the duplicate with the arrow keys

-> crash

[su_v (suv-lp)]

> But just to clarify how you think it should work :
>
> *If the user creates a gradient, then copy/pastes, the id and hence
> the name will be different.
> *If the user creates a gradient, then sets a label/name for the
> gradient (by editing the name in the Fill/Stroke dialog) , then
> copy/pastes, the label and hence the name should stay the same ? Or
> do you think the label and the name should be automatically changed
> as well ?

TBH - I don't know: up to now, gradient names as displayed in the GUI (i.e. IDs) have been unique resource identifiers in Inkscape. While I do understand that 'inkscape:label' attributes do not have this restriction, I'm not yet convinced that we should allow users to label different gradient definitions with the same name.

If the labels are not unique, they may disguise the fact that multiple definitions of the same gradient (colors, offsets) exist, while showing the same name in Inkscape's GUI (yes, I know, the usage # is an indicator). Since (unfortunately IMHO) forking of gradients cannot be turned off when copy&pasting within the same document, a steadily increasing amount of duplicate gradient definitions is a persistant issue for many Inkscape users.

Another issue that might come up with such additional, non-unique labels (as did with layer names, e.g. bug #243383), is that AFAIU those attributes in inkscape's namespace are removed when saving a copy as 'Plain/Optimized SVG', and cannot be used e.g. in scripts or animations.

[Mark Crutch (markc-qsiuk)]

As a user who occasionally makes subsequent changes via a text editor in order to add scripting or animation that will work in a web browser, my preference would be for the following:

* Start with an auto-generated name and matching ID.

* If I specifically set a name for a gradient I would like that to be used as the ID. Using a human-readable name as the ID makes it easier to write and comprehend any subsequent script additions.

* Where the name is not valid as an ID, Inkscape would modify it based on clear rules (e.g. spaces replaced by underscores, or removed entirely and the name CamelCased).

* If the name is such that there is no sensible mapping to a valid ID it fall back to an auto-generated ID

* Names should be unique. If I try to enter the same name a second time it should have a suffix appended (e.g. Shimmering Gold (1), or Shimmering Gold #1). I doubt many users will complain about not being able to use precisely the same name for different gradients within a single document.

* Gradients imported from other documents should also be suffixed, if they would clash with existing names.

I understand that there is more to this than meets the eye, but those are my thoughts based on previously wrestling with Inkscape's auto-generated IDs in hand-coded Javascript (I ended up doing a search and replace to convert them to something more readable).

[v1nce (vincent-pennec)]

> There will soon be a third gradient mode - Mesh radients. So one button will not be enough for Linear/Radial/Mesh.

You're sure mesh gradient will fit there ?
I think meshes editor will need a brand new tool.
(Except if you use it only for angular gradient)

> As an alternative how about if when you click on a colocated stop, both the colocated stops are selected ? Then you could easily change the location or color of both at once.

More confusing than really usefull imho.

[ScislaC (scislac)]

With all of the recent changes in trunk, the mesh gradient feature will get it's own tool. That tool will also support conical gradients (done by mesh) and possibly other types.

When dealing with colocated stops, if the stop selector seems cumbersome to you. I'd say it makes sense to get used to the Tab and Shift+Tab shortcuts to toggle between stops if you want a quick workflow.

[John Smith (john-smithi)]

@suv, unfortunately i cannot reproduce the crashes in #38 and #39 on Ubuntu 12.04 or Windows 7.
Compilable patch attached.

[su_v (suv-lp)]

> Compilable patch attached.

Thanks - crash still reproducible, e.g.

0) rm -r ~/.config/inkscape
1) launch inkscape without arguments (empty new document)
2) draw a rectangle (defaults to flat blue fill)
3) open Fill&Stroke (Ctrl+Shift+F), change flat fill to linear gradient
3) copy & paste the rectangle (Ctrl+C, Ctrl+V) (gradient is forked with new ID)
4) switch to the gradient tool, select a gradient stop of the pasted rectangle
5) assign a different color to the selected gradient stop by clicking on a color swatch in the palette below the canvas

Crash:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000000000000028b
0x0000000103d54443 in gtk_tree_view_get_selection ()

Inkscape 0.48+devel r11454+722017.v3.patch, debug build (-g -O0), llvm-gcc-4.2
glib 2.32.3, gtk+/x11 2.24.10, glibmm 2.32.0, gtkmm 2.24.2

[John Smith (john-smithi)]

This patch should fix the OS X problems (#43, #44, #49).

Logic is now based on Marks suggestions in #45 :
* Changing the gradient name now changes the ID - there are no labels used.
* Gradient names are guaranteed to be unique and should be auto-renamed if the name is invalid, or clashing with an existing ID. The auto-rename logic is to append a random number to the end of an existing id - this logic has been in place (to ensure unique id's) for a long time and i dont know if we should mess with it.

@v1nce - even without the mesh button, 2 buttons for 2 different modes seems consistent with the other toolbars such as the Stars and Circles toolbars. Single toggle buttons seem to only be used for on/off types states.

[ScislaC (scislac)]

This looks good to me behavior-wise, I think we're just waiting on confirmation of crash fix on osx.

[su_v (suv-lp)]

> I think we're just waiting on confirmation of crash fix on osx.

The two earlier mentioned crashes no longer occur (tested with r11507+722017.v4.patch on OS X10.7.4, debug build with llvm-gcc-4.2).

[John Smith (john-smithi)]

Committed as r11515.
The Edit button still opens the legacy Gradient Editor, but can be switched to open the Gradient tool via a preference.

[su_v (suv-lp)]

Follow-up reports:
Bug #1067808 “Focus issues with new gradient (and swatch) manager in Fill&Stroke (trunk)”
Bug #1067819 “Changing gradient name does not dirty the document (trunk)”