gimp_color_selector_set_color() must not test for perceptual identity because GimpColorSelector is too much of a generic class. In some case, such a test may be worth it to limit costly updates (in particular when it implies some rendering of color surfaces), but this would happen in specific subclasses.
In GimpColorSelection, the GimpColorScales show numbers, so any change in them will likely trigger other scales to change as a side effect. Therefore when handling the "color-changed" signal on these scales, however small the change may be, we want to run the update. Now removing this test in gimp_color_selector_set_color() also revealed a serious bug which I fix in this commit, which is that the binding between the "value" of a GimpLabelSpin with the "value" of its adjustment was still triggering repeated property-setting, which was enough to freeze the GUI for a while. The logic of using only the GtkAdjustment's value as a source while also binding both properties was not robust enough. Instead the GimpLabelSpin will now store its own value and the binding will simply keep it in sync with the one in the adjustment. Note that this is also part of the solution for #10998, because it means there were cases where the color displayed in scales of the color selection dialog was not actually the color set as foreground or background.
Revert "libgimpwidgets: fix #11339 chroma slider fail on small increments" · 079a68a9 Jehan authored Oct 09, 2024 This reverts commit bdddc941. This commit was not fixing the issue the proper way and was creating new issues. The real problem was that for very small increments at a time, a color change could be perceptually identical to the previous color and therefore not trigger color updates down to subclasses. The reverted commit was trying to work around this by not updating the GimpColorSelector color when it was perceptually identical (therefore next check may be a bigger color distance), but this was definitely not right. It was creating inconsistency in the stored color with the actually selected one and that was the root for more issues. See the next commit for a proper fix. Oh and by the way, there was no leak, unlike what the reverted commit message was saying. The old color was freed. ;-)
libgimpwidgets: make sure that the selected channel is in sync with reality. · abf0c1c2 Jehan authored Oct 09, 2024 By default, the GimpColorSelect widget is set to show HSV with Hue selected but we weren't selecting the channel which was defaulting to "Red" of RGB. Therefore there was some inconsistency when first opening the color selection dialog which was showing HSV colors on the left, yet with "Red" selected on the right. This fixes the inconsistency, which also allows parent or container code to set the default they want (which is indeed RGB).
libgimpwidgets: show the model in the GimpColorSelect label. · e8958e41 Jehan authored Oct 08, 2024 Do not only show the space, but also the model. For instance both RGB and HSV can have the same profiles. As for LCH, we must not show any space (it is based on CIELAB). Note that I use the string "Model: %s" which is already used in libgimpcolor, so I am not breaking string freeze. The "%s - %s" string though is not localized, even though ideally it should be (and possibly even be a better joining string in English), but I don't want to break string freeze for this. This issue is part of the fix for #10998, more as a UX issue than a bug per-se. Depending on how you were selecting a color, now you might select it as HSV, LCh or some other model (this was not the case before, even though the GUI was similar. Yet the stored color was always RGB. Now it's actually "whatever you choose"). As a consequence, it is possible that choosing a color in another model may convert to slightly different numbers, especially within decimal places. I don't think it was the main issue, but it certainly doesn't help. Now we may be making clearer what color model is being used in the GimpColorSelect color areas.
Oct 09, 2024
Oct 08, 2024
plug-in: Prevent another segfault in Gradient Flare plug-in · 8474606d Code that updates the main dialogue preview and the editing dialogue preview were conflicting with each other, setting various strings to NULL. This patch turns off the main dialogue preview updating code when the edit dialogue is open, to prevent this overwriting behavior.
Do not force-clip effects with a mask. Otherwise when adding a filter, it initially renders fine (and can cross its input extents), but once applied, it's suddenly clipped. That's not what we want.
Fix the crop_before area when there was a selection. We have in fact to start at 0×0 on input and only use width×height dimensions.
core: Use prior filter size for stack crops · 59b7b6a5 Alx Sa authored Oct 05, 2024 and Jehan committed Oct 08, 2024 Previously filters were cropped to the layer size in the "crop_before" node. This was fine when we had destructive-only filters, but now that we can multiple active layers, this causes new layers to crop the prior ones if they're larger than the layer (e.g. If gegl:drop-shadow goes out of the layer boundaries) This patch sets the crop_before to the current sizes, then searches the filter stack to see if there's a filter that needs a larger width or height (or if it needs a smaller x or y values), then sets the crop to that size. This crop update is also run when a filter is raised or lowered.
Oct 07, 2024
build, gimp-data: do not hardcode the build directory. · cf3aa1b6 Jehan authored Oct 08, 2024 This fixes building with the option -Dwindows-installer=true. We should never hardcode the build directory like what was done in this script. Also bumping gimp-data where some scripts had similar issues which were only visible with -Dwindows-installer=true.
actions,core,file: Copy inactive filters · afc0a6d1 Previously we used gimp_drawable_has_filters () to detect if a layer had any filters set. However, this function only gets active filters, leading to filters with their visibility set to FALSE not being copied. This patch checks the number of children in the filter stack container instead to get an accurate filter count.
Oct 06, 2024
Oct 05, 2024
app/tools: Add shortcuts for Paint Select modes · 94a27697 This patch ports the Add/Subtract mode shortcuts from GimpSelectionTool to GimpPaintSelectionTool, implementing the unfinished gimp_paint_select_tool_modifier_key () function. The UI itself is left unchanged.
Jehan committed Oct 08, 2024