… GimpProcedureDialog.
Technically I added:
- New gimp_prop_color_select_new() property widget to create a
GimpColorButton for a given GimpRGB property.
- gimp_procedure_dialog_get_widget() now supports a GimpRGB property and
will create a GimpColorArea by default.
- When the default doesn't suit you, a new function
gimp_procedure_dialog_get_color_widget() allows to create either a
GimpColorArea or a GimpColorButton (editable = TRUE), as well as
choose the area type (small or large checks, as well as flat area,
i.e. no alpha support).
When creating a label bound to a property, only make the binding
directional if the property is read-write.
This fixes WARNINGs and broken label in the GimpDeviceInfoEditor widget,
such as this one:
> The source object of type GimpDeviceInfo has no writable property called 'vendor-id'
… gimp_label_spin_set_digits() and deleted gimp_prop_opacity_entry_new()
- The "digits" argument for the number of decimal places in
gimp_prop_scale_entry_new() is now mostly useless since GimpLabelSpin
(hence GimpScaleEntry too) got a nice estimation algorithm of sensible
values.
- Add gimp_label_spin_set_digits() function to manually set the digits
property when we don't like the estimated value.
- Also add a new "factor" argument to gimp_prop_scale_entry_new(). Its
role is to allow a GimpScaleEntry showing a factored range, typically
a [0, 100] range for some types of [0, 1] properties.
- Remove gimp_prop_opacity_entry_new() which was basically a
special-case of gimp_prop_scale_entry_new() and which can now be
easily reproduced by simply set factor=100.0.
- Update all usage of gimp_prop_scale_entry_new() in app/ and plug-ins/
with updated arguments. It is interesting to note that all existing
usage were either integers (digits=1) or when double, the estimated
decimal places are the same as the ones which were manually set (hence
showing the generic estimation is not too bad). So the new function
gimp_label_spin_set_digits() was not even needed once in current code.
Similar code was used in 2 places basically (GimpLabelSpin and
GimpProcedureDialog) so just make it an utils function. It's good anyway
to have a generic function to estimate suitable increments and decimal
places depending on a range.
As a consequence also gimp_label_spin_new() now takes a gint digits
(instead of guint), with -1 meaning we want digits computed from the
range.
Similarly gimp_prop_scale_entry_new() docs adds the -1 meaning too.
There is currently no property widget which just creates a
GimpSpinButton with a label. Just as the GimpScaleEntry was needed, this
one is as well.
I am creating a GimpLabeled abstract class which will represent various
widgets with a label. While this may seem a bit over-engineered for such
a basic feature, this will actually bring some consistency and a common
parent. In particular this can be used to get the GtkLabel with a common
interface to add them all in a common GtkSizeGroup when generating
dialogs automatically, hence make dialogs with properly aligned labels
and edition widgets.
… gimp_scale_entry_set_bounds().
I realized that this function may look like the set() opposite for
gimp_scale_entry_get_range(), which it is not at all. The get_range() is
for getting back the GtkRange widget packed in the GimpScaleEntry,
whereas the set_range() is to change the minimum and maximum allowed
values.
I had recently renamed the former, and could just rename it back into
gimp_scale_entry_get_scale() as it was, but since the class we rely on
is actually called GtkRange (GtkScale is a subclass), I think it could
be misleading. So in the end, let's rather rename the function setting
the widget minimum and maximum as gimp_scale_entry_set_bounds() instead.
Hopefully this is even more understandable. Naming is hard!
Renaming the temporary function gimp_scale_entry_new2() into
gimp_scale_entry_new() now that the original code is entirely gone. This
is now a fully-fledged widget with a nice and proper introspectable API.
Instead of setting always manually the step and page increments when
creating a GimpScaleEntry, let's just generate some common cases
automatically. Indeed the increments are rarely something you want to
care about. The algorithm used is:
- For a range under 1.0, use a hundredth and a tenth (typically a [0,
1.0] range will step-increment of 0.01 and page-increment of 0.1).
- For small ranges (under 40), step-increment by 1, page-increment by 2.
- For bigger ranges, step-increment by 1, page-increment by 10.
For use cases when you absolutely want specific increment values, I add
the gimp_scale_entry_set_increments() function. It is much better to
have a small and understandable constructor call followed by
configuration calls (only when needed) rather than a constructor with a
crazy amount of parameters. Hence gimp_scale_entry_new() went from 17
arguments (absolutely unreadable calls) to now 5.
Instead of the gimp_scale_entry_new() which creates several bound yet
independant widgets, and in the same time pack them into an existing
grid and return a GtkAdjustment (while heavily relying on GObject data
to link widgets), let's have a proper custom widget with its own clean
API.
This also simplifies the gimp_prop_scale_entry_new() property widget
variant.
First advantage is that we don't force the usage of a grid to use this
widget (there are a few pieces of code which create a GtkGrid with only
this inside just to be able to use this feature).
Second thing is that I am creating a much simpler API.
gimp_scale_entry_new() had 17 parameters! How crazy is that? So I
removed all the grid packing related parameters. Also I moved the spin
button/scale unconstraining parameters into their separate function,
because the constrained behavior is the most common use case, so it's
stupid to add 3 permanent dummy parameters for most calls. Instead the
few times where we'll want different ranges for the spin button and the
scale, we'll call the separate API gimp_scale_entry_set_range().
Thirdly the tooltip can be set directly with gimp_help_set_help_data()
since this is now its own widget. No need to have dedicated logics
anymore, better stay generic. Similarly no need of a custom function to
switch sensitivitivy (instead of generic gtk_widget_set_sensitive()).
Fourth thing is that we should not use macros for the public API, but
proper functions, because macros are not properly introspected for
binding.
For future improvements, maybe we could even make this widget implement
GtkOrientable interface, in order to be able to use it vertically.
Note: right now, I created a separate gimp_scale_entry_new2() and only
modified the property widget API to use this new code. Eventually I will
remove fully the old gimp_scale_entry_new() function (and the new code
will replace it).
… 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.
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.
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...
Documentation-wise in C, this doesn't matter a lot, but it allows
GObject-Introspection based bindings to use their built-in versions when
they want to render any kind of documentation (for example, docs for
Python plugins can render `%NULL` as `None`).
This was my initial choice, but the more I think about it, the less I am
sure this was the right choice. There was some common code (as I was
making a common composite bucket fill once the line art was generated),
but there is also a lot of different code and the functions were filled
of exception when we were doing a line art fill. Also though there is a
bit of color works (the way we decide whether a pixel is part of a
stroke or not, though currently this is basic grayscale threshold), this
is really not the same as other criterions. In particular this was made
obvious on the Select by Color tool where the line art criterion was
completely meaningless and would have had to be opted-out!
This commit split a bit the code. Instead of finding the line art in the
criterion list, I add a third choice to the "Fill whole selection"/"Fill
similar colors" radio. In turn I create a new GimpBucketFillArea type
with the 3 choices, and remove line art value from GimpSelectCriterion.
I am not fully happy yet of this code, as it creates a bit of duplicate
code, and I would appreciate to move some code away from gimpdrawable-*
and gimppickable-* files. This may happen later. I break the work in
pieces to not get too messy.
Also this removes access to the smart colorization from the API, but
that's probably ok as I prefer to not freeze options too early in the
process since API needs to be stable. Probably we should get a concept
of experimental API.
This commit implements part of the research paper "A Fast and Efficient
Semi-guided Algorithm for Flat Coloring Line-arts" from the GREYC (the
people from G'Mic). It is meant to select regions from drawn sketchs in
a "smart" way, in particular it tries to close non-perfectly closed
regions, which is a common headache for digital painters and colorists.
The implementation is not finished as it needs some watersheding as well
so that the selected area does not leave "holes" near stroke borders.
The research paper proposes a new watersheding algorithm, but I may not
have to implement it, as it is more focused on automatic colorization
with prepared spots (instead of bucket fill-type interaction).
This will be used in particular with the fuzzy select and bucket fill
tools.
Note that this first version is a bit slow once we get to big images,
but I hope to be able to optimize this.
Also no options from the algorithm are made available in the GUI yet.
Normally, the model would try to avoid notifications when a set()
doesn't change anything, but with g_object_set() that's not possible.
Do the same in the propwidgets' callbacks and avoid potentially
expensive notifications at the cost of a cheap g_object_get().
Also fix the syntax of "Since:" and "Deprecated:" annotations.
One cannot just use the min/max values since the precision digits must
also be accounted for (as well as one additional character for the
decimal separator).
Current implementation is not perfect yet because GimpSizeEntry code
itself does not yet use gimp_unit_get_scaled_digits(). Moreover the
entry size could be updated when changing units (or the original size
be actually based of the bigger width considering every possible unit).
