In GimpContainerTreeView, don't process updates in response to a
selection-change if the selection is empty (for the reason this is
necessary in the first place (though not in this particular case),
see commit f9a71fb6de5a2e65e0d88c6b7aaa39f589d6cdc4.) When
clearing the container-view's context, we deselect all items after
setting the context to NULL, in which case
gimp_view_renderer_draw() warns, breaking one of our tests.
...not found if language changed since last session
For various reasons, (gimp-context-get-brush, pattern, gradient, ...)
can return "Standard" which is the untranslatable name of the internal
fallback object.
Therefore, we must accept "Standard" as fallback in all PDB functions
that take brush, pattern, gradient etc. names.
(cherry picked from commit 397ae027ba)
...and successfully fails
Commit d2ad2928 removed "gradient-repeat" from GimpPaintOptions, not
considering that it is also used in the PDB.
Move "gradient-repeat" from GimpGradientOptions back to
GimpPaintOptions, and add a comment that it is only used by the
gradient tool, not for painting.
(cherry picked from commit c3d37140eb)
- "LCh" intead of "LCH"
- "CIE LCh" instead of "CIELCh"
- "HSV Hue" instead of "Hue (HSV)" for all models/components
(cherry picked from commit 926dc070ef)
In GimpContainerTreeView, work around a GTK bug which can cause the
window containing the tree view to stop processing updates,
resulting in an apprarent freeze, until update-processing is
explicitly requested. This can be triggered by adding layers to a
layer group until the layers-dialog tree view is almost full, but
still doesn't have a scrollbar, and then duplicating the group.
This doesn't seem to affect GTK3, so not applying to master.
Don't destroy the color frames when the number of points changes.
Instead, simply hide them so they keep their color model, but add an
upper limit of an arbitrary number of 16 frames to keep around.
(cherry picked from commit 370680f9bc)