I updated GimpScaleEntry and GimpColorScaleEntry header to use
respectively the macros G_DECLARE_DERIVABLE_TYPE and
G_DECLARE_FINAL_TYPE.
Though having the `priv` structure directly in the object data is
extremely comfortable for developing (hence we don't want to use this
macro on core code as it makes coding a bit more bothersome), it is true
that it does not make for a very pretty public interface (showing a
`priv` member which nobody can actually use, and a private type which
has no associated functions). So it might be a good idea to use these
macros at least on libgimp side.
I am still not sure though if it is a good idea so we could say it's an
experiment. At least the docs says that using G_DECLARE_FINAL_TYPE does
not affect ABI stability as it can later be changed into a
G_DECLARE_DERIVABLE_TYPE because the class structure stays private. So
at least that's one good point.
P.S.: also reordering gimpwidgets.def.
Similarly to GimpScaleEntry, this is meant to replace usage of
gimp_color_scale_entry_new() by having a proper widget. This is a child
class of GimpScaleEntry which simply replaces the GtkScale by a
GimpColorScale by adding a GimpScaleEntry class method to create the
scale widget (only restriction: it must be a GtkRange subtype).
This also triggers me to rename gimp_scale_entry_get_scale() into
gimp_scale_entry_get_range() (as well as the 2 plug-ins already using
this function).
This fixes#5838 which was caused by an incomplete port
of this plug-in to the new introspection API.
For now we do keep the n_drawables parameter of save_ora until
issue #5312 is fixed. Not doing this would cause saving to fail.
I got rid of gimp_scale_entry_set_sensitive(), as we can now use the
generic gtk_widget_set_sensitive(), and I ported the 2 plug-ins using
this function.
I also created gimp_scale_entry_set_value() to set the value (nicer than
setting object properties).
For very small ranges, just dividing by 10 and 100 is not very good. You
could end up with weird step values. It is often better to use 10^(-x)
values just below your range.
I.e for a 0.5 range, a step of 0.1 and page of 0.01 are probably fine
(better than 0.05 and 0.005).
Of course as usual these are default values only and setting custom
increments is possible through available API.
Also fixing a small bug in gimp_scale_entry_set_increments() added in
commit 0f05825a29.
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.
* Add a gimp_scale_entry_get_value() because if we don't do a property
widget, getting the value of the widget easily is a main point.
* Move gimp_scale_entry_(set|get)_logarithmic() to the new class API.
* Internally edit the GtkSpinButton width depending on min/max values,
place digits, and possible value sign.
* Emit a "value-changed" signal (similarly to other widgets with a
value), for cases when just binding the "value" property is not
enough.
* Finally use the new API in palette-import-dialog.
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).
It is more accurate to say it returns a list of parasite names rather
than a list of parasites (as we could take it as meaning a list of
GimpParasite). Of course, we would soon see the actual element contents
(if not for the introspection metadata (element-type gchar*)), but
better being accurate in textual docs too.
There was a /* FIXME MOVE TO PRIVATE */ and anyway it makes sense to not
leave such data in the public API.
I note that the whole widget declaration is between #ifndef
GIMP_DISABLE_DEPRECATED macros so maybe we should just delete it
altogether for GIMP 3, but it might still have a usage. Maybe it could
also be interesting to experiment with the file portal on such widget
for plug-in usage? Let's see.
This is the bug which triggered me to do previous commit because the
error message was talking about a procedure name. Now the error message
is right, but let's not have an error at all! ;-)
… instead of gimp_pdb_is_canonical_procedure().
The later would set an error saying "Procedure name '%s' is not a
canonical identifier". Yet the data label is not a procedure name. It is
a random name. I'm not sure why we need it to be canonical too, but why
not. In any case, let's use the right function.
Commit d3139e0f7c added suuporting for saving/exporting with
muti-selection, but forgot to added the necessary GObject Introspection
annotation for the callback's `drawables` argument, which confused
bindings.
https://gitlab.gnome.org/GNOME/gimp/-/issues/5312
Add info about the hicolor trick on 2.99.2 news. Also start a 2.99.4
news with the first update (action search, since there is a visible
Preferences settings for this, better not backport this maybe).
… of query_procedures().
Since our procedure list is now fully dynamic with runtime check, it's
much better to run it at every startup. Basically if some has updated
libheif with new encoders/decoders, we want GIMP to be aware at it at
next startup even if the plug-in has not been updated.
Upcoming autoconf-2.70 exposes deficiency in configure.ac:
```
$ autoconf-2.70_beta2 && ./configure --host=x86_64-pc-linux-gnu
./configure: line 1430: 5: Bad file descriptor
checking whether is declared... ./configure: line 1432: ${+y}: bad
```
It happens because macros are called with parameters using insufficient quoting.
More details at https://lists.gnu.org/archive/html/bug-autoconf/2020-10/msg00027.html
The fix only amends `--with-linux-input`. Other cases of underquoting
will need to be handled separately.
Fix-by: Zack Weinberg
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
This reverts commit e869a11270.
Mitch could reproduce the issue and made each .actions file into
respective CLEANFILES in commit 0052803313. At least now the distcheck
job works, so let's just make its failure forbidden again.
Some people had been complaining that they couldn't find some actions in
some case, which was only because they were in states where the actions
were non-sensitive. So it was "normal" (i.e. not a bug), yet I can see
how it can be disturbing especially when we don't realize that an action
is meant to be inactive in some given case.
Of course the option to show all actions already existed in the
Preferences. But as most options in Preferences, this is hardly
discoverable and many people only use default settings. Moreover showing
hidden action made the action search cluttered with non-sensitive
actions in the middle of sensitive ones.
This change gets rid of the "Show unavailable actions" settings and
always show all matching actions. In order not to clutter the list with
useless results, I simply updated the display logics to always show
non-sensitive action after sensitive ones. Note that even non-sensitive
actions will still be ordered in a better-match-on-top logics, yet they
will be after sensitive actions. So the top results will be the best
matches among sensitive actions (action in history), followed by various
levels of matches (actions with matching labels, tooltips, different
order matches, etc.); then they will be followed by best matches among
non-sensitive actions, followed by the same levels of matches as
sensitive ones.
This way, we still keep a very relevant result and there is no need to
have a settings for this.
Let's start up some porting guide for plug-in developers. One of the
first things to do is to get rid of any deprecated functions from 2.10
or older versions. In the current stable, these would "just" output
warnings, but in the dev version, all deprecated functions got removed
and the build would fail.
This list may not be complete. I mostly created it by some grep on
deprecated functions from libgimp 2.10.
There were still a few references to functions which have been removed
from GIMP 3 (because they were deprecated in previous versions), which I
found as I was doing an inventory of removed functions.
Jehan