Thanks. I did not convert to a switch statement, as it is one of those instances where {} are needed inside most of the case statements, and it ended up being longer and uglier than the if/else structure. Made changes to reduce the number of SP_GRADIENT() uses and the other "active" code changes listed above. The attached patch also includes the patch for 1298967 since that affects the same sections of code, and the changes for 1298967 are just a couple of lines. I also rolled in changes so that copy/paste of an object with a gradient created by inkscape does not duplicate the gradient as it had previously.
To see the new gradient behavior:
1. create a blue rectangle, black border
2. in fill/stroke convert it to a linear gradient
3. select it and paste
there will NOT be another gradient type - both objects will reference the same type.
4. select the new rectangle and start the gradient tool.
5. drag the handles to rotate and scale the gradient.
there will still NOT be another gradient type. This is because the gradients listed under fill/stroke is the one at the end of the chain, and inkscape creates an intervening lineargradient record. The intervening one was modified by the handle changes, but the one at the end wasn't.
Here is where it gets a little odd..
6. Copy/paste the second rectangle.
7. With the third rectangle still selected change it to a radial gradient.
There is STILL no new gradient. What has happened is that inkscape has changed the intervening gradient from linear->radial, but the gradient at the end of the chain, which is listed, is still the same.
Things that DO create new gradient types are changes to the colors at the handles.
Additionally, if the entire lineargradient description is in a single record, which is the case when gradients are read in from EMF files, then when objects filled with those gradients are cut/paste new gradients are created. This is because the gradienttransform in those cases is in the single lineargradient, not in the intervening one, and if the transform changes a new gradient type is required.
If an end user wants to create a duplicate of an existing gradient type they can do so by starting with a solid rectangle (for instance), and then converting it to a linear gradient. That will place a new gradient on the list, even when it is identical to an existing one. However, if a file containing the duplicate is imported or cut/paste to another window then that duplicate will be eliminated in the target window.
I am going to commit these changes after I'm done posting here.
Thanks. I did not convert to a switch statement, as it is one of those instances where {} are needed inside most of the case statements, and it ended up being longer and uglier than the if/else structure. Made changes to reduce the number of SP_GRADIENT() uses and the other "active" code changes listed above. The attached patch also includes the patch for 1298967 since that affects the same sections of code, and the changes for 1298967 are just a couple of lines. I also rolled in changes so that copy/paste of an object with a gradient created by inkscape does not duplicate the gradient as it had previously.
To see the new gradient behavior:
1. create a blue rectangle, black border
2. in fill/stroke convert it to a linear gradient
3. select it and paste
there will NOT be another gradient type - both objects will reference the same type.
4. select the new rectangle and start the gradient tool.
5. drag the handles to rotate and scale the gradient.
there will still NOT be another gradient type. This is because the gradients listed under fill/stroke is the one at the end of the chain, and inkscape creates an intervening lineargradient record. The intervening one was modified by the handle changes, but the one at the end wasn't.
Here is where it gets a little odd..
6. Copy/paste the second rectangle.
7. With the third rectangle still selected change it to a radial gradient.
There is STILL no new gradient. What has happened is that inkscape has changed the intervening gradient from linear->radial, but the gradient at the end of the chain, which is listed, is still the same.
Things that DO create new gradient types are changes to the colors at the handles.
Additionally, if the entire lineargradient description is in a single record, which is the case when gradients are read in from EMF files, then when objects filled with those gradients are cut/paste new gradients are created. This is because the gradienttransform in those cases is in the single lineargradient, not in the intervening one, and if the transform changes a new gradient type is required.
If an end user wants to create a duplicate of an existing gradient type they can do so by starting with a solid rectangle (for instance), and then converting it to a linear gradient. That will place a new gradient on the list, even when it is identical to an existing one. However, if a file containing the duplicate is imported or cut/paste to another window then that duplicate will be eliminated in the target window.
I am going to commit these changes after I'm done posting here.