As part of the color space invasion, we
converted the IFS Compose colors to
GeglColor. However, we forgot to initialize
them when we create a new AFFElement
in undo_update (). As a result, when we
try to clear them out later in aff_element_free (),
the plug-in crashes.
This patch resolves the issues by initializing
the five GeglColors on creation.
...to gimp_drawable_has_visible_filters ().
With NDE filters, it's now possible to have
filters that are not active but still attached
to a layer. This patch renames the API to
prevent confusion as seen in prior
commits.
Similar to afc0a6d1, we need to use gimp_drawable_get_filters () to
get the total number of filters rather than gimp_drawable_has_filters (),
which just returns if any filters in the stack are active/visible.
Because of this, we weren't updating the XCF version to 22 when we
saved a file that had all of its layer effects set to invisible/inactive.
Always update stored colors. When colors are perceptually identical, we
only bypass color rendering code, but not the color value update (even
small value updates need to be echoed across the code, so that what is
shown is always what is set).
With NDE, we can now edit a filter when another layer is selected. This
broke an assumption in GimpFilterTool that the selected layer is the same
as the layer the current filter is applied to.
This patch fixes the problem by checking if the filter is being editing, and then
using either the filter's drawable or tool->drawables->data accordingly.
The previous comment is wrong, because GIMP never had WMF export. Let's
clarify, however, that WMF support is still tricky because of some
options available at configure time regarding 'fontmap' and so on.
Prior commits porting these scripts to v3 dialect
incorrectly compared SF-TOGGLE args to #t and #f.
They are bound to TRUE and FALSE, 1 and 0,
before choice of dialect can take effect.
This was already the case because gegl_operation_get_format() had no
space (i.e. default, sRGB). it's not the source format.
But let's make it clearer because otherwise on a short skimming, it
looks like we are working on the source space.
Also adding a comment on why working on the source space is not a good
idea right now anyway (it's *very* slow for anything but sRGB).
Local certification with WACK is optional and useful to anticipate if
the MSIX will be refused by Partner Center's online certification.
(Just to note: On Windows SDK, certification is not equal to signing.
It's more a checklist process to see if the package is suitable to run.)
To avoid needing the full script to be run with admin rights (which
would be scary) this feature only works with a bunch of requirements:
1. sudo for Windows (so Windows 11 24H2)...
2. enabled in normal (aka inline) mode...
3. in a Windows account in admin group
The 2nd and, specially, the last one are harsh but this is sudo's design:
https://github.com/microsoft/sudo/issues/108https://github.com/microsoft/sudo/discussions/68
Running Color Balance on an image with profile was very slow.
This is because we have special conversion path for sRGB "R'G'B'" in
babl (since babl@90da256), but all the other color spaces are going
through the generic path which does the double conversion to linear RGB
then to 2.2 gamma. And that's slow.
I'm not 100% sure it's right, especially as I'm seeing some CLAMPing
going on (but I'm not sure if removing it is right either) which means
we will likely not cover the full target space in the end.
I'm letting it go because when we'll add proper version support to GEGL
ops, we will be able to improve the algorithm without breaking XCF files
with this filter.
At least now we don't have over-slow Color Balance.
As side improvements, I'm cleaning up a bit the code, which is mostly
micro-optimizations at this point.
This completes the GimpRGB API removal
project for the color space invasion.
Note that the GIMP_RGB_LUMINANCE macro is
temporarily moved to gimpcolor. It does not
require GimpRGB but was included in gimprgb.h.
We are getting HTTP error 429 probably because it's a highly requested file,
and this is causing pipelines to fail at CI lint. Let's fix this with mirrors.
Commit abf0c1c272 fixed the inconsistency of showing "R" for RGB's Red
channel selected whereas the actually displayed selection UI was "H" for
HSV's Hue channel.
As a consequence of this fix, now we were indeed displayed "R". Yet
people got used to working with the Hue channel (and LC plane) for
at least a dozen years. Let's make "H" the officially displayed channel.
During the GAction port, we removed gtk_alignment_new () from the
Animation Playback plug-in as it was deprecated in GTK 3.14.
However, this caused the drawing area to be put on the left side of
the window.
This patch reimplements the alignment feature using gtk_widget_set_halign ()
and gtk_widget_set_valign (), to keep the animation in the center of the dialogue.
Resolves#12160
Currently, GEGL Graph and filters with Aux nodes can only be
applied destructively. Therefore, we need to add a restriction so
they can't be applied when a layer group is selected.
Certain tools like Levels and Brightness-Contrast allow you
to convert it to another filter live. This happened by creating a new
tool, so if you were editing an existing filter, the connection was lost
and duplicate filters were created.
This patch copies any existing filter to the new tool and updates the
name and icon to the new filter type when saved.
During the GimpProcedureDialog port, newly generated widgets were
connected to bender_global_notify (). However, GimpProcedureConfig was
connected to it rather than a GtkWidget, which caused the function to return
without updating since it did not have access to the BenderDialog object.
This patch connects the function to the individual rotate, smoothing, and
anti-aliasing widgets to resolve the issue.
This file was added in commit 21ffb58903 to replace the list in
4_dist-gimp-inno.ps1. The older list used to be verified for missing
langs in the test-installer-langs.sh unit test, but the test was removed
and never replaced. This is why now when a new language is added and it
is missing in iso_639_custom.xml, it goes unnoticed until failing in
dist-installer-weekly job.
Rather than the previously reverted commit, the proper solution is:
* 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.
This reverts commit bdddc94151.
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. ;-)
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).
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.
