When converting an image TRC (or a precision+TRC change), we used to
convert the profile to a linear (resp. sRGB TRC) variant or use the
builtin profile, which we'd set on the image.
Pippin is telling me that "it used to be that linear and non-linear
precision gave different results, rather than only about how things were
stored". Yet this is not needed anymore. Nowadays "RGBA foo" + any
profile is linear anyway, disregarding the profile's TRC.
Furthermore, this way, we don't lose the original TRC in a non-linear ->
linear -> non-linear roundtrip and we simplify the code, which fixes
such problems as shown in #3495 as a side effect.
We check the width of the zoom label (if it exists) and use it to size the
combobox's entry field. Otherwise, we default to the existing formula.
Also removes Windows special-casing for PERCENT_SPACING constant,
as Pango now uses harfbuzz on Windows as well.
This patch temporarily reverts 02546da7,
due to performance issues with our use
of Babl. After 3.0, we'll try to improve
these operations so they can be more
color correct.
However, GimpRGB, GimpHSV, and GimpHSL are
replaced with double arrays.
There are certain operations where we're
not yet getting sufficient performance with
Babl. For these legacy operations, we'll
use the original GimpHSV/HSL conversions
internally. This will allow us to replace
them in the future without plug-in
developers relying on them.
The name for internal data may be localized. This is the case at least
for some dynamic gradients (Foreground to Background and others).
Nevertheless they have unique collection name. So let's simply rely on
this for internal data.
See point 2 in: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1830#note_2218014
I also change the standard alias fonts to also have unique collection
names. These seem to be the only other internal data which had no unique
collection until now, which is now fixed.
gimp_brushes_popup() was triggering a popup allowing to change not only
the brush, but also the "paint mode", the opacity and the spacing. As
far as I could see, this was used nowhere for the paint mode and
opacity.
As for the spacing, it looks like gfig was indeed getting this data,
except that the GimpBrushSelect was disabling the effect on this scale
by setting change_brush_spacing to FALSE when calling
gimp_brush_factory_view_new(), and even setting this to TRUE, it was not
working fine anyway. Rather than debugging this, let's simplify the API.
Such settings seems like additional paint settings which don't have to
be in the brush selection. If someone wants people to also select an
opacity, spacing or paint mode, it would be much more efficient to add
separate plug-in arguments for these.
Additionally, I fix GimpBrushFactoryView not to show the spacing scale
when change_brush_spacing was set to FALSE anyway. This is just a bogus
widget then, which can only confuse people.
Also fixes the passing of the resource param definitions through PDB.
There was some weird assumption, with a comment, in commit 73733335c8
that this was unneeded, which meant that we were not able to properly
recreate the right param spec over the wire.
GimpOperationHueSaturation did not do
conversions since the source was already
HSL, so its GimpHSL object was replaced
with a float array.
Van-Gogh plug-in's RGB -> HSL
conversion was replaced with an
HSL float Babl format with gegl_buffer_sample ().
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
Now you can declare a default value when declaring resource arguments to
a PDB procedure.
Add default behavior to GimpParamSpecResource.
Add field and override g_param_spec_value_set_default.
Fix the plugins that have resource arguments.
Some plugins temporarily use a hardcoded default instead of declared default.
ScriptFu plugins, TODO.
Misc fix to the test plugin for this case: test-dialog.py.
Dev>Demo>Test dialog...
TODO 10822 Lava plugin issue depends on this.
Note film.c fixed but still doesn't work.
This is a regression brought with commits 9b5463b5c5 and f7aaba9fc9.
Technically the bug already existed, but it was brought to light after
the reordering of our param bit flags, because GEGL_PARAM_PAD_INPUT
(which is set on all op properties) and GIMP_PARAM_DONT_SERIALIZE are
now the same value. It used to be same as GIMP_CONFIG_PARAM_AGGREGATE,
which, by chance only, didn't have unfortunate consequence on
serialization, yet that was also a bug. The real fix is that we should
not propagate GEGL bit flags in our operation config types.
Resolves#11993
In !1319, we added the ability to merge down filters destructively
in the Filter Tool GUI. This accidentally allowed you to merge down
a filter on a layer group. This patch adds checks to prevent this
option from being used, in the same way we hide the option when
editing an existing layer effect.
The colors are assumed to be sRGB since they come from a
pre-defined array and are used for the item color tags in the
GUI. This replaces the call to gimp_rgb_composite () with the
direct implementation of the GIMP_RGB_COMPOSITE_NORMAL
code.
It also ensures that only one call is made to gegl_color_set_rgba (),
rather than two if the color is inherited.
We weren't updating the precision of layer effect masks when
converting the layer's precision. This patch updated with the
format from gimp_image_get_mask_format ().
Note that in the future, this code should be moved to
gimp_drawable_real_convert_type () once that function is used
in all the child classes of GimpDrawable.
gimp_file_save () is used to save both XCF
and export formats like PNG. XCF does
not have a GimpExportOption parameter,
but we were unconditionally copying it.
This patch adds a check for this.
As noted by bootchk, docs of gtk_application_is_inhibited() says:
> Determines if any of the actions specified in flags are currently inhibited (possibly by another application).
The last part, between parentheses imply that it's possible for another
application to inhibit GIMP. So we should not rely on this function to
verify we inhibited the logout. Just check of we have an inhibition
cookie.
… more robust.
GIMP_PARAM_NO_VALIDATE and GIMP_CONFIG_PARAM_DONT_COMPARE were the same
value, most likely because when GIMP_CONFIG_PARAM_DONT_COMPARE got added
(commit c5c807d191), the comment to keep in sync
libgimpbase/gimpparamspecs.h and libgimpconfig/gimpconfig-params.h was
missed.
Instead, since libgimpconfig can include libgimpbase, do the other way
around: first non-GLib param flags are in libgimpbase, then we add a
GIMP_PARAM_FLAG_SHIFT, then we increment from it in libgimpconfig, and
finally we increment from GIMP_CONFIG_PARAM_FLAG_SHIFT if ever we add
more flags in app/ (right now GIMP_SYMMETRY_PARAM_GUI is apparently the
only one, but this may change).
Previously, we called gimp_display_shell_appearance_update ()
which updates the "Show" settings in the View menu *before*
we had updated the Display object in GimpContext.
This meant that the wrong settings were being applied when
switching images.
This patch moves the call after we run gimp_context_set_display ()
to make sure we've got the right active Display.
The other way around, we were going to have the quick'n dirty exit for
the whole 3.0 stable branch, which is obviously not what we want. We
want the clean exit for all developer builds, even within a stable
branch.
The color for the nib handle is pulled from
the widget's background-color style.
However, this was not defined - so it was
always (0, 0, 0).
This patch adds a GimpBlobEditor CSS
class and defines the background and
border color for it to resolve the issue.
It was made impossible to paste into a channel, as this was creating a
normal layer instead. We need to use floating selections when the pasted
target is a GimpChannel type.
Note that the UX is very ugly right now for these (except for the layer
mask case as I improved this a lot with commits 04810ec95e and
28457ce337), so I opened issue Teams/GIMP/Design/gimp-ux/89 to design
further evolutions.
This is a follow-up of commit c5db158f58, where the flickering issue was
happening when creating new windows when already in multi-window mode. I
had the same issue again when I had several tabs opened in SWM and
switched to MWM. Then it would undraw displays to move them to their own
window. In the short time when this occurs, we don't want to process
events. So now I changed the "drawn" status when undrawing ("unrealize"
event) a shell.
I also changed the implementation of gimp_displays_accept_focus_events().
What we need is to check the active shell only of each window. In SWM in
particular, it is normal that non-visible tab shells get unrealized.
I had added an assert in commit 98ebe96c1f specifically to catch other
cases where we may have run gimp_ui_manager_update() with inconsistent
user context, and I failed to catch the obvious CRITICAL (the damn Error
Console was catching it!).
Anyway we had this other obvious case when creating new displays in
gui_display_create() which would trigger the ui update with still
inconsistent context.
Now I'm in fact wondering why GimpContext is simply not returning the
active GimpDisplay's image and connecting to the "image" property of set
display so that it's always synchronized. But since we are so close to
GIMP 3, and I don't want to do too important restructuration of code
(why did we do this complicated update in 2 parts? Maybe there was a
good reason…) at this point, I'll just do the simple skip for now and
look more closely at GimpContext implementation after the release.
The previous PDB generation was losing pre-formatting inside
triple-backticked blocks. In particular we were losing indentation
(which was already ugly in C, but even syntactically wrong when
displaying Python code samples). And it was also making us add
double-newlines between every code lines, which was annoying.
This updated code now leaves triple-backticked sections as-is.
Unfortunately I was completely unable to do this by modifying the
existing functions, which were modifying the input arg in-place. So I
made them into functions returning the result. But then there is another
part of code (niceargs()) where changing array contents doesn't work
properly, and worse it seems to corrupt the array somehow (because I
have generation breakage in completely-different pieces of the PDB
generation code). I believe there is some passing-by reference/value
concepts in perl which I don't quite get (they use `&`, `\` and other
symbols and even searching for these, I don't quite understand how to
use them the right way) but I've spent already too much time on this. So
since I've got something working now by having duplicate functions, I'll
let someone else from the future, who knows better perl, re-merge these
functions if they know how.
The 'help' field needs to be single-quoted so that @-values do not look
like perl variables, hence breaking GIR annotations.
Fixing:
> Possible unintended interpolation of @Gimp in string at /home/jehan/dev/src/gimp/pdb/groups/item.pdb line 64.
I double-checked the gi-docgen docs and realized the "Note:" were all on
the same line as previous text. I had forgotten it just removed one
newline. So if I want a new paragraph (double-newline in markdown), I
need 3 newlines in the pdb file.
All the functions working with object's IDs are mostly internal. They
are still made public because they can be useful and are relevant in
specific use cases (i.e. using IDs to reference items in specific
widgets, such as drop-down lists, or when temporarily storing an item as
integer, etc.).
Yet it should be made clear that these usages are the exception rather
than the norm.
I had this one case at GIMP exit where destroying editor->selection
inside gimp_colormap_editor_set_context() was segfaulting, very likely
because the widget was already destroyed so the pointer was dangling.
Therefore set a weak pointer, and clear it in dispose, so that whatever
comes first at destruction time will reset the pointer to NULL.
This fixes a never-ending flickering blocking the GUI, until a manual
focus event (such as moving a window in front) breaks the infinite loop
of handling focus events.
As Cheesequake noted in !1673, there may be cases where one would want
to run gimp_help_connect() while also setting a tooltip. So they also
run gimp_help_set_help_data(), even though the latter is implied by the
former. Worse, it makes the order matter too much because if you call
gimp_help_connect() after gimp_help_set_help_data(), the tooltip would
be removed.
Now the reason is that gimp_help_connect() was clearly made to be run on
windows whereas gimp_help_set_help_data() was for other widgets, which
usually don't need to react to F1. Yet the previous commit does add
F1-connect for the lock buttons, which kind of makes sense. So why not
just add this tooltip argument.
As a side fix, I am removing a bunch of gimp_help_connect() on each
button in the layers effect popover. Just run it once on the top
container.
This patch adds gimp_help_connect () calls before
gImp_set_help_data () to set up F1 keybind to work
properly. It also adds lock_visibility_help_id to channel
view.
Resolves#11718
Copying filters over from one image to a partial copy was broken on
multiple level by doing it on an additional loop, and assuming that the
originally selected layers and the newly created ones had the same
structure:
1. First the actually copied layers may be more numerous. For instance,
we'd also copy parent layers. Typically copying a layer under a layer
group, both the layer and its parent layer group would be in the clip
image.
2. Second, because this structure may change, the assumptions made so
that filters were not copied to the right image.
3. And as a last consequence, sometimes we could have crashes, assuming
the same structure and therefore directly dereferencing a NULL
pointer. I had such a crash when copy-pasting a layer group, while
also selecting its children layers (though this crash also got hidden
by my previous commit, but just by chance).
Instead just copy filters in the same time as layers are copied, so that
we can easily associate the filter from the correct original layer we
copied from.
app/text/gimptextlayout.c gives warnings
on MSYS2 about xres and yres not being
initialized.
plug-ins/file-tiff/file-tiff-load.c gives
warnings about read_unit not being
initialized.
plug-ins/file-bmp/bmp.c has a typo on
the label of the rgbx-8888 option for
rgb-format.
Main dev branch of GIMP always depends on the HEAD of babl and GEGL
anyway, but that's just so that we maybe have less people reporting GIMP
not building because they use a stable release version of GEGL (though
it won't take care of the case of people using an older 0.4.49 build
which also won't have the newer API).
In GTK2 and GIMP 2.10, you can use the mouse scroller to
switch between dockable tabs if you hover over the bar.
This behavior was removed from GtkNotebook in GTK3.
This patch follows other GTK3 applications in re-implementing
the behavior with a scroll-event callback.
I broke MR !1660 commits into 2 commits so that the strings are added
now (freeing this up for the upcoming string freeze), with this commit.
A next commit will be needed when we'll have the proper version update
infrastructure on GEGL side, because right now, all we can do when
filter versions don't match is ignoring the filter.
Jehan