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".
Jehan