During instantiation, the widget bypassed saving the PROP_DIGITS state
because the spinbutton was not populated, leaving digits at 0. This
forced the widget into an integer state, causing step calculations to
break for small fractional ranges (e.g., 0.001 to 1.0).
Added G_PARAM_CONSTRUCT to the digits property and moved the internal
assignment outside the spinbutton check so the correct initial state
is saved immediately.
Added a check to ensure step and page do not go out of range.
The documentation for gimp_prop_toggle_new ()
had "icon_name" and "label" in the wrong order.
This patch fixes the documentation to be consistent
with the API.
Our historical heuristic looking for the main monitor based on the
position of the center point in a widget just won't work on Wayland,
where reported positions are always (0, 0). This is the security policy
for this protocol.
Instead we must now use gdk_display_get_monitor_at_window() which is
meant to do the approximation of determining the monitor a surface is
in, for us.
This is one step of implementing color management for Wayland (#15827),
except we still need the code to get the ICC profile of a monitor (but
now at least, we know which monitor we are on).
This commit enables GimpBrowser to emit the "stop-search" signal,
originally emitted only by the internal GtkSearchEntry.
It also connects this signal to all widgets embedding a GimpBrowser,
so they can intercept it and close themselves.
This restores the behaviour that existed before the GtkSearchEntry update
Since we don't necessarily re-render the color area when the color
change, let's store the actually rendered color, additionally to the
supposedly rendered color. Otherwise when changing the color by very
small increments, small enough that the color is always perceptually
identical to the previous color, we never re-render the widget, even
when the rendered color is now quite different. Indeed the "identical
color" algorithm, based on CIE2000 distance, is not transitive.
Additionally I do not check for perceptual identity in
GimpColorSelection anymore, because we also check for this in the
GimpColorArea. Better always having the right color set in the area.
This was raised in #11339 (even though the initial issue was about the
hexadecimal field).
This patch swaps out the GtkBox in
gimp_enum_icon_box_new_with_toggle ()
with a GtkButtonBox and sets it to EXPAND
so that the buttons are pressed together.
It also adds some CSS style to complete
the effect.
This is a followup of commit 0ff960c45b which was the right fix, except
that we must make sure that gimp_widget_free_native_handle() is called
**before** chaining up with the widget's parent dispose().
Failing to do so, the first parent's dispose() was destroying the
associated GdkWindow, which made it impossible to call
gdk_wayland_window_unexport_handle() on it. And therefore we were still
getting handle callbacks possibly run after the window was destroyed, if
we were very fast enough to destroy a window immediately when it is
being shown.
I was still experiencing a crash when closing the Export file dialog
very fast with Esc while it was reappearing after canceling a plug-in's
export dialog.
This followup commit reorders the one case where we still had the crash
because of this order issue, and adds some docs comment to tell
developers how to use the freeing function.
It is a tentative fix as I had this crash once but could not reproduce
it, even redoing dozens of times the same thing I had done.
It is mostly based on something which GDK docs of
gdk_wayland_window_export_handle() says:
> To unexport the window, gdk_wayland_window_unexport_handle() must be
> called the same number of times as gdk_wayland_window_export_handle()
> was called. Any 'exported' callback may still be invoked until the
> window is unexported or destroyed.
So when the GdkWindow of the widget still exists, let's make sure we
call gdk_wayland_window_unexport_handle() as many times as necessary (no
less, but also no more!), and also that we disconnect all handlers which
could possibly call more export_handle().
- Added some link annotations to other types or functions.
- Rename argument @handle to @window_handle in
gimp_widget_set_native_handle() docs to be similar to the same
argument of gimp_widget_free_native_handle().
- Fix annotation of the handle to (inout) though I do wonder if this can
really be usable in bindings anyway because of the asynchronous logic.
Maybe these functions should be skipped for bindings?
- Better docs globally, and in particular remove implementation details
in gimp_widget_free_native_handle() docs. The point is that the handle
is to be considered opaque data and you have to run this when you ran
gimp_widget_set_native_handle(). No need to talk about Wayland or
explain that it's a GBytes or meanings of "handle".
- Also clean the free() implementation with far too many comments, and
in particular we don't need to check if the handle is NULL.
g_clear_pointer() steps out by itself if the pointed data is NULL.
Fixes:
> (file-svg:125356): Gtk-CRITICAL **: 22:11:43.459: gtk_entry_buffer_set_text: assertion 'chars != NULL' failed
… when running file-svg-export because the default of the "title" string
argument is NULL.
I did hesitate considering this was a bug in file-svg code on the
premises that a NULL value was not valid (hence replacing it as ""), but
in the end, I went with the more flexible solution, which is that NULL
is considered equivalent to "". So GimpLabelEntry code will just
transform the NULL pointer internally to an empty string.
Instead of using a makeshift search entry use the one provided by GTK.
As a side-product it allows the procedure browser to shrink its left
panel a little more.
The 'Plugin Browser' and 'Procedure Browser' use the same logic for
enforcing the minimum size of the details page and the list views. And
both are doing it by first setting the minimum: size of GtkTreeView and
then they climb up the widget tree to do the same. This is not ideal.
Setting the minimum size of GtkTreeView is not necessary because it is
inside of GtkScrolledWindow which makes this request moot. It also does
not enforce the minimum height of the widget for that reason. And if
GimpBrowser ever changes, both browsers will need to update their logic.
Moving the size enforcing a level up is logical and more robust.
New libgimpwidgets icon macros: GIMP_ICON_LAYER_LINK_LAYER and
GIMP_ICON_LAYER_VECTOR_LAYER. Note that the actual icons still need to
be done so I use temporary actual icon designs for now.
Also adding some TODOs for these.
Fix run warning:
> WARNING: icon theme has no icon 'gimp-vector-layer'.
In the page selector the translation for "All n pages selected"
was always used, even if all pages weren't selected. This was
caused by the same singular msgid being used in multiple places
with different msgid_plural.
These were then all smashed into a single translation. Replace one
of the singular msgid:s to avoid this. This string is never shown
since the n_selected == 1 case is already covered earlier in the
code.
Our build files were relying 'sysroot' to find gexiv2.h but this is
not possible with Apple Clang om which sysroot points to macOS SDK.
So, exotic environments like Homebrew were failing. Let's fix this.
This patch connects the gimp_color_hex_entry_events ()
function to "key-release-event" and adjusts the code
to update valid colors as you type. Pressing Enter
will work as before, converting back to the last valid
color if an invalid one is typed.
This is the recommended fix from Gtk to use our own mime type rather than depend on a mimetype
that has a different expectation of payload.
This means drag and drop of colors uses `application/x-geglcolor` rather than `application/x-color` which expects an RGBA color rather than a structure.
This patch fixes a few (mostly Windows-specific) warnings on build.
* Hides functions like gimp_get_foreign_window () and variables
like transient_set that aren't used in Windows.
* Changes hollow_g_shell_quote () to not return a const gchar *,
since the value it returns is actually not const.
* Cast update_interval to double to remove warning about mixing
enums and doubles in division.
This fixes the following warning when compiling with CLang:
> libgimpwidgets/gimppropwidgets.c:3961:11: warning: variable 'unit_type' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
> 3961 | if (pspec_unit && GIMP_IS_PARAM_SPEC_UNIT (pspec_unit))
If a unit property name is set, it must be a valid unit property. Let's
check, output a CRITICAL and return NULL otherwise.
This patch uses the is_u8 variable in GimpColorScales's
create_group () function to conditionally set decimals to
0 when creating u8 RGB color selectors.
This change will help further distinguish between the 0...00
and 0..255 views in the Color Selectors. It will also better
convey to users that u8 is an integer value rather than a
floating point.
The "grabbing" cursor currently used is quite large on
newer versions of GTK3, and makes it difficult for users
to see where they're grabbing. This patch switches to
using "pointer" cursor for hovering over the slider area,
and "col-resize" when actually moving the slider.
It also reverts padding changes in CSS so that the progress
bar aligns with the place the user clicks. Padding is added
in Cairo for the label, though the number entry is now
flush against the input buttons.
This commit allows the "reference value" spinbuttons in GimpSizeEntry
to accept and evaluate mathematical expressions, just like the main
value fields. The GimpEevl parser is now attached to both value and
reference value spinbuttons.
...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.
