… GimpIntComboBox "value" property.
For this, I connect to the "changed" signal, which is equivalent anyway.
Otherwise the link was not bidirectionnal, so selecting a new item in
the combo list was not actually changing the internal value, hence the
binding set by gimp_prop_int_combo_box_new() was not complete either.
Not sure how I missed that. Hopefully not missing anything else!
… and have gimp_prop_int_combo_box_new() bind to "value" instead of
"active".
The "active" property is defined by GtkComboBox and is the index of the
combo box, not its values, whereas with gimp_prop_int_combo_box_new(),
we want to bind an int property to the combobox value. Therefore the
commit 0828a371c2 was only properly working when we were creating a
combo box with values starting at 0 and incremented by 1.
By adding a "value" property to GimpIntComboBox, I allow binding any
property to the int value rather than the index.
See also !265 where the issue was raised as it affected our HEIF
plug-in.
Looking further at this widget, many things are not right. Here are the
changes:
- Use binary prefixes (i.e. kibibyte, mebibyte and gibibyte) instead of
decimal ones. We are making binary shifts so we were actually showing
the wrong units.
- Round the value to the closest integer when showing it, not towards 0.
Otherwise I had cases where it was showing 7GiB for an actual value of
7.69GiB (default as computed by GIMP from my actual physical memory).
Note that I am actually unsure even rounding makes sense. Shouldn't we
rather show double values with a few digits after the decimal points?
For such values, I think it would make sense.
- Do not edit the internally saved accurate value when the entry is
edited to the same less accurate value as our saved value would be
shown too. In particular when changing the display unit to a bigger
one, we don't want to lose accuracy. This is especially true for low
values. Say you don't have a lot of memory and you set the Tile cache
size to 1.5GiB (1536MiB), you certainly don't want it to become either
1 or 2GiB when switching display unit to GiB. Now even if the number
will still display with less accuracy, the internal value will stay
accurate.
This bug doesn't happen when setting value through the GUI as in such
case, the unit never changed. It happened when setting a value which
could not be properly displayed by current unit (typically smaller than
1 in this unit, or with remainder).
In such a case, we should not manually set private->shift before
gimp_int_combo_box_set_active(), or the callback was failing to
reconfigure the GtkAdjustement, in particular min and max values.
As a consequence, hitting a Preferences reset, with a GimpMemSizeEntry
in Gigabytes, it got reset to Kilobytes with the max values capped at
4096. So I realized a Reset ended me with a Tile cache size of 4096 KB
in particular, which is of course ridiculously small and would be a
problem if one doesn't notice the issue immediately.
In GimpSpinButton, don't propagate Enter key-press events if
updating the spin-button's value in response changes the entered
text. This prevents confirming dialogs when hitting Enter after
entering a math expression in size entries, updating their value
instead.
Likewise, don't propagate Escape key-press events if a new value
was entered, and restore the original value instead.
`gimp_unit_store_get_value()` clashes with the `get_value()` method of
its parent class GtkTreeStore. This means trouble for bindings, as seen
here in some pseudocode:
```vala
var unit_store = new Gimp.UnitStore();
// Which function are we referencing here, the one from GtkTreeStore or
// the one from GimpUnitStore? Worse, they both have different arguments
unit_store.get_value( ... )
```
GtkHBox is a deprecated version of GtkBox, which we don't even use
anymore. It confuses the gtk-doc a build though, so let's fix it to get
rid of another warning.
The GIR parser is giving warnings because both e.g. a signal, a
corresponding vfunc and a method emitting it are named
"channel_changed", which can and will give issues in some bindings.
The easiest option is to follow the general convention of starting the
signal emitters with `emit_`, which also makes clear the intention of
the method.
* Don't generate our own marshallers if they are available in GLib
already
* Don't set the c_marshaller parameter in `g_signal_new()` if it's a
default marshaller provided by GLib. See commit message of commit
39e4aa3c57 on why this is the case.
gimp_int_radio_group_new() was still complaining about the scope of
radio_button_callback(). Make it (scope notified) because it needs to
stay alive after the function returns and may be called multiple times.
Also adding a GDestroyNotify to free the callback data once the widget
is destroyed (additionally it will also serve as a notifier for bindings
to properly free the callback closure itself, not only it's data).
With this last one done, GObject Introspection generation now happens
without any warning output.
In GimpSpinButton, adjust the scroll step in response to modifiers:
normal scrolling uses the step increment, Ctrl uses the page
increment, and Shift scales the step increment down by the ratio
between the page and step increments (up to the minimal precision
of the spin button).
This applies to all spin buttons used in GIMP, including spin
scales.
Add a new 3D Transform tool, based on GimpToolTransform3DGrid,
added in the previous commit. The tool UI provides a notbook with
three tabs, corresponding to the three GimpToolTransform3DGrid
modes:
Camera - allows setting the primary vanishing point, as well as
the camera's focal length, expressed either directly, or as the
camera's angle of view, relative to the whole image or the
transformed item. By default, the vanishing point is aligned
with the item's center, and the angle of view is fixed relative
to the item; this essentially means that each item is transformed
using a local perspective, independent of its position and size
relative to the image. A global perspective can be achieved by
using a common vanishing point and focal length (or an image-
relative angle of view).
Move - allows moving the item using X, Y, and Z offsets.
Rotate - allows rotating the item using X, Y, and Z Euler angles.
The order of rotation of the different axes can be controlled by
a set of numbered buttons next to the sliders, and the rotation's
pivot can be controlled using a pivot selector.
GimpPivotSelector is a 3x3 grid of toggle buttons, used for
selecting a natural pivot position (e.g., for a transform) relative
to an item: its center, its corners, and the midpoints of its
edges.
In GimpSizeEntry, the value corresponding to 0%, as per
gimp_size_entry_set_size(), may be non-zero. This works correctly
when using the size entry in percentage mode, but not when using
precentage as part of arithmetic.
Fix this by adding an 'offset' parameter to eevl's unit-resolution
callback, which can be specifies a constant value to add as part
of unit conversion, after scaling the converted value by the
conversion factor. In GimpSizeEntry, use this parameter to offset
percentages by their lower bound.
More of the files were wrong, or at least not absolutely identical to
the files generated by the autotools. I am not doing any code change
other than trying to make both build systems produce identical files
(except for slight differences on 2 files not worth the effort) even
though maybe some things can be improved (especially on the include
list). Maybe to be improved later.
Also fixing 2 of the previously autotools-generated files because of
space typos which should have been committed earlier.
Finally it is to be noted that there is no logics to copy the generated
files back to the source directory in the meson rules. I am not sure
anyway this is really worth it and maybe we should just stop tracking
these generated files eventually.
Noticed by Massimo.
gimp_type_set_translation_domain() calls were missing.
Also make so that the output is exactly similar (even whitespaces) as
the autotools one, making it easier to diff, hence maintain.
In gimp_page_selector_add_frame(), if "gimp-frame" icon cannot be loaded
(which should not happen, but reality can always strike back!), we want
to abort from gimp_page_selector_add_frame() immediately.
Also as a consequence, its return value might be NULL, hence should be
freed with g_clear_object() instead.
This happened here because of broken meson rules (which didn't install
this icon) and ended up in forever looping errors when loading a
multi-page PDF (pages are shown in frames in a dialog):
> (file-pdf-load:12348): GdkPixbuf-CRITICAL **: 11:59:28.513: gdk_pixbuf_copy_area: assertion 'src_pixbuf != NULL' failed
and remove a gazillion gtk_widget_show() all over the place, some
places need a gtk_widget_hide() now, and I'm pretty sure I broke at
least one thing in all those files...
to match gimp_int_combo_box_new(), and add gimp_int_store_new_valist().
Move the va_list of (name, value) parsing code to
gimp_int_store_new_valist() and use it from
gimp_int_combo_box_new_valist().
This makes the entire GimpIntStore/GimpIntComboBox stuff useable much
more generically for the price of an incompatible change of a public
function that is used exactly once outside of libgimpwidgets.
... in their dockable dialog
In GimpChainButton, override GtkWidget::compute_expand() to avoid
inheriting [hv]expand from the button's chain lines, so that these
propeties don't in turn propagate to the widget's ancestors,
screwing with their layout.
Jehan