...to GimpProcedureDialog.
This patch allows plugin developers to create a
GimpCoordinates widget (two GimpSizeEntries linked
together with a chain and with a units combo) in the
GimpProcedureDialog.
It is largely a wrapper for gimp_prop_coordinates_new ().
This patch also makes that function more responsive
to the unit property, now that GimpUnit has a proper
GParamSpec implementation. The default unit and
whether we show pixels, percents, or the resolution
spinners can now be determined via the unit
parameter (if set) rather than relying on
hardcoded values.
As a demonstration, the Tile plug-in's width/height
entries were restored to what they were before the
GimpProcedureDialog port, with units and a chain
link between values.
since GTK 3.10 and according to the GTK3 documentation the setting
is ignored.
Remove the reference to it and thus setting a fallback. According to
the GTK docs `hicolor` is the fallback icon theme.
Since `gimp_icons_notify_system_icon_theme` was only used to add
the fallback, remove the function and setting it with
`g_signal_connect`.
Previous code was right and equivalent because
gdk_wayland_window_export_handle() works asynchronously in the same
thread (so phandle can't get overridden by mistake). Nevertheless a
quick code scan felt surprising, so to avoid any such future surprise,
let's just switch the order of statements.
Resolves#13293
This patch fixes a regression from 2.10. The OK button
was not set to be the default response for certain
Selection dialogues like Shrink/Grow/Border, so
users could not just press Enter to apply if they were
fine with the default values. This patch adds a call to
gtk_dialog_set_default_response () to restore this
behavior.
In 2baa518a, to avoid a critical we use
the resolution as the width of GimpScaleEntry
when the unit is set to pixels.
This had the side-effect of making the
width of the GimpSizeEntry very long when
the unit is initially set to pixels.
Since GimpUnit is now an object, the original
critical no longer displays. Therefore, we
partially revert 2baa518a and refer to the
value as entry_width instead for clarity.
The minimum width is set to 7 to match
the minimum width of GimpSpinButton.
This widget will replace our usage of GtkFileChooserButton, except that
it has a title label and also it contains GUI implementation for the
SAVE and CREATE_FOLDER actions (unlike the GTK button). Moreover this
widget was removed in GTK4. So it is a good idea to start encapsulating
such GTK widget anyway.
I'm also adding a propwidget function to create such a widget bound to a
GimpParamSpecFile property.
New functions:
- gimp_file_chooser_get_action
- gimp_file_chooser_get_file
- gimp_file_chooser_get_label
- gimp_file_chooser_get_label_widget
- gimp_file_chooser_get_title
- gimp_file_chooser_get_type
- gimp_file_chooser_new
- gimp_file_chooser_set_action
- gimp_file_chooser_set_file
- gimp_file_chooser_set_label
- gimp_file_chooser_set_title
- gimp_prop_file_chooser_new
This patch does the following to reduce the
height of the Load PDF GUI:
* Hides the title label if the PDF does not
have a title.
* Reduce the padding around elements
* Reduces the requested height of the
GimpPageSelector widget.
* Alter the GimpPageSelector widget so
that the layer/image combobox and the
range entry are on the same line.
New libgimpbase functions:
- gimp_param_spec_choice_get_choice
- gimp_param_spec_choice_get_default
Now the only GParamSpec in libgimpbase whose struct is visible is
GimpParamSpecObject. This can't change since it is derived into param
specs defined in libgimp and therefore needs to be visible.
This same widget is used for GFile args and GimpParamSpecConfigPath
specs. The latter are string-based. So we need different code to handle
both types of arguments.
This was crashing when a change was coming from the config object,
rather than from the GUI, such as when doing a reset to factory values.
Similar to 42300d9d, we want to prevent overly long color profile
labels from stretching out dialogues with GimpColorSelect too far.
This patch adds gtk_label_set_ellipsize () to both the color profile
and simulation profile labels, and adds them to a grid instead of
letting them free-flow.
...with gtk_icon_theme_add_resource_path (). Per Wormnest in !1027, this function
might not even be necessary at all. But until removing it can be completely tested,
this patch at least removes the deprecation warning for GIMP 3.0 RC1.
The whole widget was made deprecated in 2006 (commit 99f979e118) but it
is still being used by another widget. Since we can break API, I at
least hide the functions and type by making these private.
This will give us time to think if we really need this widget (or a
nicer implementation for this widget) or if we just want to get rid of
it.
Checking the log, it looks like this code has not been touched since
2007, so whatever this various was used for, it's clearly not been used
for a long time.
Fixes warning:
> libgimpwidgets/gimpcairo-utils.c:80:16: warning: variable 'total_length' set but not used [-Wunused-but-set-variable]
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).
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.
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.
gimp_size_entry_eevl_unit_resolver () loops through all valid units
to find a match for user's inputted value in GimpSizeEntry.
It runs until gimp_unit_get_by_id () returns NULL, where it does a
final check on GIMP_UNIT_PERCENT.
Due to a small logic error, we kept setting the GimpUnit to
gimp_unit_percent () each time it was NULL, so the loop ran forever.
Per Jehan, this patch breaks the logic up so that we terminate the
loop once the percent check fails.
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 resizes the selection mode
icons based on the user's icon size
settings. It creates a new function in
gimpenumwidgets.c to update sizes,
then connects to GimpGuiConfig's icon
size update notifications in GimpSelectionOptions.
