© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
demo site
(Get the code!)
ScislaC wrote:
> ~suv: any comments on if the implementation is good by you in trunk?
1a - Editing custom gradient swatches in 0.48.x:
- ok (depends on the deprecated gradient editor).
1b - Editing custom gradient swatches in current trunk:
- The color selector widget displayed below the list of custom swatches does not update when selecting a custom gradient swatch and - if any value is changed - simply overwrites the first stop of that custom gradient swatch based on edits of whatever color it happens to display. IMHO either the color sliders are disabled (insensitive) when selecting a custom gradient swatch, or get a stop selector and update with the color of the first gradient stop. The current implementation is confusing.
- With default preferences ('Use legacy Gradient Editor' is _not_ enabled), it is still possible to edit a gradient swatch currently not in use via context menu of the 'Auto'-palette: 'Edit…' opens the deprecated gradient editor dialog. I don't know whether this went unnoticed or is intentional. Based on discussions elsewhere, it seems that no one really cares for this feature - probably the entry in the context menu of the 'Auto'-palette should be disabled if usage of the legacy editor is not enabled in the preferences, or removed completely.
2a - Position/size of custom gradient swatches in 0.48.x:
- see bug description (still present in 0.48.x)
2b - Position/size of custom gradient swatches in current trunk (r11535):
- Not yet fixed: Inconsistent placement and rendering of newly assigned custom gradient swatches still occurs (AFAICT behavior varies depending on whether the current (or prior) custom swatch was applied via Fill&Stroke or 'Auto'-palette, needs further investigation).
3 - changing from swatch paint to a regular gradient paint fails (0.48.x as well as trunk), see
<https:/