The GimpProcedureDialog API allows int and double SpinScales. However,
it calls gimp_prop_widget_set_factor () which requires doubles.
A conditional check for a double property was added to this call.
A check was also added to ensure int properties have a factor of 1.0.
… don't include it from public gimpui.h.
As reviewed during !786, if this file is private, the name should show it
clearly. And of course, we must not include it from another public header, since
it won't be installed.
This also fixes building plug-ins with gimptool as reported by tmanni:
e00f2d7f50 (note_1650791)
Simplifies chooser widgets (e.g. GimpBrushSelect) by eliminating attributes (e.g. opacity) of chosen resource.
See #8745, but this commit fixes that by first refactoring the code.
Refactors GUI widgets (e.g. GimpBrushSelectButton and GimpBrushSelect etc.)
Refactor by "Extract class" GimpResourceSelectButton from GimpBrushSelectButton etc.
This moves common code into an inherited class (formerly called GimpSelectButton)
but the subclasses still exist.
The subclasses mainly just do drawing now.
Refactor by "Extract module" GimpResourceSelect from GimpBrushSelect etc.
Moves common code into one file, generic at runtime on type of GimpResource,
that is, the new code dispatches on type i.e. switch statements.
In the future, when core is changed some of that can be deleted.
The files gimpbrushselect.[c,h] etc. are deleted.
The module adapts the API from core to the API of callbacks to libgimp.
Note that core is running the resource chooser (select) widgets remotely.
Core is still calling back over the wire via PDB with more attributes
than necessary.
The new design gets the attributes from the resource themselves,
instead of receiving them from core callback.
The libgimp side adapts by discarding unneeded attributes.
In the future, core (running choosers for plugins) can be simplified also.
Fix gimp_prop_chooser_brush_new same as other resources.
Finish changes, and clean style.
Annotations
So procedures can declare args and GimpProcedureDialog show chooser
widgets
Fix so is no error dialog on id_is_valid for resources
Palette.pdb changes and testing
Memory mgt changes
Gradient pdb
Font and Pattern tests
Test brush, palette
Cleanup, remove generator
Rebase, edit docs, install test-dialog.py
Whitespace, and fix failed distcheck
Fix some clang-format, fix fail distcheck
Fix distcheck
Cleanup from review Jehan
Continuing the changes in #8124, let's have properties labels and blurbs
both localized on plug-in code, i.e. with gettext calls directly in
GIMP_PROC_ARG_*() calls.
Note that it was already the case for blurbs (longer description,
tooltip) as I couldn't find code where we'd localize it further down the
line. But we were running gettext on nicks (shorter description, label)
inside GimpProcedureDialog code. Let's not do this anymore.
This will make the whole localization much more clear and obvious. There
is no "later localized" case anymore. Now let's localize everything
directly when the arguments are created.
… GimpIntStore for value filling.
GimpIntComboBox was not taking ownership of the value store whereas the
newer GimpIntRadioFrame was taking ownership. As a more common practice,
I decided to leave ownership to the caller (which will therefore have
the responsibility to free the data) in the main class and property
widget APIs.
On the other hand, let's steal ownership of the store objects in the
gimp_procedure_dialog_get_int_*() functions as these are really used for
very quick and easy creation of dialogs by script writers. It would even
allow to create a GimpIntStore inline within the widget creation
function, if one wanted to.
… GimpProcedureDialog.
- gimp_prop_file_chooser_button_new() now works also with properties
G_PARAM_SPEC_OBJECT having a value_type == G_TYPE_FILE (additionally
to GIMP_PARAM_SPEC_CONFIG_PATH properties).
- gimp_procedure_dialog_get_widget() will now create a
GtkFileChooserButton in open mode for such a GFile property.
- New gimp_procedure_dialog_get_file_chooser() API to create
GtkFileChooserButton for GFile properties in other modes.
Current limitation: GtkFileChooserButton doesn't have a label. This
should be fixed, probably by creating another custom widget with would
be a labelized file chooser button.
… %GIMP_TYPE_SPIN_SCALE in gimp_procedure_dialog_get_widget().
The dedicated function is for when a plug-in wants to use a scale range
multiplied by a factor. Otherwise using the generic function is fine.
Now using the new GimpLabelColor as new default for RGB properties. It
makes more sense that the default is editable widgets. Also it has a
label, which is better default widget.
Also gimp_procedure_dialog_get_color_widget() now only returns
GimpLabelColor widgets.
It is now discouraged to create constructor-type _new() functions with
custom code, which would make them behave differently that simply
calling g_object_new() with the GType and relevant properties. The main
reason is that some bindings would create objects with g_object_new() so
it should create expected code too.
See: https://gi.readthedocs.io/en/latest/writingbindableapis.html#custom-code-in-constructors
Here it was complicated for a few reasons:
- We hack "title" property to use the procedure's menu label by default
(without the mnemonic). For this, I overrode the GtkWindow property.
- We want "use-header-bar" to follow the application general settings by
default. Since it is a CONSTRUCT_ONLY property, g_object_set() is not
possible in _init() and _constructed(). Instead I had to override the
constructor() method to set this at construction time (yet still allow
API users to override this with the property at creation).
- Similarly, "help-func" is a CONSTRUCT_ONLY property, so I used the
same trick.
- As for "help-id", I now just set it in _constructed(). This was the
easy one.
All objects of subclass GtkWindow are special as they are actually owned
by GTK which keeps a list of all top-level windows. So we cannot
actually give ownership to the caller. With GObject Introspection in
particular, it will mean a double-free of the dialog object (by GTK,
then by the GI layer).
See also gobject-introspection#394.
As explained in GtkSizeGroup docs, all objects inside a size group holds
a reference to it. So once we destroy the last object inside these, it
will be freed too and we should drop the initial reference after adding
the objects.
Only the main size group reference is kept until the end, because we are
adding and removing objects from it regularly, so it is possible that it
is empty again at some intermediary states. Yet we don't want to free it
when this happens.
All the widgets with label inside GimpProcedureDialog have same
GtkSizeGroup (dialog->priv->label_group), which result in wrong sizes of
widget if any of the label is long. In this commit, a new GtkSizeGroup
is made for each of the container, so that labels are aligned but size
of widget in one container do not affect size of widgets in other
containers.
For the widget not belonging to any of the container, default
GtkSizeGroup (dialog->priv->label_group) is used.
Added an option for exporting thumbnail in WebP Export dialogbox.
Additionally, introduced a function gimp_procedure_dialog_fill_expander.
The function is similar to gimp_procedure_dialog_fill_frame but allows
adding GtkExpander instead of GtkFrame.
Though the previous implementation worked fine on C plug-ins, I realized
it was problematic on bindings. In particular, the Python binding at
least was somehow freeing returned floating objects, unless assigned to
a variable.
For instance, the widget returned by the following code:
> dialog.get_color_widget('color', True, GimpUi.ColorAreaType.FLAT)
… was freed by the PyGObject binding when it was floating, even though
(transfer none) was set (hence telling the binding it should not free
the returned object). The workaround was to assign it to some variable,
even though I was not planning to use it.
Making sure all references are full fixes it.
GObject docs also notes:
> **Note**: Floating references are a C convenience API and should not
> be used in modern GObject code. Language bindings in particular find
> the concept highly problematic, as floating references are not
> identifiable through annotations, and neither are deviations from the
> floating reference behavior, like types that inherit from
> GInitiallyUnowned and still return a full reference from
> g_object_new().
… 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).
New function to set some procedure dialog's widget sensitive, either
with a constant value, or by binding it to a boolean property (or its
inverse) of a config object.
As the docs says, this was always allowed and would just imply we want a
dialog with all properties in order of declaration.
Yet this usage would output this warning:
> plug-ins/file-fli/fli-gimp.c:976:3: warning: not enough variable arguments to fit a sentinel [-Wformat=]
This commit take care of this warning.
… but only when a menu label was set with
gimp_procedure_set_menu_label(). In such case, this menu label is used
as dialog title (with mnemonic underscore removed).
The term "Defaults" is not clear enough and looks like it may be
redundant with the "Factory Defaults" button. Let's try an alternative
"Save Settings" and "Load Saved Settings".
Also adding some tooltips.
And finally making the "Load Saved Settings" only sensitive if the "Save
Settings" button had been used at least once.
This is what the GNOME's HIG calls a "button menu" apparently. Adding
this arrow makes it clearer that it is not a finale action but an
intermediate one allowing you to see more choices.
See also report #6145 where this was raised among other things.
Use gtk_widget_list_mnemonic_labels() to look for mnemonic of common GTK
widgets. Also warn when several mnemonic were set on a given widget
("wasting" keys when it seems we are always looking for available
mnemonics).
Also warn with core action IDs too when they miss a mnemonic.
Make sure that the OK button ("Export", etc.) is always the default
action in a GimpProcedureDialog. This allows to quickly validate the
default settings.
Though a GimpScaleEntry could already be created with
gimp_procedure_dialog_get_widget(), this specific function allows to add
a factor to the property range.
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.
- New gimp_procedure_dialog_fill_box(_list)() functions to create a
GtkBox in the layout.
- Generating widgets for parameters of type double (and computing
appropriate "ok defaults" digits for these, depending on the min-max
range of the property).
… class GimpSaveProcedureDialog.
The idea is that we have basically the same code in most file format
plug-ins to handle various generic metadata, yet usually with slight
differences here and there. Even behavior is sometimes a bit different
even though there is no reason for the logics to be different from one
format to another.
So I move the metadata support logics into GimpSaveProcedure (and
GimpProcedureConfig still keeps the main export logics). The GUI logics
is now in a new GimpSaveProcedureDialog. So export plug-ins will now get
the creation of generic metadata nearly for free. All they have to do is
to tell what kind of metadata the GimpSaveProcedure supports with the
gimp_save_procedure_set_support_*() functions.
Then consistency will apply:
- If a format supports a given metadata, they will always have an
auxiliary argument with the same name across plug-ins.
- The label and tooltips will also be always the same in the GUI.
- Order of metadata widgets will also stay consistent.
- The widgets will work the same (no more "Comment" text view missing in
one plug-in but present in another, or with an entry here, and a text
view there, and so on).
Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins
to "declare" one of their options as a metadata option, and therefore
have it packed within the "Metadata" block which is now created (for
instance for PNG/TIFF/JPEG specific metadata). This allows a nicer
organization of dialogs.
A very common issue we have with dialog creation is good mnemonics. In
particular, we want to:
* Keep consistent mnemonics for common features (basically the core
buttons) common to all plug-in dialogs.
* Have mnemonics for all options.
* Avoid duplicate mnemonics if possible.
Mnemonics are a usability/accessibility feature which can be important
for people using the keyboard a lot (not necessarily only because they
prefer keyboard, but also possibly because of various disorders).
This code will check at runtime that there are no missing or duplicate
mnemonics and simply print to stderr. We don't want to bother overly the
users about these, but we want developers and translators to be aware
about these so that they can easily spot and fix them.
gimp_procedure_dialog_fill_frame() allows creating a GtkFrame, in
particular with a boolean widget which can therefore control
sensitivity of the frame contents.
gimp_procedure_dialog_get_label() creates a simple text label.
- New GimpLabelIntWidget which is a label associated to any widget with
an integer "value" property.
- New gimp_procedure_dialog_get_int_combo() which creates a labeled
combo box from an integer property of the GimpProcedureConfig.
- Renamed gimp_procedure_dialog_populate*() with
gimp_procedure_dialog_fill*(). Naming is hard! I hesitated using
_pack() as well (similarly to GtkBox API).
- New gimp_procedure_dialog_fill_flowbox*() functions to create a
GtkFlowBox filled with property widgets (or other container widgets as
we can pack them one in another). This is an alternative way to build
your GUI with sane defaults, with list of property names.
- Add some border width on the main dialog box.
- Remove the additional border width on the button box but add some
padding instead to separate it a bit from the specific plug-in
widgets.
- Add GimpLabelSpin as one of the possible property widgets to represent
an integer property and make it the default.
- Put labels of GimpLabeled widgets into a common GtkSizeGroup so that
labels and entry widgets are aligned, hence much faster to parse with
the eyes.
This is still a very early baseline for a more extended API. This first
version is not able to capture the complexity of most existing plug-in
dialogs.
Add internal GimpProcedureConfig API to load/save "default values"
which are to be treated as if they were the hardcoded GParamSpec
defaults, but user-configurable. Also make all other load/save
functions available to other libgimp files.
In gimp_procedure_run(), if incomplete arguments are passed, don't
just complete them with the GParamSpec defaults, but look up the
user-saved defaults and use them if they exist. This happens before
everything else and brings back the PNG export feature of using
user-saved defaults also in non-interactive mode (but for all
procedures not just PNG export).
In GimpProcedureDialog, add "Load Defaults" and "Save Defaults"
buttons, they are the only way of managing the user-configurable
procedure defaults.
When clicking "Reset", show a popover with the reset options "Initial
Values" and "Factory Defaults".
