dnrops
/
gimp
mirror of https://github.com/GNOME/gimp.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
gimp/libgimp/gimpproceduredialog.c

2879 lines
105 KiB
C
Raw Normal View History

libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
/* GIMP - The GNU Image Manipulation Program
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
*
* gimpproceduredialog.c
* Copyright (C) 2019 Michael Natterer <mitch@gimp.org>
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
* Copyright (C) 2020 Jehan
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <https://www.gnu.org/licenses/>.
*/
#include "config.h"
#include <gegl.h>
#include <gtk/gtk.h>
#include "libgimpwidgets/gimpwidgets.h"
libgimp*, plug-ins: reorganize the resource property choosers. - Move the property widget functions for GimpResource properties into a new libgimp/gimppropwidgets.[ch] file. This mirrors the files libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types. - Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new(). - gimp_prop_chooser_factory() doesn't need to be public. - Add a label to GimpResourceSelectButton, make so that the gimp_prop_chooser_*_new() functions set the property nick to this label and add this label to the size group in GimpProcedureDialog.
2023-08-18 05:02:38 +08:00
#include "libgimp/gimppropwidgets.h"
libgimp: rename gimppropchooser.* to gimppropchooser-private.* and… … 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: https://gitlab.gnome.org/GNOME/gimp/-/commit/e00f2d7f5034bebebf1b3cc30820071dfd078192#note_1650791
2023-01-26 22:46:12 +08:00
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
#include "gimp.h"
libgimp*, plug-ins: reorganize the resource property choosers. - Move the property widget functions for GimpResource properties into a new libgimp/gimppropwidgets.[ch] file. This mirrors the files libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types. - Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new(). - gimp_prop_chooser_factory() doesn't need to be public. - Add a label to GimpResourceSelectButton, make so that the gimp_prop_chooser_*_new() functions set the property nick to this label and add this label to the size group in GimpProcedureDialog.
2023-08-18 05:02:38 +08:00
#include "gimppropwidgets.h"
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
#include "gimpui.h"
libgimp: improve handling of procedure default values a lot 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".
2019-09-27 01:06:17 +08:00
#include "gimpprocedureconfig-private.h"
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
#include "libgimp-intl.h"
enum
{
PROP_0,
PROP_PROCEDURE,
PROP_CONFIG,
libgimp: have gimp_procedure_dialog_new() behave like g_object_new(). 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.
2021-08-04 01:35:50 +08:00
/* From here the overridden properties. */
PROP_TITLE,
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
N_PROPS
};
#define RESPONSE_RESET 1
struct _GimpProcedureDialogPrivate
{
GimpProcedure *procedure;
GimpProcedureConfig *config;
libgimp: improve handling of procedure default values a lot 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".
2019-09-27 01:06:17 +08:00
GimpProcedureConfig *initial_config;
libgimp: new gimp_procedure_dialog_set_ok_label() function. This allows to set a custom label for the OK button.
2023-06-15 09:56:00 +08:00
GtkWidget *ok_button;
libgimp: improve handling of procedure default values a lot 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".
2019-09-27 01:06:17 +08:00
GtkWidget *reset_popover;
libgimp: rename "Save|Load Defaults" buttons in GimpProcedureDialog. 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.
2021-01-08 04:59:59 +08:00
GtkWidget *load_settings_button;
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
GHashTable *widgets;
libgimp: mnemonic duplicate verification in GimpProcedureDialog. 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.
2020-11-20 08:29:08 +08:00
GHashTable *mnemonics;
GHashTable *core_mnemonics;
libgimp: improve design and usability of generated procedure dialog. - 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.
2020-11-06 00:46:02 +08:00
GtkSizeGroup *label_group;
libgimp: new gimp_procedure_dialog_set_sensitive(). 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.
2021-04-07 02:10:46 +08:00
GHashTable *sensitive_data;
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
};
libgimp: new gimp_procedure_dialog_set_sensitive(). 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.
2021-04-07 02:10:46 +08:00
typedef struct GimpProcedureDialogSensitiveData
{
gboolean sensitive;
GObject *config;
gchar *config_property;
gboolean config_invert;
} GimpProcedureDialogSensitiveData;
libgimp: new function gimp_procedure_dialog_set_sensitive_if_in(). This function allows to change the sensitivity of a widget depending on the value of another property. We already had gimp_procedure_dialog_set_sensitive() except it was only syncing with a boolean property, whereas the new function can compare with any property type.
2023-06-15 09:31:42 +08:00
typedef struct GimpProcedureDialogSensitiveData2
{
GimpProcedureDialog *dialog;
gchar *widget_property;
GimpValueArray *values;
gboolean in_values;
} GimpProcedureDialogSensitiveData2;
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
libgimp: have gimp_procedure_dialog_new() behave like g_object_new(). 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.
2021-08-04 01:35:50 +08:00
static GObject * gimp_procedure_dialog_constructor (GType type,
guint n_construct_properties,
GObjectConstructParam *construct_properties);
static void gimp_procedure_dialog_constructed (GObject *object);
static void gimp_procedure_dialog_dispose (GObject *object);
static void gimp_procedure_dialog_set_property (GObject *object,
guint property_id,
const GValue *value,
GParamSpec *pspec);
static void gimp_procedure_dialog_get_property (GObject *object,
guint property_id,
GValue *value,
GParamSpec *pspec);
static void gimp_procedure_dialog_real_fill_list (GimpProcedureDialog *dialog,
GimpProcedure *procedure,
GimpProcedureConfig *config,
GList *properties);
static void gimp_procedure_dialog_reset_initial (GtkWidget *button,
GimpProcedureDialog *dialog);
static void gimp_procedure_dialog_reset_factory (GtkWidget *button,
GimpProcedureDialog *dialog);
static void gimp_procedure_dialog_load_defaults (GtkWidget *button,
GimpProcedureDialog *dialog);
static void gimp_procedure_dialog_save_defaults (GtkWidget *button,
GimpProcedureDialog *dialog);
static gboolean gimp_procedure_dialog_check_mnemonic (GimpProcedureDialog *dialog,
GtkWidget *widget,
const gchar *id,
const gchar *core_id);
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
static GtkWidget *
libgimp: have gimp_procedure_dialog_new() behave like g_object_new(). 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.
2021-08-04 01:35:50 +08:00
gimp_procedure_dialog_fill_container_list (GimpProcedureDialog *dialog,
const gchar *container_id,
GtkContainer *container,
GList *properties);
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
libgimp: new function gimp_procedure_dialog_set_sensitive_if_in(). This function allows to change the sensitivity of a widget depending on the value of another property. We already had gimp_procedure_dialog_set_sensitive() except it was only syncing with a boolean property, whereas the new function can compare with any property type.
2023-06-15 09:31:42 +08:00
static void gimp_procedure_dialog_set_sensitive_if_in_cb (GObject *config,
GParamSpec *param_spec,
GimpProcedureDialogSensitiveData2 *data);
static void gimp_procedure_dialog_sensitive_data_free (GimpProcedureDialogSensitiveData *data);
static void gimp_procedure_dialog_sensitive_cb_data_free (GimpProcedureDialogSensitiveData2 *data);
libgimp: new gimp_procedure_dialog_set_sensitive(). 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.
2021-04-07 02:10:46 +08:00
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
G_DEFINE_TYPE_WITH_PRIVATE (GimpProcedureDialog, gimp_procedure_dialog,
GIMP_TYPE_DIALOG)
#define parent_class gimp_procedure_dialog_parent_class
static GParamSpec *props[N_PROPS] = { NULL, };
static void
gimp_procedure_dialog_class_init (GimpProcedureDialogClass *klass)
{
GObjectClass *object_class = G_OBJECT_CLASS (klass);
libgimp: have gimp_procedure_dialog_new() behave like g_object_new(). 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.
2021-08-04 01:35:50 +08:00
object_class->constructor = gimp_procedure_dialog_constructor;
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
object_class->constructed = gimp_procedure_dialog_constructed;
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
object_class->dispose = gimp_procedure_dialog_dispose;
object_class->get_property = gimp_procedure_dialog_get_property;
object_class->set_property = gimp_procedure_dialog_set_property;
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
klass->fill_list = gimp_procedure_dialog_real_fill_list;
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
props[PROP_PROCEDURE] =
libgimp: document GimpProcedureDialog's properties
2020-01-06 01:37:58 +08:00
g_param_spec_object ("procedure",
"Procedure",
"The GimpProcedure this dialog is used with",
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
GIMP_TYPE_PROCEDURE,
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
GIMP_PARAM_READWRITE |
libgimp: have gimp_procedure_dialog_new() behave like g_object_new(). 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.
2021-08-04 01:35:50 +08:00
G_PARAM_CONSTRUCT_ONLY);
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
props[PROP_CONFIG] =
libgimp: document GimpProcedureDialog's properties
2020-01-06 01:37:58 +08:00
g_param_spec_object ("config",
"Config",
libgimp: GimpProcedureDialog: next time save before committing...
2020-01-06 01:57:17 +08:00
"The GimpProcedureConfig this dialog is editing",
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
GIMP_TYPE_PROCEDURE_CONFIG,
GIMP_PARAM_READWRITE |
G_PARAM_CONSTRUCT);
libgimp: have gimp_procedure_dialog_new() behave like g_object_new(). 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.
2021-08-04 01:35:50 +08:00
g_object_class_install_properties (object_class, N_PROPS - 1, props);
/**
* GimpProcedureDialog:title:
*
* Overrides the "title" property of #GtkWindow.
* When %NULL, the title is taken from the #GimpProcedure menu label.
*
* Since: 3.0
*/
g_object_class_override_property (object_class, PROP_TITLE, "title");
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
}
static void
gimp_procedure_dialog_init (GimpProcedureDialog *dialog)
{
dialog->priv = gimp_procedure_dialog_get_instance_private (dialog);
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
libgimp: new gimp_procedure_dialog_set_sensitive(). 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.
2021-04-07 02:10:46 +08:00
dialog->priv->widgets = g_hash_table_new_full (g_str_hash, g_str_equal, g_free, g_object_unref);
dialog->priv->mnemonics = g_hash_table_new_full (g_direct_hash, NULL, NULL, g_free);
libgimp: mnemonic duplicate verification in GimpProcedureDialog. 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.
2020-11-20 08:29:08 +08:00
dialog->priv->core_mnemonics = g_hash_table_new_full (g_direct_hash, NULL, NULL, g_free);
libgimp: new gimp_procedure_dialog_set_sensitive(). 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.
2021-04-07 02:10:46 +08:00
dialog->priv->label_group = gtk_size_group_new (GTK_SIZE_GROUP_HORIZONTAL);
dialog->priv->sensitive_data = g_hash_table_new_full (g_str_hash, g_str_equal, g_free,
(GDestroyNotify) gimp_procedure_dialog_sensitive_data_free);
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
}
libgimp: have gimp_procedure_dialog_new() behave like g_object_new(). 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.
2021-08-04 01:35:50 +08:00
static GObject *
gimp_procedure_dialog_constructor (GType type,
guint n_construct_properties,
GObjectConstructParam *construct_properties)
{
gboolean use_header_bar = FALSE;
gboolean use_header_bar_edited = FALSE;
gboolean help_func_edited = FALSE;
libgimp: take into account case when gtk_settings_get_default() returns NULL. I believe it should not happen in normal GUI case (which is when you create a GimpProcedureDialog). I had the issue while moving around some plug-in code and moved dialog creation before gimp_ui_init() by mistake. The issue was not obvious until I followed the trace inside libgimp. This would be even more frustrating for plug-in developers so let's have a clear warning message giving the possible plug-in crash reason.
2023-08-29 21:27:02 +08:00
if (gtk_settings_get_default () != NULL)
g_object_get (gtk_settings_get_default (),
"gtk-dialogs-use-header", &use_header_bar,
NULL);
else
g_warning ("%s: no default screen. Did you call gimp_ui_init()?", G_STRFUNC);
libgimp: have gimp_procedure_dialog_new() behave like g_object_new(). 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.
2021-08-04 01:35:50 +08:00
for (guint i = 0; i < n_construct_properties; i++)
{
/* We need to override the default values of some properties and
* can't do it in _init() or _constructed() because it's too late
* for G_PARAM_CONSTRUCT_ONLY properties.
* Moreover we don't do it in _new() because we need this to work
* also in bindings sometimes using only constructors to
* initialize their object, hence we can't rely on our _new()
* function (relying on _new() functions doing more than the
* constructor is now discouraged by GTK/GLib developers).
*/
GObjectConstructParam property;
property = construct_properties[i];
if (! use_header_bar_edited &&
g_strcmp0 (g_param_spec_get_name (property.pspec),
"use-header-bar") == 0)
{
if (g_value_get_int (property.value) == -1)
g_value_set_int (property.value, (gint) use_header_bar);
use_header_bar_edited = TRUE;
}
else if (! help_func_edited &&
g_strcmp0 (g_param_spec_get_name (property.pspec),
"help-func") == 0)
{
if (g_value_get_pointer (property.value) == NULL)
g_value_set_pointer (property.value,
gimp_standard_help_func);
help_func_edited = TRUE;
}
if (use_header_bar_edited && help_func_edited)
break;
}
return G_OBJECT_CLASS (parent_class)->constructor (type,
n_construct_properties,
construct_properties);
}
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
static void
gimp_procedure_dialog_constructed (GObject *object)
{
GimpProcedureDialog *dialog;
GimpProcedure *procedure;
libgimp: have gimp_procedure_dialog_new() behave like g_object_new(). 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.
2021-08-04 01:35:50 +08:00
const gchar *help_id;
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
const gchar *ok_label;
GtkWidget *hbox;
GtkWidget *button;
libgimp: add down arrow to "Reset" button to show it will pop-up a menu. 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.
2021-01-07 01:16:34 +08:00
GtkWidget *widget;
GtkWidget *box;
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
GtkWidget *content_area;
gchar *role;
G_OBJECT_CLASS (parent_class)->constructed (object);
dialog = GIMP_PROCEDURE_DIALOG (object);
procedure = dialog->priv->procedure;
libgimp: have gimp_procedure_dialog_new() behave like g_object_new(). 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.
2021-08-04 01:35:50 +08:00
role = g_strdup_printf ("gimp-%s", gimp_procedure_get_name (procedure));
help_id = gimp_procedure_get_help_id (procedure);
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
g_object_set (object,
libgimp: have gimp_procedure_dialog_new() behave like g_object_new(). 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.
2021-08-04 01:35:50 +08:00
"role", role,
"help-id", help_id,
/* This may seem weird, but this is actually because we
* are overriding this property and if the title is NULL
* in particular, we create one out of the procedure's
* menu label. So we force the reset this way.
*/
"title", gtk_window_get_title (GTK_WINDOW (dialog)),
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
NULL);
g_free (role);
if (GIMP_IS_LOAD_PROCEDURE (procedure))
ok_label = _("_Open");
else if (GIMP_IS_SAVE_PROCEDURE (procedure))
ok_label = _("_Export");
else
ok_label = _("_OK");
libgimp: add down arrow to "Reset" button to show it will pop-up a menu. 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.
2021-01-07 01:16:34 +08:00
/* Reset button packaged with a down-arrow icon to show it pops up
* more choices.
*/
button = gtk_button_new ();
box = gtk_box_new (GTK_ORIENTATION_HORIZONTAL, 2);
widget = gtk_label_new_with_mnemonic (_("_Reset"));
gtk_label_set_mnemonic_widget (GTK_LABEL (widget), button);
gtk_box_pack_start (GTK_BOX (box), widget, FALSE, FALSE, 1);
gtk_widget_show (widget);
widget = gtk_image_new_from_icon_name (GIMP_ICON_GO_DOWN, GTK_ICON_SIZE_MENU);
gtk_box_pack_start (GTK_BOX (box), widget, FALSE, FALSE, 1);
gtk_widget_show (widget);
gtk_container_add (GTK_CONTAINER (button), box);
gtk_widget_show (box);
gtk_dialog_add_action_widget (GTK_DIALOG (dialog), button, RESPONSE_RESET);
gtk_widget_show (button);
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
gimp_procedure_dialog_check_mnemonic (GIMP_PROCEDURE_DIALOG (dialog), button, NULL, "reset");
libgimp: add down arrow to "Reset" button to show it will pop-up a menu. 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.
2021-01-07 01:16:34 +08:00
/* Cancel and OK buttons. */
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
button = gimp_dialog_add_button (GIMP_DIALOG (dialog),
_("_Cancel"), GTK_RESPONSE_CANCEL);
gimp_procedure_dialog_check_mnemonic (GIMP_PROCEDURE_DIALOG (dialog), button, NULL, "cancel");
button = gimp_dialog_add_button (GIMP_DIALOG (dialog),
ok_label, GTK_RESPONSE_OK);
libgimp: new gimp_procedure_dialog_set_ok_label() function. This allows to set a custom label for the OK button.
2023-06-15 09:56:00 +08:00
dialog->priv->ok_button = button;
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
gimp_procedure_dialog_check_mnemonic (GIMP_PROCEDURE_DIALOG (dialog), button, NULL, "ok");
Issue #5967: Inconvenient focus in PNG export. Make sure that the OK button ("Export", etc.) is always the default action in a GimpProcedureDialog. This allows to quickly validate the default settings.
2020-11-26 08:57:53 +08:00
/* OK button is the default action and has focus from start.
* This allows to just accept quickly whatever default values.
*/
gtk_widget_set_can_default (button, TRUE);
gtk_widget_grab_focus (button);
gtk_widget_grab_default (button);
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
gimp_dialog_set_alternative_button_order (GTK_DIALOG (dialog),
GTK_RESPONSE_OK,
RESPONSE_RESET,
GTK_RESPONSE_CANCEL,
-1);
gimp_window_set_transient (GTK_WINDOW (dialog));
/* Main content area. */
content_area = gtk_dialog_get_content_area (GTK_DIALOG (dialog));
gtk_container_set_border_width (GTK_CONTAINER (content_area), 12);
gtk_box_set_spacing (GTK_BOX (content_area), 3);
/* Bottom box buttons with small additional padding. */
hbox = gtk_button_box_new (GTK_ORIENTATION_HORIZONTAL);
gtk_box_set_spacing (GTK_BOX (hbox), 6);
gtk_button_box_set_layout (GTK_BUTTON_BOX (hbox), GTK_BUTTONBOX_START);
gtk_box_pack_end (GTK_BOX (content_area), hbox, FALSE, FALSE, 0);
gtk_container_child_set (GTK_CONTAINER (content_area), hbox,
"padding", 3, NULL);
gtk_widget_show (hbox);
libgimp: rename "Save|Load Defaults" buttons in GimpProcedureDialog. 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.
2021-01-08 04:59:59 +08:00
button = gtk_button_new_with_mnemonic (_("_Load Saved Settings"));
gtk_widget_set_tooltip_text (button, _("Load settings saved with \"Save Settings\" button"));
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
gimp_procedure_dialog_check_mnemonic (GIMP_PROCEDURE_DIALOG (dialog), button, NULL, "load-defaults");
gtk_box_pack_start (GTK_BOX (hbox), button, FALSE, FALSE, 0);
gtk_widget_show (button);
g_signal_connect (button, "clicked",
G_CALLBACK (gimp_procedure_dialog_load_defaults),
dialog);
libgimp: rename "Save|Load Defaults" buttons in GimpProcedureDialog. 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.
2021-01-08 04:59:59 +08:00
gtk_widget_set_sensitive (button,
libgimp: export again gimp_procedure_config_*_default() functions. This partially revert some of the changes in commit 652a1b4388 because the Windows CI suddenly failed because of this (my local build on Linux didn't have any problem though) with: > /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_save_defaults': > /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2570:(.text+0x633): undefined reference to `_gimp_procedure_config_save_default' > /usr/bin/x86_64-w64-mingw32-ld: /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2576:(.text+0x644): undefined reference to `_gimp_procedure_config_has_default' > /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_load_defaults': > /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2549:(.text+0xa2f): undefined reference to `_gimp_procedure_config_load_default' > /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_constructed': > /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:368:(.text+0x11b1): undefined reference to `_gimp_procedure_config_has_default' This is because these functions are used not only inside libgimp but also across inside libgimpui. As a consequence, the build fails when linking libgimpui.
2023-10-16 05:20:44 +08:00
gimp_procedure_config_has_default (dialog->priv->config));
libgimp: rename "Save|Load Defaults" buttons in GimpProcedureDialog. 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.
2021-01-08 04:59:59 +08:00
dialog->priv->load_settings_button = button;
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
libgimp: rename "Save|Load Defaults" buttons in GimpProcedureDialog. 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.
2021-01-08 04:59:59 +08:00
button = gtk_button_new_with_mnemonic (_("_Save Settings"));
gtk_widget_set_tooltip_text (button, _("Store current settings for later reuse"));
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
gimp_procedure_dialog_check_mnemonic (GIMP_PROCEDURE_DIALOG (dialog), button, NULL, "save-defaults");
gtk_box_pack_start (GTK_BOX (hbox), button, FALSE, FALSE, 0);
gtk_widget_show (button);
g_signal_connect (button, "clicked",
G_CALLBACK (gimp_procedure_dialog_save_defaults),
dialog);
}
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
static void
gimp_procedure_dialog_dispose (GObject *object)
{
GimpProcedureDialog *dialog = GIMP_PROCEDURE_DIALOG (object);
g_clear_object (&dialog->priv->procedure);
g_clear_object (&dialog->priv->config);
libgimp: improve handling of procedure default values a lot 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".
2019-09-27 01:06:17 +08:00
g_clear_object (&dialog->priv->initial_config);
g_clear_pointer (&dialog->priv->reset_popover, gtk_widget_destroy);
libgimp: mnemonic duplicate verification in GimpProcedureDialog. 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.
2020-11-20 08:29:08 +08:00
g_clear_pointer (&dialog->priv->widgets, g_hash_table_destroy);
g_clear_pointer (&dialog->priv->mnemonics, g_hash_table_destroy);
g_clear_pointer (&dialog->priv->core_mnemonics, g_hash_table_destroy);
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
libgimp: new gimp_procedure_dialog_set_sensitive(). 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.
2021-04-07 02:10:46 +08:00
g_clear_pointer (&dialog->priv->sensitive_data, g_hash_table_destroy);
libgimp: improve design and usability of generated procedure dialog. - 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.
2020-11-06 00:46:02 +08:00
g_clear_object (&dialog->priv->label_group);
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
G_OBJECT_CLASS (parent_class)->dispose (object);
}
static void
gimp_procedure_dialog_set_property (GObject *object,
guint property_id,
const GValue *value,
GParamSpec *pspec)
{
GimpProcedureDialog *dialog = GIMP_PROCEDURE_DIALOG (object);
switch (property_id)
{
case PROP_PROCEDURE:
dialog->priv->procedure = g_value_dup_object (value);
break;
case PROP_CONFIG:
dialog->priv->config = g_value_dup_object (value);
libgimp: improve handling of procedure default values a lot 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".
2019-09-27 01:06:17 +08:00
if (dialog->priv->config)
dialog->priv->initial_config =
gimp_config_duplicate (GIMP_CONFIG (dialog->priv->config));
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
break;
libgimp: have gimp_procedure_dialog_new() behave like g_object_new(). 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.
2021-08-04 01:35:50 +08:00
case PROP_TITLE:
{
GtkWidget *bogus = NULL;
const gchar *title;
title = g_value_get_string (value);
if (title == NULL)
{
/* Use the procedure menu label, but remove mnemonic
* underscore. Ugly yet must reliable way as GTK does not
* expose a function to do this from a string (and better
* not to copy-paste the internal function from GTK code).
*/
bogus = gtk_label_new (NULL);
gtk_label_set_markup_with_mnemonic (GTK_LABEL (g_object_ref_sink (bogus)),
gimp_procedure_get_menu_label (dialog->priv->procedure));
title = gtk_label_get_text (GTK_LABEL (bogus));
}
if (title != NULL)
gtk_window_set_title (GTK_WINDOW (dialog), title);
g_clear_object (&bogus);
}
break;
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
break;
}
}
static void
gimp_procedure_dialog_get_property (GObject *object,
guint property_id,
GValue *value,
GParamSpec *pspec)
{
GimpProcedureDialog *dialog = GIMP_PROCEDURE_DIALOG (object);
switch (property_id)
{
case PROP_PROCEDURE:
g_value_set_object (value, dialog->priv->procedure);
break;
case PROP_CONFIG:
g_value_set_object (value, dialog->priv->config);
break;
libgimp: have gimp_procedure_dialog_new() behave like g_object_new(). 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.
2021-08-04 01:35:50 +08:00
case PROP_TITLE:
g_value_set_string (value,
gtk_window_get_title (GTK_WINDOW (dialog)));
break;
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
break;
}
}
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
static void
gimp_procedure_dialog_real_fill_list (GimpProcedureDialog *dialog,
GimpProcedure *procedure,
GimpProcedureConfig *config,
GList *properties)
{
GtkWidget *content_area;
GList *iter;
content_area = gtk_dialog_get_content_area (GTK_DIALOG (dialog));
for (iter = properties; iter; iter = iter->next)
{
GtkWidget *widget;
widget = gimp_procedure_dialog_get_widget (dialog, iter->data, G_TYPE_NONE);
if (widget)
{
gtk_box_pack_start (GTK_BOX (content_area), widget, TRUE, TRUE, 0);
gtk_widget_show (widget);
}
}
}
libgimp: add missing documentation for gimp_procedure_dialog_new(). This is important for introspection in particular with annotations.
2021-02-02 22:53:34 +08:00
/**
* gimp_procedure_dialog_new:
* @procedure: the associated #GimpProcedure.
* @config: a #GimpProcedureConfig from which properties will be
* turned into widgets.
libgimp: allow NULL title for gimp_procedure_dialog_new()… … 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).
2021-02-03 00:14:43 +08:00
* @title: (nullable): a dialog title.
libgimp: add missing documentation for gimp_procedure_dialog_new(). This is important for introspection in particular with annotations.
2021-02-02 22:53:34 +08:00
*
* Creates a new dialog for @procedure using widgets generated from
* properties of @config.
libgimp: allow NULL title for gimp_procedure_dialog_new()… … 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).
2021-02-03 00:14:43 +08:00
* A %NULL title will only be accepted if a menu label was set with
* gimp_procedure_set_menu_label() (this menu label will then be used as
* dialog title instead). If neither an explicit label nor a @procedure
* menu label was set, the call will fail.
libgimp: add missing documentation for gimp_procedure_dialog_new(). This is important for introspection in particular with annotations.
2021-02-02 22:53:34 +08:00
*
Issue #7106: GIMP 2.99.6 Python Script Fatal Error. 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.
2021-08-02 07:32:27 +08:00
* As for all #GtkWindow, the returned #GimpProcedureDialog object is
* owned by GTK and its initial reference is stored in an internal list
* of top-level windows. To delete the dialog, call
* gtk_widget_destroy().
*
* Returns: (transfer none): the newly created #GimpProcedureDialog.
libgimp: add missing documentation for gimp_procedure_dialog_new(). This is important for introspection in particular with annotations.
2021-02-02 22:53:34 +08:00
*/
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
GtkWidget *
gimp_procedure_dialog_new (GimpProcedure *procedure,
GimpProcedureConfig *config,
const gchar *title)
{
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
g_return_val_if_fail (GIMP_IS_PROCEDURE_CONFIG (config), NULL);
libgimp: add gimp_procedure_config_get_procedure() and use it in gimp_procedure_dialog_new() to make sure that the passed config was created by the passed procedure.
2019-09-21 01:33:50 +08:00
g_return_val_if_fail (gimp_procedure_config_get_procedure (config) ==
procedure, NULL);
libgimp: allow NULL title for gimp_procedure_dialog_new()… … 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).
2021-02-03 00:14:43 +08:00
g_return_val_if_fail (title != NULL || gimp_procedure_get_menu_label (procedure), NULL);
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
libgimp: have gimp_procedure_dialog_new() behave like g_object_new(). 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.
2021-08-04 01:35:50 +08:00
return g_object_new (GIMP_TYPE_PROCEDURE_DIALOG,
"procedure", procedure,
"config", config,
"title", title,
NULL);
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
}
libgimp: new gimp_procedure_dialog_set_ok_label() function. This allows to set a custom label for the OK button.
2023-06-15 09:56:00 +08:00
/**
* gimp_procedure_dialog_set_ok_label:
* @dialog: the associated #GimpProcedureDialog.
* @ok_label: a label to replace the OK button's text.
*
* Changes the "OK" button's label of @dialog to @ok_label.
*/
void
gimp_procedure_dialog_set_ok_label (GimpProcedureDialog *dialog,
const gchar *ok_label)
{
if (ok_label == NULL)
{
GimpProcedure *procedure = dialog->priv->procedure;
if (GIMP_IS_LOAD_PROCEDURE (procedure))
ok_label = _("_Open");
else if (GIMP_IS_SAVE_PROCEDURE (procedure))
ok_label = _("_Export");
else
ok_label = _("_OK");
}
gtk_button_set_label (GTK_BUTTON (dialog->priv->ok_button), ok_label);
gimp_procedure_dialog_check_mnemonic (GIMP_PROCEDURE_DIALOG (dialog),
dialog->priv->ok_button, NULL, "ok");
}
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
/**
* gimp_procedure_dialog_get_widget:
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
* @dialog: the associated #GimpProcedureDialog.
* @property: name of the property to build a widget for. It must be
* a property of the #GimpProcedure @dialog has been
* created for.
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
* @widget_type: alternative widget type. %G_TYPE_NONE will create the
* default type of widget for the associated property
* type.
*
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
* Creates a new #GtkWidget for @property according to the property
* type. The following types are possible:
*
Issue #7301: default GimpProcedureDialog widget for string property… … has no label. Now fixed with the new GimpLabelEntry created in the previous commit.
2022-02-17 04:44:09 +08:00
* - %G_TYPE_PARAM_BOOLEAN:
* * %GTK_TYPE_CHECK_BUTTON (default)
* * %GTK_TYPE_SWITCH
* - %G_TYPE_PARAM_INT or %G_TYPE_PARAM_DOUBLE:
* * %GIMP_TYPE_LABEL_SPIN (default): a spin button with a label.
libgimp: new gimp_procedure_dialog_get_spin_scale() and support of… … %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.
2022-02-19 08:22:48 +08:00
* * %GIMP_TYPE_SCALE_ENTRY: a scale entry with label.
* * %GIMP_TYPE_SPIN_SCALE: a spin scale with label embedded.
Issue #7301: default GimpProcedureDialog widget for string property… … has no label. Now fixed with the new GimpLabelEntry created in the previous commit.
2022-02-17 04:44:09 +08:00
* * %GIMP_TYPE_SPIN_BUTTON: a spin button with no label.
* - %G_TYPE_PARAM_STRING:
* * %GIMP_TYPE_LABEL_ENTRY (default): an entry with a label.
* * %GTK_TYPE_ENTRY: an entry with no label.
* * %GTK_TYPE_TEXT_VIEW: a text view with no label.
app, libgimp*, plug-ins: GimpColorButton now space-invaded. The invasion extended to some core widgets too, in particular GimpColorPanel (a subclass of GimpColorButton). There was quite a lot of code depending on these widgets.
2023-11-24 22:35:50 +08:00
* - %GEGL_TYPE_COLOR:
libgimp: improves the support of GimpParamRGB properties. 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.
2022-02-18 04:33:39 +08:00
* * %GIMP_TYPE_LABEL_COLOR (default): a color button with a label.
* Please use gimp_procedure_dialog_get_color_widget() for a
* non-editable color area with a label.
* * %GIMP_TYPE_COLOR_BUTTON: a color button with no label.
Issue #7301: default GimpProcedureDialog widget for string property… … has no label. Now fixed with the new GimpLabelEntry created in the previous commit.
2022-02-17 04:44:09 +08:00
* * %GIMP_TYPE_COLOR_AREA: a color area with no label.
libgimp, libgimpwidgets: supporting GFile properties in… … 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.
2022-06-17 21:08:16 +08:00
* - %G_TYPE_PARAM_FILE:
* * %GTK_FILE_CHOOSER_BUTTON (default): generic file chooser button
* in %GTK_FILE_CHOOSER_ACTION_OPEN mode. Please use
* gimp_procedure_dialog_get_file_chooser() to create buttons in
* other modes.
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
*
* If the @widget_type is not supported for the actual type of
* @property, the function will fail. To keep the default, set to
* %G_TYPE_NONE.
*
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
* If a widget has already been created for this procedure, it will be
* returned instead (even if with a different @widget_type).
*
* Returns: (transfer none): the #GtkWidget representing @property. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_get_widget (GimpProcedureDialog *dialog,
const gchar *property,
GType widget_type)
{
libgimp: new gimp_procedure_dialog_set_sensitive(). 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.
2021-04-07 02:10:46 +08:00
GtkWidget *widget = NULL;
GtkWidget *label = NULL;
GimpProcedureDialogSensitiveData *binding;
GParamSpec *pspec;
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
g_return_val_if_fail (property != NULL, NULL);
/* First check if it already exists. */
widget = g_hash_table_lookup (dialog->priv->widgets, property);
if (widget)
return widget;
pspec = g_object_class_find_property (G_OBJECT_GET_CLASS (dialog->priv->config),
property);
if (! pspec)
{
g_warning ("%s: parameter %s does not exist.",
G_STRFUNC, property);
return NULL;
}
if (G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_BOOLEAN)
{
if (widget_type == G_TYPE_NONE || widget_type == GTK_TYPE_CHECK_BUTTON)
widget = gimp_prop_check_button_new (G_OBJECT (dialog->priv->config),
property,
libgimp: procedure's arguments labels are now localized plug-in side. 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.
2022-07-05 20:02:10 +08:00
g_param_spec_get_nick (pspec));
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
else if (widget_type == GTK_TYPE_SWITCH)
libgimp: also size prop switch widget's label as GimpLabeled's labels. To get nice rendering with labels and edit widgets aligned, add the prop switch label into the same size group.
2020-11-14 03:24:08 +08:00
widget = gimp_prop_switch_new (G_OBJECT (dialog->priv->config),
property,
libgimp: procedure's arguments labels are now localized plug-in side. 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.
2022-07-05 20:02:10 +08:00
g_param_spec_get_nick (pspec),
libgimp: also size prop switch widget's label as GimpLabeled's labels. To get nice rendering with labels and edit widgets aligned, add the prop switch label into the same size group.
2020-11-14 03:24:08 +08:00
&label, NULL);
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
}
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
else if (G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_INT ||
G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_DOUBLE)
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
{
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
gdouble minimum;
gdouble maximum;
gdouble step = 0.0;
gdouble page = 0.0;
gint digits = 0;
if (G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_INT)
{
GParamSpecInt *pspecint = (GParamSpecInt *) pspec;
minimum = (gdouble) pspecint->minimum;
maximum = (gdouble) pspecint->maximum;
}
else /* G_TYPE_PARAM_DOUBLE */
{
GParamSpecDouble *pspecdouble = (GParamSpecDouble *) pspec;
minimum = pspecdouble->minimum;
maximum = pspecdouble->maximum;
}
libgimp, libgimpbase, libgimpwidgets: new gimp_range_estimate_settings() 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.
2020-11-25 08:16:34 +08:00
gimp_range_estimate_settings (minimum, maximum, &step, &page, &digits);
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
libgimp: improve design and usability of generated procedure dialog. - 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.
2020-11-06 00:46:02 +08:00
if (widget_type == G_TYPE_NONE || widget_type == GIMP_TYPE_LABEL_SPIN)
{
widget = gimp_prop_label_spin_new (G_OBJECT (dialog->priv->config),
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
property, digits);
libgimp: improve design and usability of generated procedure dialog. - 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.
2020-11-06 00:46:02 +08:00
}
else if (widget_type == GIMP_TYPE_SCALE_ENTRY)
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
{
widget = gimp_prop_scale_entry_new (G_OBJECT (dialog->priv->config),
property,
libgimp: procedure's arguments labels are now localized plug-in side. 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.
2022-07-05 20:02:10 +08:00
g_param_spec_get_nick (pspec),
libgimp, libgimpwidgets: fix gimp_prop_scale_entry_new() for integer… … properties. Also a forgotten fix in a call of this function in GimpProcedureDialog.
2020-11-26 07:27:43 +08:00
1.0, FALSE, 0.0, 0.0);
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
}
libgimp: new gimp_procedure_dialog_get_spin_scale() and support of… … %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.
2022-02-19 08:22:48 +08:00
else if (widget_type == GIMP_TYPE_SPIN_SCALE)
{
widget = gimp_prop_spin_scale_new (G_OBJECT (dialog->priv->config),
property, step, page, digits);
}
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
else if (widget_type == GIMP_TYPE_SPIN_BUTTON)
{
libgimp: improve design and usability of generated procedure dialog. - 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.
2020-11-06 00:46:02 +08:00
/* Just some spin button without label. */
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
widget = gimp_prop_spin_button_new (G_OBJECT (dialog->priv->config),
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
property, step, page, digits);
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
}
}
else if (G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_STRING)
{
Issue #7301: default GimpProcedureDialog widget for string property… … has no label. Now fixed with the new GimpLabelEntry created in the previous commit.
2022-02-17 04:44:09 +08:00
if (widget_type == G_TYPE_NONE || widget_type == GIMP_TYPE_LABEL_ENTRY)
{
widget = gimp_prop_label_entry_new (G_OBJECT (dialog->priv->config),
property, -1);
}
else if (widget_type == GTK_TYPE_TEXT_VIEW)
libgimp: some more functions to GimpProcedureDialog. 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.
2020-11-14 07:21:46 +08:00
{
GtkTextBuffer *buffer;
Issue #7301: default GimpProcedureDialog widget for string property… … has no label. Now fixed with the new GimpLabelEntry created in the previous commit.
2022-02-17 04:44:09 +08:00
/* Text view with no label. */
libgimp: some more functions to GimpProcedureDialog. 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.
2020-11-14 07:21:46 +08:00
buffer = gimp_prop_text_buffer_new (G_OBJECT (dialog->priv->config),
property, -1);
widget = gtk_text_view_new_with_buffer (buffer);
libgimp: bug fixes and design improvements for generated widgets.
2020-11-20 07:06:27 +08:00
gtk_text_view_set_top_margin (GTK_TEXT_VIEW (widget), 3);
gtk_text_view_set_bottom_margin (GTK_TEXT_VIEW (widget), 3);
gtk_text_view_set_left_margin (GTK_TEXT_VIEW (widget), 3);
gtk_text_view_set_right_margin (GTK_TEXT_VIEW (widget), 3);
libgimp: some more functions to GimpProcedureDialog. 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.
2020-11-14 07:21:46 +08:00
g_object_unref (buffer);
}
else if (widget_type == GTK_TYPE_ENTRY)
{
Issue #7301: default GimpProcedureDialog widget for string property… … has no label. Now fixed with the new GimpLabelEntry created in the previous commit.
2022-02-17 04:44:09 +08:00
/* Entry with no label. */
libgimp: some more functions to GimpProcedureDialog. 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.
2020-11-14 07:21:46 +08:00
widget = gimp_prop_entry_new (G_OBJECT (dialog->priv->config),
property, -1);
}
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
}
app, libgimp*, pdb, plug-ins: GimpContext is now using only GeglColor. - app: gimp_context_get_(foreground|background)() are now returning a GeglColor. - libgimp: PDB functions named similarly in libgimp are returning a newly allocated GeglColor too. - A few other PDB functions (the ones using these functions) were updated and their signature changed to use GeglColor too, when relevant. Plug-ins which use any of the changed libgimp functions were fixed. - GimpContext: signals "(foreground|background)-changed" are now passing a GeglColor. - libgimpconfig: new macro GIMP_CONFIG_PROP_COLOR using gegl_param_spec_color(). - GimpContext: properties "foreground" and "background" are now GeglParamColor properties. - app: All code interacting with GimpContext objects were updated to receive a GeglColor (that they may still convert, or no, to GimpRGB for now). - app: gimp_prop_gegl_color_button_new() was added as an alternative to gimp_prop_color_button_new() when the property is a GeglParamColor. Eventually the former should replace completely the latter. - libgimpwidgets: gimp_prop_color_area_new() now works on GeglParamColor properties only. - libgimp: gimp_procedure_dialog_get_widget() will generate a GimpColorArea for GeglTypeParamColor arguments.
2023-11-15 03:04:14 +08:00
else if (G_PARAM_SPEC_TYPE (pspec) == GEGL_TYPE_PARAM_COLOR)
{
app, libgimp*, plug-ins, tools: settings custom check colors now space-invaded. We pass 2 GeglColor through the wire now. Since it is passed very early (when sharing the configuration), I had some issues with initialization order of GEGL, and in particular when calling gegl_init() before gegl_config() inside _gimp_config(), I had a bunch of such criticals: > Plugin script-fu: GLib-GObject: CRITICAL: Two different plugins tried to register 'GeglOpPlugIn-transform-core' Anyway in the end, I store the passed colors as raw bytes and strings in the GPConfig object, and re-construct the GeglColor last minute in _gimp_config().
2023-11-21 04:38:11 +08:00
if (widget_type == G_TYPE_NONE || widget_type == GIMP_TYPE_LABEL_COLOR)
{
widget = gimp_prop_label_color_new (G_OBJECT (dialog->priv->config),
property, TRUE);
}
else if (widget_type == GIMP_TYPE_COLOR_AREA)
libgimp: improves the support of GimpParamRGB properties. 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.
2022-02-18 04:33:39 +08:00
{
widget = gimp_prop_color_area_new (G_OBJECT (dialog->priv->config),
property, 20, 20,
GIMP_COLOR_AREA_SMALL_CHECKS);
gtk_widget_set_vexpand (widget, FALSE);
gtk_widget_set_hexpand (widget, FALSE);
}
app, libgimp*, plug-ins: GimpColorButton now space-invaded. The invasion extended to some core widgets too, in particular GimpColorPanel (a subclass of GimpColorButton). There was quite a lot of code depending on these widgets.
2023-11-24 22:35:50 +08:00
else if (widget_type == GIMP_TYPE_COLOR_BUTTON)
{
widget = gimp_prop_color_select_new (G_OBJECT (dialog->priv->config),
property, 20, 20,
GIMP_COLOR_AREA_SMALL_CHECKS);
gtk_widget_set_vexpand (widget, FALSE);
gtk_widget_set_hexpand (widget, FALSE);
}
libgimp, libgimpwidgets: support of GimpRGB properties in… … 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).
2021-04-20 22:40:18 +08:00
}
libgimp, libgimpwidgets: supporting GFile properties in… … 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.
2022-06-17 21:08:16 +08:00
else if (G_IS_PARAM_SPEC_OBJECT (pspec) && pspec->value_type == G_TYPE_FILE)
{
widget = gimp_prop_file_chooser_button_new (G_OBJECT (dialog->priv->config),
property, NULL,
GTK_FILE_CHOOSER_ACTION_OPEN);
}
app, libgimp: new GimpChoice procedure argument. These will replace the int arguments used in place of enums. The problem of int arguments used as list of choices is that it makes calling PDB functions very opaque. This is especially bad when a list is long, so you constantly have to refer to the documentation to understand what a series of numbers mean in argument lists. And the second issue is that plug-in developers have to manually maintain a list of values both in the GUI and in the documentation string. This help text may get out-of-sync, may end up with missing values or whatnot. Also if it is used as tooltips, it makes for very weird tooltips in the graphical interface, with an overlong technical list of int-values mapping which should ideally only be made visible in the PDB procedure browser listing.
2023-08-03 05:55:33 +08:00
else if (G_PARAM_SPEC_TYPE (pspec) == GIMP_TYPE_PARAM_CHOICE)
{
widget = gimp_prop_choice_combo_box_new (G_OBJECT (dialog->priv->config), property);
gtk_widget_set_vexpand (widget, FALSE);
gtk_widget_set_hexpand (widget, TRUE);
widget = gimp_label_string_widget_new (g_param_spec_get_nick (pspec), widget);
}
libgimp: API refactor GUI for GimpResource 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
2022-10-16 03:11:05 +08:00
/* GimpResource subclasses */
/* FUTURE: title the chooser more specifically, with a prefix that is the nick of the property. */
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush 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
2022-09-06 07:28:35 +08:00
else if (G_IS_PARAM_SPEC_OBJECT (pspec) && pspec->value_type == GIMP_TYPE_BRUSH)
{
libgimp*, plug-ins: reorganize the resource property choosers. - Move the property widget functions for GimpResource properties into a new libgimp/gimppropwidgets.[ch] file. This mirrors the files libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types. - Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new(). - gimp_prop_chooser_factory() doesn't need to be public. - Add a label to GimpResourceSelectButton, make so that the gimp_prop_chooser_*_new() functions set the property nick to this label and add this label to the size group in GimpProcedureDialog.
2023-08-18 05:02:38 +08:00
widget = gimp_prop_brush_chooser_new (G_OBJECT (dialog->priv->config), property, _("Brush Chooser"));
libgimp: API refactor GUI for GimpResource 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
2022-10-16 03:11:05 +08:00
}
else if (G_IS_PARAM_SPEC_OBJECT (pspec) && pspec->value_type == GIMP_TYPE_FONT)
{
libgimp*, plug-ins: reorganize the resource property choosers. - Move the property widget functions for GimpResource properties into a new libgimp/gimppropwidgets.[ch] file. This mirrors the files libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types. - Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new(). - gimp_prop_chooser_factory() doesn't need to be public. - Add a label to GimpResourceSelectButton, make so that the gimp_prop_chooser_*_new() functions set the property nick to this label and add this label to the size group in GimpProcedureDialog.
2023-08-18 05:02:38 +08:00
widget = gimp_prop_font_chooser_new (G_OBJECT (dialog->priv->config), property, _("Font Chooser"));
libgimp: API refactor GUI for GimpResource 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
2022-10-16 03:11:05 +08:00
}
else if (G_IS_PARAM_SPEC_OBJECT (pspec) && pspec->value_type == GIMP_TYPE_GRADIENT)
{
libgimp*, plug-ins: reorganize the resource property choosers. - Move the property widget functions for GimpResource properties into a new libgimp/gimppropwidgets.[ch] file. This mirrors the files libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types. - Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new(). - gimp_prop_chooser_factory() doesn't need to be public. - Add a label to GimpResourceSelectButton, make so that the gimp_prop_chooser_*_new() functions set the property nick to this label and add this label to the size group in GimpProcedureDialog.
2023-08-18 05:02:38 +08:00
widget = gimp_prop_gradient_chooser_new (G_OBJECT (dialog->priv->config), property, _("Gradient Chooser"));
libgimp: API refactor GUI for GimpResource 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
2022-10-16 03:11:05 +08:00
}
else if (G_IS_PARAM_SPEC_OBJECT (pspec) && pspec->value_type == GIMP_TYPE_PALETTE)
{
libgimp*, plug-ins: reorganize the resource property choosers. - Move the property widget functions for GimpResource properties into a new libgimp/gimppropwidgets.[ch] file. This mirrors the files libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types. - Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new(). - gimp_prop_chooser_factory() doesn't need to be public. - Add a label to GimpResourceSelectButton, make so that the gimp_prop_chooser_*_new() functions set the property nick to this label and add this label to the size group in GimpProcedureDialog.
2023-08-18 05:02:38 +08:00
widget = gimp_prop_palette_chooser_new (G_OBJECT (dialog->priv->config), property, _("Palette Chooser"));
libgimp: API refactor GUI for GimpResource 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
2022-10-16 03:11:05 +08:00
}
else if (G_IS_PARAM_SPEC_OBJECT (pspec) && pspec->value_type == GIMP_TYPE_PATTERN)
{
libgimp*, plug-ins: reorganize the resource property choosers. - Move the property widget functions for GimpResource properties into a new libgimp/gimppropwidgets.[ch] file. This mirrors the files libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types. - Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new(). - gimp_prop_chooser_factory() doesn't need to be public. - Add a label to GimpResourceSelectButton, make so that the gimp_prop_chooser_*_new() functions set the property nick to this label and add this label to the size group in GimpProcedureDialog.
2023-08-18 05:02:38 +08:00
widget = gimp_prop_pattern_chooser_new (G_OBJECT (dialog->priv->config), property, _("Pattern Chooser"));
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush 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
2022-09-06 07:28:35 +08:00
}
app, libgimp, pdb: generate widgets for GIMP_PROC_ARG_LAYER|CHANNEL arguments. I am using the same GimpDrawableChooser with an additional drawable_type argument to only show the appropriate tab if we want to limit what can be chosen. None of our plug-ins actually use a GimpLayer or GimpChannel only arg so far, but if we have some day, or if some third-party plug-ins want to have such arg, now they quite easily can!
2023-09-06 04:39:04 +08:00
else if (G_IS_PARAM_SPEC_OBJECT (pspec) && (pspec->value_type == GIMP_TYPE_DRAWABLE ||
pspec->value_type == GIMP_TYPE_LAYER ||
pspec->value_type == GIMP_TYPE_CHANNEL))
libgimp: new GimpDrawableChooser widget, associated propwidget function and… … generation of such a widget for drawable arguments in PDB procedures.
2023-08-29 03:42:39 +08:00
{
widget = gimp_prop_drawable_chooser_new (G_OBJECT (dialog->priv->config), property, NULL);
}
Enhance GimpProcedureDialog have int combo widget for G_PARAM_SPEC_ENUM Resolves #8488
2022-08-13 19:34:17 +08:00
else if (G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_ENUM)
{
GimpIntStore *store;
store = (GimpIntStore *) gimp_enum_store_new (G_PARAM_SPEC_VALUE_TYPE (pspec));
widget = gimp_prop_int_combo_box_new (G_OBJECT (dialog->priv->config),
property,
store);
gtk_widget_set_vexpand (widget, FALSE);
gtk_widget_set_hexpand (widget, TRUE);
widget = gimp_label_int_widget_new (g_param_spec_get_nick (pspec),
widget);
}
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
else
{
Enhance GimpProcedureDialog have int combo widget for G_PARAM_SPEC_ENUM Resolves #8488
2022-08-13 19:34:17 +08:00
g_warning ("%s: parameter %s has non supported type %s for value type %s",
G_STRFUNC, property,
G_PARAM_SPEC_TYPE_NAME (pspec),
g_type_name (G_PARAM_SPEC_VALUE_TYPE (pspec)));
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
return NULL;
}
if (! widget)
{
g_warning ("%s: widget type %s not supported for parameter '%s' of type %s",
libgimp: mnemonic duplicate verification in GimpProcedureDialog. 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.
2020-11-20 08:29:08 +08:00
G_STRFUNC, g_type_name (widget_type),
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
property, G_PARAM_SPEC_TYPE_NAME (pspec));
return NULL;
}
libgimp: tooltip added to all widgets in GimpProcedureDialog Appropriate tooltip is displayed for all widgets in GimpProcedureDialog.
2021-06-18 02:13:08 +08:00
else
libgimp: improve design and usability of generated procedure dialog. - 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.
2020-11-06 00:46:02 +08:00
{
libgimp: tooltip added to all widgets in GimpProcedureDialog Appropriate tooltip is displayed for all widgets in GimpProcedureDialog.
2021-06-18 02:13:08 +08:00
const gchar *tooltip = g_param_spec_get_blurb (pspec);
libgimp*, plug-ins: reorganize the resource property choosers. - Move the property widget functions for GimpResource properties into a new libgimp/gimppropwidgets.[ch] file. This mirrors the files libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types. - Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new(). - gimp_prop_chooser_factory() doesn't need to be public. - Add a label to GimpResourceSelectButton, make so that the gimp_prop_chooser_*_new() functions set the property nick to this label and add this label to the size group in GimpProcedureDialog.
2023-08-18 05:02:38 +08:00
libgimp: tooltip added to all widgets in GimpProcedureDialog Appropriate tooltip is displayed for all widgets in GimpProcedureDialog.
2021-06-18 02:13:08 +08:00
if (tooltip)
gimp_help_set_help_data (widget, tooltip, NULL);
libgimp*, plug-ins: reorganize the resource property choosers. - Move the property widget functions for GimpResource properties into a new libgimp/gimppropwidgets.[ch] file. This mirrors the files libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types. - Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new(). - gimp_prop_chooser_factory() doesn't need to be public. - Add a label to GimpResourceSelectButton, make so that the gimp_prop_chooser_*_new() functions set the property nick to this label and add this label to the size group in GimpProcedureDialog.
2023-08-18 05:02:38 +08:00
if (label == NULL)
libgimp: tooltip added to all widgets in GimpProcedureDialog Appropriate tooltip is displayed for all widgets in GimpProcedureDialog.
2021-06-18 02:13:08 +08:00
{
libgimp*, plug-ins: reorganize the resource property choosers. - Move the property widget functions for GimpResource properties into a new libgimp/gimppropwidgets.[ch] file. This mirrors the files libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types. - Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new(). - gimp_prop_chooser_factory() doesn't need to be public. - Add a label to GimpResourceSelectButton, make so that the gimp_prop_chooser_*_new() functions set the property nick to this label and add this label to the size group in GimpProcedureDialog.
2023-08-18 05:02:38 +08:00
if (GIMP_IS_LABELED (widget))
libgimp: tooltip added to all widgets in GimpProcedureDialog Appropriate tooltip is displayed for all widgets in GimpProcedureDialog.
2021-06-18 02:13:08 +08:00
label = gimp_labeled_get_label (GIMP_LABELED (widget));
libgimp: rename Gimp*SelectButton widgets to Gimp*Chooser. This name was really irking me because it's not a button (anymore? Maybe it used to be just a button). Depending on the specific widget, it will have several sub-widgets, including a label. And it can theoretically even be something else than a button. So let's just rename these widgets with the more generic "chooser" name.
2023-08-19 07:22:09 +08:00
else if (GIMP_IS_RESOURCE_CHOOSER (widget))
label = gimp_resource_chooser_get_label (GIMP_RESOURCE_CHOOSER (widget));
libgimp: new GimpDrawableChooser widget, associated propwidget function and… … generation of such a widget for drawable arguments in PDB procedures.
2023-08-29 03:42:39 +08:00
else if (GIMP_IS_DRAWABLE_CHOOSER (widget))
label = gimp_drawable_chooser_get_label (GIMP_DRAWABLE_CHOOSER (widget));
libgimp: tooltip added to all widgets in GimpProcedureDialog Appropriate tooltip is displayed for all widgets in GimpProcedureDialog.
2021-06-18 02:13:08 +08:00
}
libgimp*, plug-ins: reorganize the resource property choosers. - Move the property widget functions for GimpResource properties into a new libgimp/gimppropwidgets.[ch] file. This mirrors the files libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types. - Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new(). - gimp_prop_chooser_factory() doesn't need to be public. - Add a label to GimpResourceSelectButton, make so that the gimp_prop_chooser_*_new() functions set the property nick to this label and add this label to the size group in GimpProcedureDialog.
2023-08-18 05:02:38 +08:00
if (label != NULL)
gtk_size_group_add_widget (dialog->priv->label_group, label);
libgimp: improve design and usability of generated procedure dialog. - 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.
2020-11-06 00:46:02 +08:00
}
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
libgimp: new gimp_procedure_dialog_set_sensitive(). 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.
2021-04-07 02:10:46 +08:00
if ((binding = g_hash_table_lookup (dialog->priv->sensitive_data, property)))
{
if (binding->config)
{
g_object_bind_property (binding->config, binding->config_property,
widget, "sensitive",
G_BINDING_SYNC_CREATE |
(binding->config_invert ? G_BINDING_INVERT_BOOLEAN : 0));
}
else
{
gtk_widget_set_sensitive (widget, binding->sensitive);
}
g_hash_table_remove (dialog->priv->sensitive_data, property);
}
libgimp: mnemonic duplicate verification in GimpProcedureDialog. 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.
2020-11-20 08:29:08 +08:00
gimp_procedure_dialog_check_mnemonic (dialog, widget, property, NULL);
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
g_hash_table_insert (dialog->priv->widgets, g_strdup (property), widget);
libgimp: sink the floating references after adding them to hash table. 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().
2021-04-20 23:08:31 +08:00
if (g_object_is_floating (widget))
g_object_ref_sink (widget);
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
return widget;
}
libgimp, libgimpwidgets: support of GimpRGB properties in… … 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).
2021-04-20 22:40:18 +08:00
/**
* gimp_procedure_dialog_get_color_widget:
* @dialog: the associated #GimpProcedureDialog.
* @property: name of the #GimpRGB property to build a widget for. It
* must be a property of the #GimpProcedure @dialog has been
* created for.
* @editable: whether the color can be edited or is only for display.
* @type: the #GimpColorAreaType.
*
* Creates a new widget for @property which must necessarily be a
* #GimpRGB property.
* This must be used instead of gimp_procedure_dialog_get_widget() when
libgimp: improves the support of GimpParamRGB properties. 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.
2022-02-18 04:33:39 +08:00
* you want a #GimpLabelColor which is not customizable for an RGB
* property, or when to set a specific @type.
libgimp, libgimpwidgets: support of GimpRGB properties in… … 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).
2021-04-20 22:40:18 +08:00
*
* If a widget has already been created for this procedure, it will be
* returned instead (whatever its actual widget type).
*
libgimp: improves the support of GimpParamRGB properties. 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.
2022-02-18 04:33:39 +08:00
* Returns: (transfer none): a #GimpLabelColor representing @property.
libgimp, libgimpwidgets: support of GimpRGB properties in… … 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).
2021-04-20 22:40:18 +08:00
* The object belongs to @dialog and must not
* be freed.
*/
GtkWidget *
gimp_procedure_dialog_get_color_widget (GimpProcedureDialog *dialog,
const gchar *property,
gboolean editable,
GimpColorAreaType type)
{
GtkWidget *widget = NULL;
GParamSpec *pspec;
g_return_val_if_fail (property != NULL, NULL);
/* First check if it already exists. */
widget = g_hash_table_lookup (dialog->priv->widgets, property);
if (widget)
return widget;
pspec = g_object_class_find_property (G_OBJECT_GET_CLASS (dialog->priv->config),
property);
if (! pspec)
{
g_warning ("%s: parameter %s does not exist.",
G_STRFUNC, property);
return NULL;
}
if (G_PARAM_SPEC_TYPE (pspec) == GIMP_TYPE_PARAM_RGB)
{
libgimp: improves the support of GimpParamRGB properties. 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.
2022-02-18 04:33:39 +08:00
widget = gimp_prop_label_color_new (G_OBJECT (dialog->priv->config),
property, editable);
libgimp, libgimpwidgets: support of GimpRGB properties in… … 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).
2021-04-20 22:40:18 +08:00
gtk_widget_set_vexpand (widget, FALSE);
libgimp: improves the support of GimpParamRGB properties. 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.
2022-02-18 04:33:39 +08:00
gtk_widget_set_hexpand (widget, FALSE);
libgimp, libgimpwidgets: support of GimpRGB properties in… … 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).
2021-04-20 22:40:18 +08:00
}
if (! widget)
{
g_warning ("%s: parameter '%s' of type %s not suitable as color widget",
G_STRFUNC, property, G_PARAM_SPEC_TYPE_NAME (pspec));
return NULL;
}
else if (GIMP_IS_LABELED (widget))
{
libgimp: tooltip added to all widgets in GimpProcedureDialog Appropriate tooltip is displayed for all widgets in GimpProcedureDialog.
2021-06-18 02:13:08 +08:00
GtkWidget *label = gimp_labeled_get_label (GIMP_LABELED (widget));
const gchar *tooltip = g_param_spec_get_blurb (pspec);
libgimp, libgimpwidgets: support of GimpRGB properties in… … 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).
2021-04-20 22:40:18 +08:00
gtk_size_group_add_widget (dialog->priv->label_group, label);
libgimp: tooltip added to all widgets in GimpProcedureDialog Appropriate tooltip is displayed for all widgets in GimpProcedureDialog.
2021-06-18 02:13:08 +08:00
if (tooltip)
gimp_help_set_help_data (label, tooltip, NULL);
libgimp, libgimpwidgets: support of GimpRGB properties in… … 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).
2021-04-20 22:40:18 +08:00
}
libgimp: tooltip added to all widgets in GimpProcedureDialog Appropriate tooltip is displayed for all widgets in GimpProcedureDialog.
2021-06-18 02:13:08 +08:00
libgimp, libgimpwidgets: support of GimpRGB properties in… … 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).
2021-04-20 22:40:18 +08:00
gimp_procedure_dialog_check_mnemonic (dialog, widget, property, NULL);
g_hash_table_insert (dialog->priv->widgets, g_strdup (property), widget);
libgimp: sink the floating references after adding them to hash table. 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().
2021-04-20 23:08:31 +08:00
if (g_object_is_floating (widget))
g_object_ref_sink (widget);
libgimp, libgimpwidgets: support of GimpRGB properties in… … 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).
2021-04-20 22:40:18 +08:00
return widget;
}
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
/**
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
* gimp_procedure_dialog_get_int_combo:
* @dialog: the associated #GimpProcedureDialog.
* @property: name of the int property to build a combo for. It must be
* a property of the #GimpProcedure @dialog has been created
* for.
libgimp, libgimpwidgets: more consistent API for widgets using a… … 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.
2022-06-17 23:50:18 +08:00
* @store: (transfer full): the #GimpIntStore which will be used.
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
*
* Creates a new #GimpLabelIntWidget for @property which must
* necessarily be an integer or boolean property.
* This must be used instead of gimp_procedure_dialog_get_widget() when
* you want to create a combo box from an integer property.
*
* If a widget has already been created for this procedure, it will be
* returned instead (whatever its actual widget type).
*
* Returns: (transfer none): the #GtkWidget representing @property. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_get_int_combo (GimpProcedureDialog *dialog,
const gchar *property,
GimpIntStore *store)
{
GtkWidget *widget = NULL;
GParamSpec *pspec;
libgimp, libgimpwidgets: more consistent API for widgets using a… … 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.
2022-06-17 23:50:18 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE_DIALOG (dialog), NULL);
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
g_return_val_if_fail (property != NULL, NULL);
libgimp, libgimpwidgets: more consistent API for widgets using a… … 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.
2022-06-17 23:50:18 +08:00
g_return_val_if_fail (GIMP_IS_INT_STORE (store), NULL);
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
/* First check if it already exists. */
widget = g_hash_table_lookup (dialog->priv->widgets, property);
if (widget)
libgimp, libgimpwidgets: more consistent API for widgets using a… … 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.
2022-06-17 23:50:18 +08:00
{
g_object_unref (store);
return widget;
}
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
pspec = g_object_class_find_property (G_OBJECT_GET_CLASS (dialog->priv->config),
property);
if (! pspec)
{
libgimp, libgimpwidgets: more consistent API for widgets using a… … 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.
2022-06-17 23:50:18 +08:00
g_warning ("%s: parameter %s does not exist.", G_STRFUNC, property);
g_object_unref (store);
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
return NULL;
}
if (G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_BOOLEAN ||
G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_INT)
{
widget = gimp_prop_int_combo_box_new (G_OBJECT (dialog->priv->config),
property, store);
gtk_widget_set_vexpand (widget, FALSE);
gtk_widget_set_hexpand (widget, TRUE);
libgimp: procedure's arguments labels are now localized plug-in side. 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.
2022-07-05 20:02:10 +08:00
widget = gimp_label_int_widget_new (g_param_spec_get_nick (pspec),
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
widget);
}
libgimp, libgimpwidgets: more consistent API for widgets using a… … 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.
2022-06-17 23:50:18 +08:00
g_object_unref (store);
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
if (! widget)
{
g_warning ("%s: parameter '%s' of type %s not suitable as GimpIntComboBox",
G_STRFUNC, property, G_PARAM_SPEC_TYPE_NAME (pspec));
return NULL;
}
libgimp: tooltip added to all widgets in GimpProcedureDialog Appropriate tooltip is displayed for all widgets in GimpProcedureDialog.
2021-06-18 02:13:08 +08:00
else
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
{
libgimp: tooltip added to all widgets in GimpProcedureDialog Appropriate tooltip is displayed for all widgets in GimpProcedureDialog.
2021-06-18 02:13:08 +08:00
const gchar *tooltip = g_param_spec_get_blurb (pspec);
if (tooltip)
gimp_help_set_help_data (widget, tooltip, NULL);
if (GIMP_IS_LABELED (widget))
{
GtkWidget *label = gimp_labeled_get_label (GIMP_LABELED (widget));
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
libgimp: tooltip added to all widgets in GimpProcedureDialog Appropriate tooltip is displayed for all widgets in GimpProcedureDialog.
2021-06-18 02:13:08 +08:00
gtk_size_group_add_widget (dialog->priv->label_group, label);
}
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
}
libgimp: mnemonic duplicate verification in GimpProcedureDialog. 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.
2020-11-20 08:29:08 +08:00
gimp_procedure_dialog_check_mnemonic (dialog, widget, property, NULL);
libgimp: new gimp_procedure_dialog_get_int_radio(). This allows to create a GimpIntRadioFrame from an int property.
2022-06-11 05:12:55 +08:00
g_hash_table_insert (dialog->priv->widgets, g_strdup (property), widget);
if (g_object_is_floating (widget))
g_object_ref_sink (widget);
return widget;
}
/**
* gimp_procedure_dialog_get_int_radio:
* @dialog: the associated #GimpProcedureDialog.
* @property: name of the int property to build radio buttons for. It
* must be a property of the #GimpProcedure @dialog has been
* created for.
libgimp, libgimpwidgets: more consistent API for widgets using a… … 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.
2022-06-17 23:50:18 +08:00
* @store: (transfer full): the #GimpIntStore which will be used.
libgimp: new gimp_procedure_dialog_get_int_radio(). This allows to create a GimpIntRadioFrame from an int property.
2022-06-11 05:12:55 +08:00
*
* Creates a new #GimpLabelIntRadioFrame for @property which must
* necessarily be an integer, enum or boolean property.
* This must be used instead of gimp_procedure_dialog_get_widget() when
* you want to create a group of %GtkRadioButton-s from an integer
* property.
*
* If a widget has already been created for this procedure, it will be
* returned instead (whatever its actual widget type).
*
* Returns: (transfer none): the #GtkWidget representing @property. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_get_int_radio (GimpProcedureDialog *dialog,
const gchar *property,
GimpIntStore *store)
{
GtkWidget *widget = NULL;
GParamSpec *pspec;
libgimp, libgimpwidgets: more consistent API for widgets using a… … 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.
2022-06-17 23:50:18 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE_DIALOG (dialog), NULL);
libgimp: new gimp_procedure_dialog_get_int_radio(). This allows to create a GimpIntRadioFrame from an int property.
2022-06-11 05:12:55 +08:00
g_return_val_if_fail (property != NULL, NULL);
libgimp, libgimpwidgets: more consistent API for widgets using a… … 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.
2022-06-17 23:50:18 +08:00
g_return_val_if_fail (GIMP_IS_INT_STORE (store), NULL);
libgimp: new gimp_procedure_dialog_get_int_radio(). This allows to create a GimpIntRadioFrame from an int property.
2022-06-11 05:12:55 +08:00
/* First check if it already exists. */
widget = g_hash_table_lookup (dialog->priv->widgets, property);
if (widget)
libgimp, libgimpwidgets: more consistent API for widgets using a… … 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.
2022-06-17 23:50:18 +08:00
{
g_object_unref (store);
return widget;
}
libgimp: new gimp_procedure_dialog_get_int_radio(). This allows to create a GimpIntRadioFrame from an int property.
2022-06-11 05:12:55 +08:00
pspec = g_object_class_find_property (G_OBJECT_GET_CLASS (dialog->priv->config),
property);
if (! pspec)
{
libgimp, libgimpwidgets: more consistent API for widgets using a… … 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.
2022-06-17 23:50:18 +08:00
g_warning ("%s: parameter %s does not exist.", G_STRFUNC, property);
g_object_unref (store);
libgimp: new gimp_procedure_dialog_get_int_radio(). This allows to create a GimpIntRadioFrame from an int property.
2022-06-11 05:12:55 +08:00
return NULL;
}
if (G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_BOOLEAN ||
G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_INT)
{
widget = gimp_prop_int_radio_frame_new (G_OBJECT (dialog->priv->config),
property, NULL, store);
gtk_widget_set_vexpand (widget, FALSE);
gtk_widget_set_hexpand (widget, TRUE);
}
libgimp, libgimpwidgets: more consistent API for widgets using a… … 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.
2022-06-17 23:50:18 +08:00
g_object_unref (store);
libgimp: new gimp_procedure_dialog_get_int_radio(). This allows to create a GimpIntRadioFrame from an int property.
2022-06-11 05:12:55 +08:00
if (! widget)
{
g_warning ("%s: parameter '%s' of type %s not suitable as GimpIntRadioFrame",
G_STRFUNC, property, G_PARAM_SPEC_TYPE_NAME (pspec));
return NULL;
}
gimp_procedure_dialog_check_mnemonic (dialog, widget, property, NULL);
libgimp: new gimp_procedure_dialog_get_spin_scale() and support of… … %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.
2022-02-19 08:22:48 +08:00
g_hash_table_insert (dialog->priv->widgets, g_strdup (property), widget);
if (g_object_is_floating (widget))
g_object_ref_sink (widget);
return widget;
}
/**
* gimp_procedure_dialog_get_spin_scale:
* @dialog: the associated #GimpProcedureDialog.
* @property: name of the int or double property to build a
* #GimpSpinScale for. It must be a property of the
* #GimpProcedure @dialog has been created for.
* @factor: a display factor for the range shown by the widget.
libgimp: Fix critical for int SpinScale API 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.
2023-04-15 04:44:00 +08:00
* It must be set to 1.0 for integer properties.
libgimp: new gimp_procedure_dialog_get_spin_scale() and support of… … %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.
2022-02-19 08:22:48 +08:00
*
* Creates a new #GimpSpinScale for @property which must necessarily be
* an integer or double property.
* This can be used instead of gimp_procedure_dialog_get_widget() in
* particular if you want to tweak the display factor. A typical example
* is showing a [0.0, 1.0] range as [0.0, 100.0] instead (@factor = 100.0).
*
* If a widget has already been created for this procedure, it will be
* returned instead (whatever its actual widget type).
*
* Returns: (transfer none): the #GtkWidget representing @property. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_get_spin_scale (GimpProcedureDialog *dialog,
const gchar *property,
gdouble factor)
{
GtkWidget *widget = NULL;
GParamSpec *pspec;
gdouble minimum;
gdouble maximum;
gdouble step = 0.0;
gdouble page = 0.0;
gint digits = 0;
g_return_val_if_fail (GIMP_IS_PROCEDURE_DIALOG (dialog), NULL);
g_return_val_if_fail (property != NULL, NULL);
pspec = g_object_class_find_property (G_OBJECT_GET_CLASS (dialog->priv->config),
property);
if (! pspec)
{
g_warning ("%s: parameter %s does not exist.",
G_STRFUNC, property);
return NULL;
}
libgimp: Fix critical for int SpinScale API 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.
2023-04-15 04:44:00 +08:00
g_return_val_if_fail (G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_DOUBLE ||
(G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_INT &&
factor == 1.0), NULL);
libgimp: new gimp_procedure_dialog_get_spin_scale() and support of… … %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.
2022-02-19 08:22:48 +08:00
/* First check if it already exists. */
widget = g_hash_table_lookup (dialog->priv->widgets, property);
if (widget)
return widget;
if (G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_INT)
{
GParamSpecInt *pspecint = (GParamSpecInt *) pspec;
minimum = (gdouble) pspecint->minimum;
maximum = (gdouble) pspecint->maximum;
}
else /* G_TYPE_PARAM_DOUBLE */
{
GParamSpecDouble *pspecdouble = (GParamSpecDouble *) pspec;
minimum = pspecdouble->minimum;
maximum = pspecdouble->maximum;
}
gimp_range_estimate_settings (minimum * factor, maximum * factor, &step, &page, &digits);
widget = gimp_prop_spin_scale_new (G_OBJECT (dialog->priv->config),
property, step, page, digits);
libgimp: Fix critical for int SpinScale API 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.
2023-04-15 04:44:00 +08:00
if (G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_DOUBLE)
gimp_prop_widget_set_factor (widget, factor, step, page, digits);
libgimp: new gimp_procedure_dialog_get_spin_scale() and support of… … %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.
2022-02-19 08:22:48 +08:00
gimp_procedure_dialog_check_mnemonic (dialog, widget, property, NULL);
libgimp: new gimp_procedure_dialog_get_scale_entry() function. 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.
2020-11-25 19:25:59 +08:00
g_hash_table_insert (dialog->priv->widgets, g_strdup (property), widget);
libgimp: sink the floating references after adding them to hash table. 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().
2021-04-20 23:08:31 +08:00
if (g_object_is_floating (widget))
g_object_ref_sink (widget);
libgimp: new gimp_procedure_dialog_get_scale_entry() function. 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.
2020-11-25 19:25:59 +08:00
return widget;
}
/**
* gimp_procedure_dialog_get_scale_entry:
* @dialog: the associated #GimpProcedureDialog.
* @property: name of the int property to build a combo for. It must be
* a property of the #GimpProcedure @dialog has been created
* for.
* @factor: a display factor for the range shown by the widget.
*
* Creates a new #GimpScaleEntry for @property which must necessarily be
* an integer or double property.
* This can be used instead of gimp_procedure_dialog_get_widget() in
* particular if you want to tweak the display factor. A typical example
* is showing a [0.0, 1.0] range as [0.0, 100.0] instead (@factor = 100.0).
*
* If a widget has already been created for this procedure, it will be
* returned instead (whatever its actual widget type).
*
* Returns: (transfer none): the #GtkWidget representing @property. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_get_scale_entry (GimpProcedureDialog *dialog,
const gchar *property,
gdouble factor)
{
GtkWidget *widget = NULL;
GParamSpec *pspec;
g_return_val_if_fail (GIMP_IS_PROCEDURE_DIALOG (dialog), NULL);
g_return_val_if_fail (property != NULL, NULL);
pspec = g_object_class_find_property (G_OBJECT_GET_CLASS (dialog->priv->config),
property);
if (! pspec)
{
g_warning ("%s: parameter %s does not exist.",
G_STRFUNC, property);
return NULL;
}
g_return_val_if_fail (G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_INT ||
G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_DOUBLE, NULL);
/* First check if it already exists. */
widget = g_hash_table_lookup (dialog->priv->widgets, property);
if (widget)
return widget;
widget = gimp_prop_scale_entry_new (G_OBJECT (dialog->priv->config),
property,
libgimp: procedure's arguments labels are now localized plug-in side. 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.
2022-07-05 20:02:10 +08:00
g_param_spec_get_nick (pspec),
libgimp: new gimp_procedure_dialog_get_scale_entry() function. 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.
2020-11-25 19:25:59 +08:00
factor, FALSE, 0.0, 0.0);
gtk_size_group_add_widget (dialog->priv->label_group,
gimp_labeled_get_label (GIMP_LABELED (widget)));
gimp_procedure_dialog_check_mnemonic (dialog, widget, property, NULL);
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
g_hash_table_insert (dialog->priv->widgets, g_strdup (property), widget);
libgimp: sink the floating references after adding them to hash table. 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().
2021-04-20 23:08:31 +08:00
if (g_object_is_floating (widget))
g_object_ref_sink (widget);
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
return widget;
}
libgimp: new gimp_procedure_get_size_entry () This allows plug-in developers to create GimpSizeEntry widgets with the procedure dialog API.
2023-04-06 11:35:19 +08:00
/**
* gimp_procedure_dialog_get_size_entry:
* @dialog: the associated #GimpProcedureDialog.
* @property: name of the int property to build an entry for.
* It must be a property of the #GimpProcedure @dialog
* has been created for.
* @property_is_pixel: when %TRUE, the property value is in pixels,
* and in the selected unit otherwise.
* @unit_property: name of unit property.
* @unit_format: a printf-like unit-format string used for unit
* labels.
* @update_policy: how the automatic pixel <-> real-world-unit
* calculations should be done.
* @resolution: the resolution (in dpi) for the field.
*
* Creates a new #GimpSizeEntry for @property which must necessarily be
* an integer or double property. The associated @unit_property must be
* a GimpUnit or integer property.
*
* If a widget has already been created for this procedure, it will be
* returned instead (whatever its actual widget type).
*
* Returns: (transfer none): the #GtkWidget representing @property. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_get_size_entry (GimpProcedureDialog *dialog,
const gchar *property,
gboolean property_is_pixel,
const gchar *unit_property,
const gchar *unit_format,
GimpSizeEntryUpdatePolicy update_policy,
gdouble resolution)
{
GtkWidget *widget = NULL;
GtkWidget *label = NULL;
GtkSizeGroup *group;
GParamSpec *pspec;
GParamSpec *pspec_unit;
g_return_val_if_fail (GIMP_IS_PROCEDURE_DIALOG (dialog), NULL);
g_return_val_if_fail (property != NULL, NULL);
g_return_val_if_fail (unit_property != NULL, NULL);
pspec = g_object_class_find_property (G_OBJECT_GET_CLASS (dialog->priv->config),
property);
pspec_unit = g_object_class_find_property (G_OBJECT_GET_CLASS (dialog->priv->config),
unit_property);
if (! pspec)
{
g_warning ("%s: parameter %s does not exist.",
G_STRFUNC, property);
return NULL;
}
if (! pspec_unit)
{
g_warning ("%s: unit parameter %s does not exist.",
G_STRFUNC, unit_property);
return NULL;
}
g_return_val_if_fail (G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_INT ||
G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_DOUBLE, NULL);
g_return_val_if_fail (G_PARAM_SPEC_TYPE (pspec_unit) == GIMP_TYPE_PARAM_UNIT, NULL);
/* First check if it already exists. */
widget = g_hash_table_lookup (dialog->priv->widgets, property);
if (widget)
return widget;
widget = gimp_prop_size_entry_new (G_OBJECT (dialog->priv->config), property,
property_is_pixel, unit_property,
unit_format, update_policy, resolution);
/* Add label */
label = gimp_size_entry_attach_label (GIMP_SIZE_ENTRY (widget),
g_param_spec_get_nick (pspec), 1, 0, 0.0);
gtk_widget_set_margin_end (label, 6);
group = gtk_size_group_new (GTK_SIZE_GROUP_HORIZONTAL);
gtk_size_group_add_widget (group, label);
g_object_unref (group);
g_hash_table_insert (dialog->priv->widgets, g_strdup (property), widget);
if (g_object_is_floating (widget))
g_object_ref_sink (widget);
return widget;
}
libgimp: new gimp_procedure_dialog_get_preview_from_drawable() function. This allows plug-in developers to create GimpPreviewDrawable widgets with the procedure dialog API.
2024-02-03 20:03:32 +08:00
/**
* gimp_procedure_dialog_get_drawable_preview:
* @dialog: the #GimpProcedureDialog.
* @preview_id: the ID of #GimpDrawablePreview.
* @drawable: the #GimpDrawable.
*
* Gets or creates a new #GimpDrawablePreview for @drawable.
* If a widget with the @preview_id has already been created for
* this procedure, it will be returned instead.
*
* The @preview_id ID can later be used together with property names
* to be packed in other containers or inside @dialog itself.
* Returns: (transfer none): the #GtkWidget representing @preview_id. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_get_drawable_preview (GimpProcedureDialog *dialog,
const gchar *preview_id,
GimpDrawable *drawable)
{
GtkWidget *w = g_hash_table_lookup (dialog->priv->widgets, preview_id);
if (w != NULL)
{
g_warning ("%s: preview_from_drawable identifier '%s' was already configured.",
G_STRFUNC, preview_id);
return w;
}
w = gimp_drawable_preview_new_from_drawable (drawable);
g_hash_table_insert (dialog->priv->widgets, g_strdup (preview_id), w);
if (g_object_is_floating (w))
g_object_ref_sink (w);
return w;
}
libgimp: some more functions to GimpProcedureDialog. 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.
2020-11-14 07:21:46 +08:00
/**
* gimp_procedure_dialog_get_label:
libgimp, plug-ins: enhance gimp_procedure_dialog_get_label() with markup and… … mnemonic abilities.
2023-07-18 06:06:26 +08:00
* @dialog: the #GimpProcedureDialog.
* @label_id: the label for the #GtkLabel.
* @text: the text for the label.
* @is_markup: whether @text is formatted with Pango markup.
* @with_mnemonic: whether @text contains a mnemonic character.
libgimp: some more functions to GimpProcedureDialog. 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.
2020-11-14 07:21:46 +08:00
*
* Creates a new #GtkLabel with @text. It can be useful for packing
* textual information in between property settings.
*
libgimp: add ability to sync a label to a string property of a procedure. Now gimp_procedure_dialog_get_label() can work both with an existing property ID or a new property ID. In the former case, it will simply sync the label with the procedure argument, which will make it easy to update the label contents. In the latter case, it just initialize with the provided text.
2023-07-22 09:08:42 +08:00
* If @label_id is an existing string property of the #GimpProcedureConfig
* associated to @dialog, then it will sync to the property value. In this case,
* @text should be %NULL.
*
* If @label_id is a unique ID which is neither the name of a property of the
* #GimpProcedureConfig associated to @dialog, nor is it the ID of any
* previously created label or container, it will be initialized to @text. This
* ID can later be used together with property names to be packed in other
libgimp: some more functions to GimpProcedureDialog. 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.
2020-11-14 07:21:46 +08:00
* containers or inside @dialog itself.
*
* Returns: (transfer none): the #GtkWidget representing @label_id. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_get_label (GimpProcedureDialog *dialog,
const gchar *label_id,
libgimp, plug-ins: enhance gimp_procedure_dialog_get_label() with markup and… … mnemonic abilities.
2023-07-18 06:06:26 +08:00
const gchar *text,
gboolean is_markup,
gboolean with_mnemonic)
libgimp: some more functions to GimpProcedureDialog. 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.
2020-11-14 07:21:46 +08:00
{
libgimp: add ability to sync a label to a string property of a procedure. Now gimp_procedure_dialog_get_label() can work both with an existing property ID or a new property ID. In the former case, it will simply sync the label with the procedure argument, which will make it easy to update the label contents. In the latter case, it just initialize with the provided text.
2023-07-22 09:08:42 +08:00
GtkWidget *label;
GParamSpec *pspec;
libgimp: some more functions to GimpProcedureDialog. 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.
2020-11-14 07:21:46 +08:00
g_return_val_if_fail (label_id != NULL, NULL);
libgimp: add ability to sync a label to a string property of a procedure. Now gimp_procedure_dialog_get_label() can work both with an existing property ID or a new property ID. In the former case, it will simply sync the label with the procedure argument, which will make it easy to update the label contents. In the latter case, it just initialize with the provided text.
2023-07-22 09:08:42 +08:00
pspec = g_object_class_find_property (G_OBJECT_GET_CLASS (dialog->priv->config),
label_id);
if (pspec != NULL && G_PARAM_SPEC_TYPE (pspec) != G_TYPE_PARAM_STRING)
libgimp: some more functions to GimpProcedureDialog. 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.
2020-11-14 07:21:46 +08:00
{
libgimp: add ability to sync a label to a string property of a procedure. Now gimp_procedure_dialog_get_label() can work both with an existing property ID or a new property ID. In the former case, it will simply sync the label with the procedure argument, which will make it easy to update the label contents. In the latter case, it just initialize with the provided text.
2023-07-22 09:08:42 +08:00
g_warning ("%s: label identifier '%s' must either not already exist or "
"be an existing string property.",
libgimp: some more functions to GimpProcedureDialog. 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.
2020-11-14 07:21:46 +08:00
G_STRFUNC, label_id);
return NULL;
}
if ((label = g_hash_table_lookup (dialog->priv->widgets, label_id)))
{
g_warning ("%s: label identifier '%s' was already configured.",
G_STRFUNC, label_id);
return label;
}
libgimp, plug-ins: enhance gimp_procedure_dialog_get_label() with markup and… … mnemonic abilities.
2023-07-18 06:06:26 +08:00
label = gtk_label_new (NULL);
libgimp: add ability to sync a label to a string property of a procedure. Now gimp_procedure_dialog_get_label() can work both with an existing property ID or a new property ID. In the former case, it will simply sync the label with the procedure argument, which will make it easy to update the label contents. In the latter case, it just initialize with the provided text.
2023-07-22 09:08:42 +08:00
g_object_set (label,
"use-markup", is_markup,
"use-underline", with_mnemonic,
NULL);
if (pspec != NULL)
g_object_bind_property (dialog->priv->config, label_id,
label, "label",
G_BINDING_BIDIRECTIONAL | G_BINDING_SYNC_CREATE);
libgimp, plug-ins: enhance gimp_procedure_dialog_get_label() with markup and… … mnemonic abilities.
2023-07-18 06:06:26 +08:00
else
libgimp: add ability to sync a label to a string property of a procedure. Now gimp_procedure_dialog_get_label() can work both with an existing property ID or a new property ID. In the former case, it will simply sync the label with the procedure argument, which will make it easy to update the label contents. In the latter case, it just initialize with the provided text.
2023-07-22 09:08:42 +08:00
g_object_set (label, "label", text, NULL);
libgimp, plug-ins: enhance gimp_procedure_dialog_get_label() with markup and… … mnemonic abilities.
2023-07-18 06:06:26 +08:00
libgimp: some more functions to GimpProcedureDialog. 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.
2020-11-14 07:21:46 +08:00
g_hash_table_insert (dialog->priv->widgets, g_strdup (label_id), label);
libgimp: sink the floating references after adding them to hash table. 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().
2021-04-20 23:08:31 +08:00
if (g_object_is_floating (label))
g_object_ref_sink (label);
libgimp: some more functions to GimpProcedureDialog. 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.
2020-11-14 07:21:46 +08:00
return label;
}
libgimp, libgimpwidgets: supporting GFile properties in… … 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.
2022-06-17 21:08:16 +08:00
/**
* gimp_procedure_dialog_get_file_chooser:
* @dialog: the associated #GimpProcedureDialog.
* @property: name of the %GimpParamConfigPath or %GParamObject of value
* type %GFile property to build a #GtkFileChooserButton for.
* It must be a property of the #GimpProcedure @dialog has
* been created for.
* @action: The open mode for the widget.
*
* Creates a new %GtkFileChooserButton for @property which must
* necessarily be a config path or %GFile property.
* This can be used instead of gimp_procedure_dialog_get_widget() in
* particular if you want to create a button in non-open modes (i.e. to
* save files, and select or create folders).
*
* If a widget has already been created for this procedure, it will be
* returned instead (whatever its actual widget type).
*
* Returns: (transfer none): the #GtkWidget representing @property. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_get_file_chooser (GimpProcedureDialog *dialog,
const gchar *property,
GtkFileChooserAction action)
{
GtkWidget *widget = NULL;
GParamSpec *pspec;
g_return_val_if_fail (GIMP_IS_PROCEDURE_DIALOG (dialog), NULL);
g_return_val_if_fail (property != NULL, NULL);
pspec = g_object_class_find_property (G_OBJECT_GET_CLASS (dialog->priv->config),
property);
if (! pspec)
{
g_warning ("%s: parameter %s does not exist.",
G_STRFUNC, property);
return NULL;
}
g_return_val_if_fail (GIMP_IS_PARAM_SPEC_CONFIG_PATH (pspec) ||
libgimp: fix #10730 gimp_procedure_dialog_get_file_chooser precondition wrong
2024-02-02 00:39:00 +08:00
(G_IS_PARAM_SPEC_OBJECT (pspec) && pspec->value_type == G_TYPE_FILE),
libgimp, libgimpwidgets: supporting GFile properties in… … 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.
2022-06-17 21:08:16 +08:00
NULL);
/* First check if it already exists. */
widget = g_hash_table_lookup (dialog->priv->widgets, property);
if (widget)
return widget;
widget = gimp_prop_file_chooser_button_new (G_OBJECT (dialog->priv->config),
property, NULL, action);
/* TODO: make is a file chooser with label. */
/*gtk_size_group_add_widget (dialog->priv->label_group,
gimp_labeled_get_label (GIMP_LABELED (widget)));
gimp_procedure_dialog_check_mnemonic (dialog, widget, property, NULL);*/
g_hash_table_insert (dialog->priv->widgets, g_strdup (property), widget);
if (g_object_is_floating (widget))
g_object_ref_sink (widget);
return widget;
}
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
/**
* gimp_procedure_dialog_fill:
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
* @dialog: the #GimpProcedureDialog.
libgimp: gimp_procedure_dialog_fill() allows no properties listed. 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.
2021-04-06 00:51:33 +08:00
* @...: a %NULL-terminated list of property names.
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
*
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
* Populate @dialog with the widgets corresponding to every listed
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
* properties. If the list is empty, @dialog will be filled by the whole
* list of properties of the associated #GimpProcedure, in the defined
* order:
* |[<!-- language="C" -->
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
* gimp_procedure_dialog_fill (dialog, NULL);
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
* ]|
* Nevertheless if you only wish to display a partial list of
* properties, or if you wish to change the display order, then you have
* to give an explicit list:
* |[<!-- language="C" -->
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
* gimp_procedure_dialog_fill (dialog, "property-1", "property-2", NULL);
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
* ]|
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
*
* Note: you do not have to call gimp_procedure_dialog_get_widget() on
* every property before calling this function unless you want a given
* property to be represented by an alternative widget type. By default,
* each property will get a default representation according to its
* type.
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
*/
void
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
gimp_procedure_dialog_fill (GimpProcedureDialog *dialog,
...)
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
{
libgimp: gimp_procedure_dialog_fill() allows no properties listed. 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.
2021-04-06 00:51:33 +08:00
const gchar *prop_name;
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
GList *list = NULL;
va_list va_args;
g_return_if_fail (GIMP_IS_PROCEDURE_DIALOG (dialog));
libgimp: gimp_procedure_dialog_fill() allows no properties listed. 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.
2021-04-06 00:51:33 +08:00
va_start (va_args, dialog);
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
libgimp: gimp_procedure_dialog_fill() allows no properties listed. 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.
2021-04-06 00:51:33 +08:00
while ((prop_name = va_arg (va_args, const gchar *)))
list = g_list_prepend (list, (gpointer) prop_name);
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
libgimp: gimp_procedure_dialog_fill() allows no properties listed. 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.
2021-04-06 00:51:33 +08:00
va_end (va_args);
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
list = g_list_reverse (list);
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
gimp_procedure_dialog_fill_list (dialog, list);
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
if (list)
g_list_free (list);
}
/**
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
* gimp_procedure_dialog_fill_list: (rename-to gimp_procedure_dialog_fill)
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
* @dialog: the #GimpProcedureDialog.
* @properties: (nullable) (element-type gchar*): the list of property names.
*
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
* Populate @dialog with the widgets corresponding to every listed
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
* properties. If the list is %NULL, @dialog will be filled by the whole
* list of properties of the associated #GimpProcedure, in the defined
* order:
* |[<!-- language="C" -->
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
* gimp_procedure_dialog_fill_list (dialog, NULL);
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
* ]|
* Nevertheless if you only wish to display a partial list of
* properties, or if you wish to change the display order, then you have
* to give an explicit list:
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
* |[<!-- language="C" -->
* gimp_procedure_dialog_fill (dialog, "property-1", "property-2", NULL);
* ]|
*
* Note: you do not have to call gimp_procedure_dialog_get_widget() on
* every property before calling this function unless you want a given
* property to be represented by an alternative widget type. By default,
* each property will get a default representation according to its
* type.
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
*/
void
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
gimp_procedure_dialog_fill_list (GimpProcedureDialog *dialog,
GList *properties)
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
{
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
gboolean free_properties = FALSE;
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
if (! properties)
{
GParamSpec **pspecs;
guint n_pspecs;
libgimp*, plug-ins: fix some warnings
2021-05-25 04:36:31 +08:00
guint i;
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
pspecs = g_object_class_list_properties (G_OBJECT_GET_CLASS (dialog->priv->config),
&n_pspecs);
for (i = 0; i < n_pspecs; i++)
{
const gchar *prop_name;
GParamSpec *pspec = pspecs[i];
/* skip our own properties */
if (pspec->owner_type == GIMP_TYPE_PROCEDURE_CONFIG)
continue;
prop_name = g_param_spec_get_name (pspec);
properties = g_list_prepend (properties, (gpointer) prop_name);
}
properties = g_list_reverse (properties);
if (properties)
free_properties = TRUE;
libgimp: some memory leak fixed.
2023-07-21 05:59:05 +08:00
g_free (pspecs);
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
}
libgimp: new metadata support concept in GimpSaveProcedure and new… … 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.
2020-11-21 08:15:15 +08:00
GIMP_PROCEDURE_DIALOG_GET_CLASS (dialog)->fill_list (dialog,
dialog->priv->procedure,
dialog->priv->config,
properties);
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
if (free_properties)
g_list_free (properties);
}
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
/**
* gimp_procedure_dialog_fill_box:
* @dialog: the #GimpProcedureDialog.
* @container_id: a container identifier.
* @first_property: the first property name.
* @...: a %NULL-terminated list of other property names.
*
* Creates and populates a new #GtkBox with widgets corresponding to
* every listed properties. If the list is empty, the created box will
* be filled by the whole list of properties of the associated
* #GimpProcedure, in the defined order. This is similar of how
* gimp_procedure_dialog_fill() works except that it creates a new
* widget which is not inside @dialog itself.
*
* The @container_id must be a unique ID which is neither the name of a
* property of the #GimpProcedureConfig associated to @dialog, nor is it
* the ID of any previously created container. This ID can later be used
* together with property names to be packed in other containers or
* inside @dialog itself.
*
* Returns: (transfer none): the #GtkBox representing @property. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_fill_box (GimpProcedureDialog *dialog,
const gchar *container_id,
const gchar *first_property,
...)
{
const gchar *prop_name = first_property;
GtkWidget *box;
GList *list = NULL;
va_list va_args;
g_return_val_if_fail (GIMP_IS_PROCEDURE_DIALOG (dialog), NULL);
g_return_val_if_fail (container_id != NULL, NULL);
if (first_property)
{
va_start (va_args, first_property);
do
list = g_list_prepend (list, (gpointer) prop_name);
while ((prop_name = va_arg (va_args, const gchar *)));
va_end (va_args);
}
list = g_list_reverse (list);
box = gimp_procedure_dialog_fill_box_list (dialog, container_id, list);
if (list)
g_list_free (list);
return box;
}
/**
* gimp_procedure_dialog_fill_box_list: (rename-to gimp_procedure_dialog_fill_box)
* @dialog: the #GimpProcedureDialog.
* @container_id: a container identifier.
* @properties: (nullable) (element-type gchar*): the list of property names.
*
* Creates and populates a new #GtkBox with widgets corresponding to
* every listed @properties. If the list is empty, the created box will
* be filled by the whole list of properties of the associated
* #GimpProcedure, in the defined order. This is similar of how
* gimp_procedure_dialog_fill() works except that it creates a new
* widget which is not inside @dialog itself.
*
* The @container_id must be a unique ID which is neither the name of a
* property of the #GimpProcedureConfig associated to @dialog, nor is it
* the ID of any previously created container. This ID can later be used
* together with property names to be packed in other containers or
* inside @dialog itself.
*
* Returns: (transfer none): the #GtkBox representing @property. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_fill_box_list (GimpProcedureDialog *dialog,
const gchar *container_id,
GList *properties)
{
g_return_val_if_fail (container_id != NULL, NULL);
return gimp_procedure_dialog_fill_container_list (dialog, container_id,
GTK_CONTAINER (gtk_box_new (GTK_ORIENTATION_VERTICAL, 2)),
properties);
}
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
/**
* gimp_procedure_dialog_fill_flowbox:
* @dialog: the #GimpProcedureDialog.
* @container_id: a container identifier.
* @first_property: the first property name.
* @...: a %NULL-terminated list of other property names.
*
* Creates and populates a new #GtkFlowBox with widgets corresponding to
* every listed properties. If the list is empty, the created flowbox
* will be filled by the whole list of properties of the associated
* #GimpProcedure, in the defined order. This is similar of how
* gimp_procedure_dialog_fill() works except that it creates a new
* widget which is not inside @dialog itself.
*
* The @container_id must be a unique ID which is neither the name of a
* property of the #GimpProcedureConfig associated to @dialog, nor is it
* the ID of any previously created container. This ID can later be used
* together with property names to be packed in other containers or
* inside @dialog itself.
*
* Returns: (transfer none): the #GtkFlowBox representing @property. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_fill_flowbox (GimpProcedureDialog *dialog,
const gchar *container_id,
const gchar *first_property,
...)
{
const gchar *prop_name = first_property;
GtkWidget *flowbox;
GList *list = NULL;
va_list va_args;
g_return_val_if_fail (GIMP_IS_PROCEDURE_DIALOG (dialog), NULL);
g_return_val_if_fail (container_id != NULL, NULL);
if (first_property)
{
va_start (va_args, first_property);
do
list = g_list_prepend (list, (gpointer) prop_name);
while ((prop_name = va_arg (va_args, const gchar *)));
va_end (va_args);
}
list = g_list_reverse (list);
flowbox = gimp_procedure_dialog_fill_flowbox_list (dialog, container_id, list);
if (list)
g_list_free (list);
return flowbox;
}
/**
* gimp_procedure_dialog_fill_flowbox_list: (rename-to gimp_procedure_dialog_fill_flowbox)
* @dialog: the #GimpProcedureDialog.
* @container_id: a container identifier.
* @properties: (nullable) (element-type gchar*): the list of property names.
*
* Creates and populates a new #GtkFlowBox with widgets corresponding to
* every listed @properties. If the list is empty, the created flowbox
* will be filled by the whole list of properties of the associated
* #GimpProcedure, in the defined order. This is similar of how
* gimp_procedure_dialog_fill() works except that it creates a new
* widget which is not inside @dialog itself.
*
* The @container_id must be a unique ID which is neither the name of a
* property of the #GimpProcedureConfig associated to @dialog, nor is it
* the ID of any previously created container. This ID can later be used
* together with property names to be packed in other containers or
* inside @dialog itself.
*
* Returns: (transfer none): the #GtkFlowBox representing @property. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_fill_flowbox_list (GimpProcedureDialog *dialog,
const gchar *container_id,
GList *properties)
{
g_return_val_if_fail (container_id != NULL, NULL);
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
return gimp_procedure_dialog_fill_container_list (dialog, container_id,
GTK_CONTAINER (gtk_flow_box_new ()),
properties);
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
}
libgimp: some more functions to GimpProcedureDialog. 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.
2020-11-14 07:21:46 +08:00
/**
* gimp_procedure_dialog_fill_frame:
* @dialog: the #GimpProcedureDialog.
* @container_id: a container identifier.
* @title_id: (nullable): the identifier for the title widget.
* @invert_title: whether to use the opposite value of @title_id if it
* represents a boolean widget.
* @contents_id: (nullable): the identifier for the contents.
*
* Creates a new #GtkFrame and packs @title_id as its title and
* @contents_id as its child.
* If @title_id represents a boolean property, its value will be used to
* renders @contents_id sensitive or not. If @invert_title is TRUE, then
* sensitivity binding is inverted.
*
* The @container_id must be a unique ID which is neither the name of a
* property of the #GimpProcedureConfig associated to @dialog, nor is it
* the ID of any previously created container. This ID can later be used
* together with property names to be packed in other containers or
* inside @dialog itself.
*
* Returns: (transfer none): the #GtkWidget representing @container_id. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_fill_frame (GimpProcedureDialog *dialog,
const gchar *container_id,
const gchar *title_id,
gboolean invert_title,
const gchar *contents_id)
{
GtkWidget *frame;
GtkWidget *contents = NULL;
GtkWidget *title = NULL;
g_return_val_if_fail (container_id != NULL, NULL);
if (g_object_class_find_property (G_OBJECT_GET_CLASS (dialog->priv->config),
container_id))
{
g_warning ("%s: frame identifier '%s' cannot be an existing property name.",
G_STRFUNC, container_id);
return NULL;
}
if ((frame = g_hash_table_lookup (dialog->priv->widgets, container_id)))
{
g_warning ("%s: frame identifier '%s' was already configured.",
G_STRFUNC, container_id);
return frame;
}
libgimp: bug fixes and design improvements for generated widgets.
2020-11-20 07:06:27 +08:00
frame = gimp_frame_new (NULL);
libgimp: some more functions to GimpProcedureDialog. 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.
2020-11-14 07:21:46 +08:00
if (contents_id)
{
contents = gimp_procedure_dialog_get_widget (dialog, contents_id, G_TYPE_NONE);
if (! contents)
{
g_warning ("%s: no property or configured widget with identifier '%s'.",
G_STRFUNC, contents_id);
return frame;
}
gtk_container_add (GTK_CONTAINER (frame), contents);
gtk_widget_show (contents);
}
if (title_id)
{
title = gimp_procedure_dialog_get_widget (dialog, title_id, G_TYPE_NONE);
if (! title)
{
g_warning ("%s: no property or configured widget with identifier '%s'.",
G_STRFUNC, title_id);
return frame;
}
gtk_frame_set_label_widget (GTK_FRAME (frame), title);
gtk_widget_show (title);
if (contents && (GTK_IS_CHECK_BUTTON (title) || GTK_IS_SWITCH (title)))
{
GBindingFlags flags = G_BINDING_SYNC_CREATE;
if (invert_title)
flags |= G_BINDING_INVERT_BOOLEAN;
g_object_bind_property (title, "active",
contents, "sensitive",
flags);
}
}
g_hash_table_insert (dialog->priv->widgets, g_strdup (container_id), frame);
libgimp: sink the floating references after adding them to hash table. 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().
2021-04-20 23:08:31 +08:00
if (g_object_is_floating (frame))
g_object_ref_sink (frame);
libgimp: some more functions to GimpProcedureDialog. 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.
2020-11-14 07:21:46 +08:00
return frame;
}
libgimp: new gimp_procedure_dialog_set_sensitive(). 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.
2021-04-07 02:10:46 +08:00
plug-in, libgimp: Fixes #6753: redesign of WebP Export dialog 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.
2021-06-18 01:38:56 +08:00
/**
* gimp_procedure_dialog_fill_expander:
* @dialog: the #GimpProcedureDialog.
* @container_id: a container identifier.
* @title_id: (nullable): the identifier for the title widget.
* @invert_title: whether to use the opposite value of @title_id if it
* represents a boolean widget.
* @contents_id: (nullable): the identifier for the contents.
*
* Creates a new #GtkExpander and packs @title_id as its title
* and @contents_id as content.
* If @title_id represents a boolean property, its value will be used to
* expand the #GtkExpander. If @invert_title is TRUE, then expand binding is
* inverted.
*
* The @container_id must be a unique ID which is neither the name of a
* property of the #GimpProcedureConfig associated to @dialog, nor is it
* the ID of any previously created container. This ID can later be used
* together with property names to be packed in other containers or
* inside @dialog itself.
*
* Returns: (transfer none): the #GtkWidget representing @container_id. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_fill_expander (GimpProcedureDialog *dialog,
const gchar *container_id,
const gchar *title_id,
gboolean invert_title,
const gchar *contents_id)
{
GtkWidget *expander;
GtkWidget *contents = NULL;
GtkWidget *title = NULL;
g_return_val_if_fail (container_id != NULL, NULL);
if (g_object_class_find_property (G_OBJECT_GET_CLASS (dialog->priv->config),
container_id))
{
g_warning ("%s: expander identifier '%s' cannot be an existing property name.",
G_STRFUNC, container_id);
return NULL;
}
if ((expander = g_hash_table_lookup (dialog->priv->widgets, container_id)))
{
g_warning ("%s: expander identifier '%s' was already configured.",
G_STRFUNC, container_id);
return expander;
}
expander = gtk_expander_new (NULL);
if (contents_id)
{
contents = gimp_procedure_dialog_get_widget (dialog, contents_id, G_TYPE_NONE);
if (! contents)
{
g_warning ("%s: no property or configured widget with identifier '%s'.",
G_STRFUNC, contents_id);
return expander;
}
gtk_container_add (GTK_CONTAINER (expander), contents);
gtk_widget_show (contents);
}
if (title_id)
{
title = gimp_procedure_dialog_get_widget (dialog, title_id, G_TYPE_NONE);
if (! title)
{
g_warning ("%s: no property or configured widget with identifier '%s'.",
G_STRFUNC, title_id);
return expander;
}
gtk_expander_set_label_widget (GTK_EXPANDER (expander), title);
gtk_expander_set_resize_toplevel (GTK_EXPANDER (expander), TRUE);
gtk_widget_show (title);
g_object_bind_property (title, "sensitive",
expander, "sensitive",
G_BINDING_SYNC_CREATE);
if (contents && (GTK_IS_CHECK_BUTTON (title) || GTK_IS_SWITCH (title)))
{
GBindingFlags flags = G_BINDING_SYNC_CREATE;
gboolean active;
/* Workaround for connecting check button state to expanded state of
* GtkExpander. This is required as GtkExpander do not pass click
* events to label widget.
* Please see https://bugzilla.gnome.org/show_bug.cgi?id=705971
*/
if (invert_title)
flags |= G_BINDING_INVERT_BOOLEAN;
g_object_get (title, "active", &active, NULL);
gtk_expander_set_expanded (GTK_EXPANDER (expander),
invert_title ? ! active : active);
g_object_bind_property (expander, "expanded",
title, "active",
flags);
}
}
g_hash_table_insert (dialog->priv->widgets, g_strdup (container_id), expander);
if (g_object_is_floating (expander))
g_object_ref_sink (expander);
return expander;
}
libgimp: new gimp_procedure_dialog_fill_scrolled_window() This allows plug-in developers to create GTKScrolledWindow with the procedure dialog API.
2023-03-31 21:55:59 +08:00
/**
* gimp_procedure_dialog_fill_scrolled_window:
* @dialog: the #GimpProcedureDialog.
* @container_id: a container identifier.
* @contents_id: The identifier for the contents.
*
* Creates and populates a new #GtkScrolledWindow with a widget corresponding
* to the declared content id.
*
* The @container_id must be a unique ID which is neither the name of a
* property of the #GimpProcedureConfig associated to @dialog, nor is it
* the ID of any previously created container. This ID can later be used
* together with property names to be packed in other containers or
* inside @dialog itself.
*
* Returns: (transfer none): the #GtkScrolledWindow representing @contents_id.
* The object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_fill_scrolled_window (GimpProcedureDialog *dialog,
const gchar *container_id,
const gchar *contents_id)
{
GtkWidget *scrolled_window;
GList *single_list = NULL;
g_return_val_if_fail (GIMP_IS_PROCEDURE_DIALOG (dialog), NULL);
g_return_val_if_fail (container_id != NULL, NULL);
/* GtkScrolledWindow can only have one child */
g_return_val_if_fail (contents_id != NULL, NULL);
single_list = g_list_prepend (single_list, (gpointer) contents_id);
scrolled_window =
gimp_procedure_dialog_fill_container_list (dialog, container_id,
GTK_CONTAINER (gtk_scrolled_window_new (NULL, NULL)),
single_list);
if (single_list)
g_list_free (single_list);
return scrolled_window;
}
libgimp: new gimp_procedure_dialog_fill_notebook*() functions.
2023-07-18 05:37:50 +08:00
/**
* gimp_procedure_dialog_fill_notebook:
* @dialog: the #GimpProcedureDialog.
* @container_id: a container identifier.
* @label_id: the first page's label.
* @page_id: the first page's contents.
* @...: a %NULL-terminated list of other property names.
*
* Creates and populates a new #GtkNotebook with widgets corresponding to every
* listed properties.
* This is similar of how gimp_procedure_dialog_fill() works except that it
* creates a new widget which is not inside @dialog itself.
*
* The @container_id must be a unique ID which is neither the name of a
* property of the #GimpProcedureConfig associated to @dialog, nor is it
* the ID of any previously created container. This ID can later be used
* together with property names to be packed in other containers or
* inside @dialog itself.
*
* Returns: (transfer none): the #GtkNotebook representing @property. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_fill_notebook (GimpProcedureDialog *dialog,
const gchar *container_id,
const gchar *label_id,
const gchar *page_id,
...)
{
GtkWidget *notebook;
GList *label_list = NULL;
GList *page_list = NULL;
va_list va_args;
g_return_val_if_fail (GIMP_IS_PROCEDURE_DIALOG (dialog), NULL);
g_return_val_if_fail (container_id != NULL, NULL);
g_return_val_if_fail (label_id != NULL && page_id != NULL, NULL);
va_start (va_args, page_id);
do
{
label_list = g_list_prepend (label_list, (gpointer) label_id);
page_list = g_list_prepend (page_list, (gpointer) page_id);
label_id = va_arg (va_args, const gchar *);
page_id = va_arg (va_args, const gchar *);
}
while (label_id != NULL && page_id != NULL);
va_end (va_args);
label_list = g_list_reverse (label_list);
page_list = g_list_reverse (page_list);
notebook = gimp_procedure_dialog_fill_notebook_list (dialog, container_id, label_list, page_list);
g_list_free (label_list);
g_list_free (page_list);
return notebook;
}
/**
* gimp_procedure_dialog_fill_notebook_list: (rename-to gimp_procedure_dialog_fill_notebook)
* @dialog: the #GimpProcedureDialog.
* @container_id: a container identifier.
* @label_list: (not nullable) (element-type gchar*): the list of label IDs.
* @page_list: (not nullable) (element-type gchar*): the list of page IDs.
*
* Creates and populates a new #GtkNotebook with widgets corresponding to every
* listed properties.
* This is similar of how gimp_procedure_dialog_fill_list() works except that it
* creates a new widget which is not inside @dialog itself.
*
* The @container_id must be a unique ID which is neither the name of a
* property of the #GimpProcedureConfig associated to @dialog, nor is it
* the ID of any previously created container. This ID can later be used
* together with property names to be packed in other containers or
* inside @dialog itself.
*
* Returns: (transfer none): the #GtkNotebook representing @property. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_fill_notebook_list (GimpProcedureDialog *dialog,
const gchar *container_id,
GList *label_list,
GList *page_list)
{
GtkWidget *notebook;
GList *iter_label = label_list;
GList *iter_page = page_list;
g_return_val_if_fail (container_id != NULL, NULL);
g_return_val_if_fail (g_list_length (label_list) > 0 &&
g_list_length (label_list) == g_list_length (page_list), NULL);
if (g_object_class_find_property (G_OBJECT_GET_CLASS (dialog->priv->config),
container_id))
{
g_warning ("%s: container identifier '%s' cannot be an existing property name.",
G_STRFUNC, container_id);
return NULL;
}
if (g_hash_table_lookup (dialog->priv->widgets, container_id))
{
g_warning ("%s: container identifier '%s' was already configured.",
G_STRFUNC, container_id);
return g_hash_table_lookup (dialog->priv->widgets, container_id);
}
notebook = gtk_notebook_new ();
g_object_ref_sink (notebook);
for (; iter_label; iter_label = iter_label->next, iter_page = iter_page->next)
{
GtkWidget *label;
GtkWidget *page;
label = gimp_procedure_dialog_get_widget (dialog, iter_label->data, G_TYPE_NONE);
page = gimp_procedure_dialog_get_widget (dialog, iter_page->data, G_TYPE_NONE);
if (label != NULL && page != NULL)
{
gtk_notebook_append_page (GTK_NOTEBOOK (notebook), page, label);
gtk_widget_show (label);
gtk_widget_show (page);
}
}
g_hash_table_insert (dialog->priv->widgets, g_strdup (container_id), notebook);
return notebook;
}
libgimp: new gimp_procedure_dialog_fill_scrolled_window() This allows plug-in developers to create GTKScrolledWindow with the procedure dialog API.
2023-03-31 21:55:59 +08:00
libgimp: new gimp_procedure_dialog_fill_paned() function.
2023-07-18 05:40:04 +08:00
/**
* gimp_procedure_dialog_fill_paned:
* @dialog: the #GimpProcedureDialog.
* @container_id: a container identifier.
* @child1_id: (nullable): the first child's ID.
* @child2_id: (nullable): the second child's ID.
*
* Creates and populates a new #GtkPaned containing widgets corresponding to
* @child1_id and @child2_id.
* This is similar of how gimp_procedure_dialog_fill() works except that it
* creates a new widget which is not inside @dialog itself.
*
* The @container_id must be a unique ID which is neither the name of a
* property of the #GimpProcedureConfig associated to @dialog, nor is it
* the ID of any previously created container. This ID can later be used
* together with property names to be packed in other containers or
* inside @dialog itself.
*
* Returns: (transfer none): the #GtkPaned representing @property. The
* object belongs to @dialog and must not be
* freed.
*/
GtkWidget *
gimp_procedure_dialog_fill_paned (GimpProcedureDialog *dialog,
const gchar *container_id,
GtkOrientation orientation,
const gchar *child1_id,
const gchar *child2_id)
{
GtkWidget *paned;
GtkWidget *child1;
GtkWidget *child2;
g_return_val_if_fail (container_id != NULL, NULL);
if (g_object_class_find_property (G_OBJECT_GET_CLASS (dialog->priv->config),
container_id))
{
g_warning ("%s: container identifier '%s' cannot be an existing property name.",
G_STRFUNC, container_id);
return NULL;
}
if (g_hash_table_lookup (dialog->priv->widgets, container_id))
{
g_warning ("%s: container identifier '%s' was already configured.",
G_STRFUNC, container_id);
return g_hash_table_lookup (dialog->priv->widgets, container_id);
}
paned = gtk_paned_new (orientation);
g_object_ref_sink (paned);
if (child1_id != NULL)
{
child1 = gimp_procedure_dialog_get_widget (dialog, child1_id, G_TYPE_NONE);
gtk_paned_pack1 (GTK_PANED (paned), child1, TRUE, FALSE);
gtk_widget_show (child1);
}
if (child2_id != NULL)
{
child2 = gimp_procedure_dialog_get_widget (dialog, child2_id, G_TYPE_NONE);
gtk_paned_pack2 (GTK_PANED (paned), child2, TRUE, FALSE);
gtk_widget_show (child2);
}
g_hash_table_insert (dialog->priv->widgets, g_strdup (container_id), paned);
return paned;
}
libgimp: new gimp_procedure_dialog_set_sensitive(). 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.
2021-04-07 02:10:46 +08:00
/**
* gimp_procedure_dialog_set_sensitive:
* @dialog: the #GimpProcedureDialog.
* @property: name of a property of the #GimpProcedure @dialog
* has been created for.
* @sensitive: whether the widget associated to @property should
* be sensitive.
* @config: (nullable): an optional config object.
* @config_property: (nullable): name of a property of @config.
* @config_invert: whether to negate the value of @config_property.
*
* Sets sensitivity of the widget associated to @property in @dialog. If
* @config is %NULL, then it is set to the value of @sensitive.
* Otherwise @sensitive is ignored and sensitivity is bound to the value
* of @config_property of @config (or the negation of this value
* if @config_reverse is %TRUE).
*/
void
gimp_procedure_dialog_set_sensitive (GimpProcedureDialog *dialog,
const gchar *property,
gboolean sensitive,
GObject *config,
const gchar *config_property,
gboolean config_invert)
{
GtkWidget *widget = NULL;
GParamSpec *pspec;
g_return_if_fail (GIMP_IS_PROCEDURE_DIALOG (dialog));
g_return_if_fail (property != NULL);
g_return_if_fail (config == NULL || config_property != NULL);
widget = g_hash_table_lookup (dialog->priv->widgets, property);
if (! widget)
{
pspec = g_object_class_find_property (G_OBJECT_GET_CLASS (dialog->priv->config),
property);
if (! pspec)
{
g_warning ("%s: parameter %s does not exist on the GimpProcedure.",
G_STRFUNC, property);
return;
}
}
if (config)
{
pspec = g_object_class_find_property (G_OBJECT_GET_CLASS (config),
config_property);
if (! pspec)
{
g_warning ("%s: parameter %s does not exist on the config object.",
G_STRFUNC, config_property);
return;
}
}
if (widget)
{
if (config)
{
g_object_bind_property (config, config_property,
widget, "sensitive",
G_BINDING_SYNC_CREATE | (config_invert ? G_BINDING_INVERT_BOOLEAN : 0));
}
else
{
gtk_widget_set_sensitive (widget, sensitive);
}
}
else
{
/* Set for later creation. */
GimpProcedureDialogSensitiveData *data;
data = g_slice_new0 (GimpProcedureDialogSensitiveData);
data->sensitive = sensitive;
if (config)
{
data->config = g_object_ref (config);
data->config_property = g_strdup (config_property);
data->config_invert = config_invert;
}
g_hash_table_insert (dialog->priv->sensitive_data, g_strdup (property), data);
}
}
libgimp: new function gimp_procedure_dialog_set_sensitive_if_in(). This function allows to change the sensitivity of a widget depending on the value of another property. We already had gimp_procedure_dialog_set_sensitive() except it was only syncing with a boolean property, whereas the new function can compare with any property type.
2023-06-15 09:31:42 +08:00
/**
* gimp_procedure_dialog_set_sensitive_if_in:
* @dialog: the #GimpProcedureDialog.
* @property: name of a property of the #GimpProcedure @dialog
* has been created for.
* @config: (nullable): an optional config object (if %NULL,
* @property's config will be used).
* @config_property: name of a property of @config.
* @values: (not nullable) (transfer full):
* an array of GValues which could be values of @config_property.
* @in_values: whether @property should be sensitive when @config_property
* is one of @values, or the opposite.
*
* Sets sensitivity of the widget associated to @property in @dialog if the
* value of @config_property in @config is equal to one of @values.
*
* If @config is %NULL, then the configuration object of @dialog is used.
*
* If @in_values is FALSE, then the widget is set sensitive if the value of
* @config_property is **not** in @values.
*/
void
gimp_procedure_dialog_set_sensitive_if_in (GimpProcedureDialog *dialog,
const gchar *property,
GObject *config,
const gchar *config_property,
GimpValueArray *values,
gboolean in_values)
{
GimpProcedureDialogSensitiveData2 *data;
GParamSpec *pspec;
gchar *signal_name;
g_return_if_fail (GIMP_IS_PROCEDURE_DIALOG (dialog));
g_return_if_fail (property != NULL);
g_return_if_fail (config_property != NULL);
g_return_if_fail (values != NULL);
pspec = g_object_class_find_property (G_OBJECT_GET_CLASS (dialog->priv->config),
property);
if (! pspec)
{
g_warning ("%s: parameter %s does not exist on the GimpProcedure.",
G_STRFUNC, property);
return;
}
if (! config)
config = G_OBJECT (dialog->priv->config);
pspec = g_object_class_find_property (G_OBJECT_GET_CLASS (config),
config_property);
if (! pspec)
{
g_warning ("%s: parameter %s does not exist on the config object.",
G_STRFUNC, config_property);
return;
}
data = g_new (GimpProcedureDialogSensitiveData2, 1);
data->dialog = dialog;
data->widget_property = g_strdup (property);
data->values = values;
data->in_values = in_values;
signal_name = g_strconcat ("notify::", config_property, NULL);
g_signal_connect_data (config, signal_name,
G_CALLBACK (gimp_procedure_dialog_set_sensitive_if_in_cb),
data,
(GClosureNotify) gimp_procedure_dialog_sensitive_cb_data_free,
0);
gimp_procedure_dialog_set_sensitive_if_in_cb (config, pspec, data);
g_free (signal_name);
}
libgimp, libgimpwidgets, plug-ins: improved GimpProcedureDialog API. - 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.
2020-11-14 04:26:14 +08:00
/**
* gimp_procedure_dialog_run:
* @dialog: the #GimpProcedureDialog.
*
* Show @dialog and only returns when the user finished interacting with
* it (either validating choices or canceling).
*
* Returns: %TRUE if the dialog was validated, %FALSE otherwise.
*/
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
gboolean
gimp_procedure_dialog_run (GimpProcedureDialog *dialog)
{
g_return_val_if_fail (GIMP_IS_PROCEDURE_DIALOG (dialog), FALSE);
while (TRUE)
{
gint response = gimp_dialog_run (GIMP_DIALOG (dialog));
if (response == RESPONSE_RESET)
{
libgimp: improve handling of procedure default values a lot 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".
2019-09-27 01:06:17 +08:00
if (! dialog->priv->reset_popover)
{
GtkWidget *button;
GtkWidget *vbox;
button = gtk_dialog_get_widget_for_response (GTK_DIALOG (dialog),
response);
dialog->priv->reset_popover = gtk_popover_new (button);
vbox = gtk_box_new (GTK_ORIENTATION_VERTICAL, 4);
gtk_container_set_border_width (GTK_CONTAINER (vbox), 4);
gtk_container_add (GTK_CONTAINER (dialog->priv->reset_popover),
vbox);
gtk_widget_show (vbox);
button = gtk_button_new_with_mnemonic (_("Reset to _Initial "
"Values"));
gtk_box_pack_start (GTK_BOX (vbox), button, FALSE, FALSE, 0);
gtk_widget_show (button);
g_signal_connect (button, "clicked",
G_CALLBACK (gimp_procedure_dialog_reset_initial),
dialog);
button = gtk_button_new_with_mnemonic (_("Reset to _Factory "
"Defaults"));
gtk_box_pack_start (GTK_BOX (vbox), button, FALSE, FALSE, 0);
gtk_widget_show (button);
g_signal_connect (button, "clicked",
G_CALLBACK (gimp_procedure_dialog_reset_factory),
dialog);
}
gtk_popover_popup (GTK_POPOVER (dialog->priv->reset_popover));
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-21 01:24:40 +08:00
}
else
{
return response == GTK_RESPONSE_OK;
}
}
}
libgimp: improve handling of procedure default values a lot 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".
2019-09-27 01:06:17 +08:00
/* private functions */
static void
gimp_procedure_dialog_reset_initial (GtkWidget *button,
GimpProcedureDialog *dialog)
{
gimp_config_copy (GIMP_CONFIG (dialog->priv->initial_config),
GIMP_CONFIG (dialog->priv->config),
0);
gtk_popover_popdown (GTK_POPOVER (dialog->priv->reset_popover));
}
static void
gimp_procedure_dialog_reset_factory (GtkWidget *button,
GimpProcedureDialog *dialog)
{
gimp_config_reset (GIMP_CONFIG (dialog->priv->config));
gtk_popover_popdown (GTK_POPOVER (dialog->priv->reset_popover));
}
static void
gimp_procedure_dialog_load_defaults (GtkWidget *button,
GimpProcedureDialog *dialog)
{
GError *error = NULL;
libgimp: export again gimp_procedure_config_*_default() functions. This partially revert some of the changes in commit 652a1b4388 because the Windows CI suddenly failed because of this (my local build on Linux didn't have any problem though) with: > /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_save_defaults': > /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2570:(.text+0x633): undefined reference to `_gimp_procedure_config_save_default' > /usr/bin/x86_64-w64-mingw32-ld: /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2576:(.text+0x644): undefined reference to `_gimp_procedure_config_has_default' > /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_load_defaults': > /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2549:(.text+0xa2f): undefined reference to `_gimp_procedure_config_load_default' > /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_constructed': > /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:368:(.text+0x11b1): undefined reference to `_gimp_procedure_config_has_default' This is because these functions are used not only inside libgimp but also across inside libgimpui. As a consequence, the build fails when linking libgimpui.
2023-10-16 05:20:44 +08:00
if (! gimp_procedure_config_load_default (dialog->priv->config, &error))
libgimp: improve handling of procedure default values a lot 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".
2019-09-27 01:06:17 +08:00
{
if (error)
{
g_printerr ("Loading default values from disk failed: %s\n",
error->message);
g_clear_error (&error);
}
else
{
g_printerr ("No default values found on disk\n");
}
}
}
static void
gimp_procedure_dialog_save_defaults (GtkWidget *button,
GimpProcedureDialog *dialog)
{
GError *error = NULL;
libgimp: export again gimp_procedure_config_*_default() functions. This partially revert some of the changes in commit 652a1b4388 because the Windows CI suddenly failed because of this (my local build on Linux didn't have any problem though) with: > /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_save_defaults': > /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2570:(.text+0x633): undefined reference to `_gimp_procedure_config_save_default' > /usr/bin/x86_64-w64-mingw32-ld: /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2576:(.text+0x644): undefined reference to `_gimp_procedure_config_has_default' > /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_load_defaults': > /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2549:(.text+0xa2f): undefined reference to `_gimp_procedure_config_load_default' > /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_constructed': > /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:368:(.text+0x11b1): undefined reference to `_gimp_procedure_config_has_default' This is because these functions are used not only inside libgimp but also across inside libgimpui. As a consequence, the build fails when linking libgimpui.
2023-10-16 05:20:44 +08:00
if (! gimp_procedure_config_save_default (dialog->priv->config, &error))
libgimp: improve handling of procedure default values a lot 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".
2019-09-27 01:06:17 +08:00
{
g_printerr ("Saving default values to disk failed: %s\n",
error->message);
g_clear_error (&error);
}
libgimp: rename "Save|Load Defaults" buttons in GimpProcedureDialog. 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.
2021-01-08 04:59:59 +08:00
gtk_widget_set_sensitive (dialog->priv->load_settings_button,
libgimp: export again gimp_procedure_config_*_default() functions. This partially revert some of the changes in commit 652a1b4388 because the Windows CI suddenly failed because of this (my local build on Linux didn't have any problem though) with: > /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_save_defaults': > /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2570:(.text+0x633): undefined reference to `_gimp_procedure_config_save_default' > /usr/bin/x86_64-w64-mingw32-ld: /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2576:(.text+0x644): undefined reference to `_gimp_procedure_config_has_default' > /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_load_defaults': > /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:2549:(.text+0xa2f): undefined reference to `_gimp_procedure_config_load_default' > /usr/bin/x86_64-w64-mingw32-ld: libgimp/libgimpui-3.0-0.dll.p/gimpproceduredialog.c.obj: in function `gimp_procedure_dialog_constructed': > /builds/GNOME/gimp/_build/../libgimp/gimpproceduredialog.c:368:(.text+0x11b1): undefined reference to `_gimp_procedure_config_has_default' This is because these functions are used not only inside libgimp but also across inside libgimpui. As a consequence, the build fails when linking libgimpui.
2023-10-16 05:20:44 +08:00
gimp_procedure_config_has_default (dialog->priv->config));
libgimp: improve handling of procedure default values a lot 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".
2019-09-27 01:06:17 +08:00
}
libgimp: add some first API to populate a GimpProcedureDialog. 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.
2020-11-03 05:42:17 +08:00
libgimp: mnemonic duplicate verification in GimpProcedureDialog. 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.
2020-11-20 08:29:08 +08:00
static gboolean
gimp_procedure_dialog_check_mnemonic (GimpProcedureDialog *dialog,
GtkWidget *widget,
const gchar *id,
const gchar *core_id)
{
GtkWidget *label = NULL;
gchar *duplicate;
gboolean success = TRUE;
guint mnemonic = GDK_KEY_VoidSymbol;
g_return_val_if_fail ((id && ! core_id) || (core_id && ! id), FALSE);
if (GIMP_IS_LABELED (widget))
{
label = gimp_labeled_get_label (GIMP_LABELED (widget));
}
libgimp: new GimpDrawableChooser widget, associated propwidget function and… … generation of such a widget for drawable arguments in PDB procedures.
2023-08-29 03:42:39 +08:00
else if (GIMP_IS_RESOURCE_CHOOSER (widget))
{
label = gimp_resource_chooser_get_label (GIMP_RESOURCE_CHOOSER (widget));
}
else if (GIMP_IS_DRAWABLE_CHOOSER (widget))
{
label = gimp_drawable_chooser_get_label (GIMP_DRAWABLE_CHOOSER (widget));
}
libgimp: improve gimp_procedure_dialog_check_mnemonic(). 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.
2020-12-30 20:31:16 +08:00
else
libgimp: mnemonic duplicate verification in GimpProcedureDialog. 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.
2020-11-20 08:29:08 +08:00
{
libgimp: improve gimp_procedure_dialog_check_mnemonic(). 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.
2020-12-30 20:31:16 +08:00
GList *labels = gtk_widget_list_mnemonic_labels (widget);
if (g_list_length (labels) >= 1)
{
if (g_list_length (labels) > 1)
g_printerr ("Procedure '%s': %d mnemonics for property %s. Too much?\n",
gimp_procedure_get_name (dialog->priv->procedure),
g_list_length (labels),
id ? id : core_id);
label = labels->data;
}
g_list_free (labels);
libgimp: mnemonic duplicate verification in GimpProcedureDialog. 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.
2020-11-20 08:29:08 +08:00
}
libgimpwidgets: new gimp_spin_scale_get_mnemonic_keyval() function. This solves part of #8524, for properties displaying as spin scale, which have a mnemonic, yet our code was not able to tell so.
2023-01-24 06:25:55 +08:00
if (label)
mnemonic = gtk_label_get_mnemonic_keyval (GTK_LABEL (label));
else if (GIMP_IS_SPIN_SCALE (widget))
mnemonic = gimp_spin_scale_get_mnemonic_keyval (GIMP_SPIN_SCALE (widget));
if (mnemonic != GDK_KEY_VoidSymbol)
libgimp: mnemonic duplicate verification in GimpProcedureDialog. 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.
2020-11-20 08:29:08 +08:00
{
duplicate = g_hash_table_lookup (dialog->priv->core_mnemonics, GINT_TO_POINTER (mnemonic));
if (duplicate && g_strcmp0 (duplicate, id ? id : core_id) != 0)
{
g_printerr ("Procedure '%s': duplicate mnemonic %s for label of property %s and dialog button %s\n",
gimp_procedure_get_name (dialog->priv->procedure),
gdk_keyval_name (mnemonic), id, duplicate);
success = FALSE;
}
if (success)
{
duplicate = g_hash_table_lookup (dialog->priv->mnemonics, GINT_TO_POINTER (mnemonic));
if (duplicate && g_strcmp0 (duplicate, id ? id : core_id) != 0)
{
g_printerr ("Procedure '%s': duplicate mnemonic %s for label of properties %s and %s\n",
gimp_procedure_get_name (dialog->priv->procedure),
gdk_keyval_name (mnemonic), id, duplicate);
success = FALSE;
}
else if (! duplicate)
{
if (id)
g_hash_table_insert (dialog->priv->mnemonics, GINT_TO_POINTER (mnemonic), g_strdup (id));
else
g_hash_table_insert (dialog->priv->core_mnemonics, GINT_TO_POINTER (mnemonic), g_strdup (core_id));
}
}
}
else
{
g_printerr ("Procedure '%s': no mnemonic for property %s\n",
libgimp: improve gimp_procedure_dialog_check_mnemonic(). 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.
2020-12-30 20:31:16 +08:00
gimp_procedure_get_name (dialog->priv->procedure),
id ? id : core_id);
libgimp: mnemonic duplicate verification in GimpProcedureDialog. 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.
2020-11-20 08:29:08 +08:00
success = FALSE;
}
return success;
}
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
/**
* gimp_procedure_dialog_fill_container_list:
libgimp: Add gtkdoc comments in gimpproceduredialog Although they're only used for a private function, gtk-doc still complains about the empty param docs, so let's just add something.
2021-01-02 20:00:37 +08:00
* @dialog: the #GimpProcedureDialog.
* @container_id: a container identifier.
* @container: (transfer full): The new container that should be used if none
* exists yet
* @properties: (nullable) (element-type gchar*): the list of property names.
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
*
Issue #6446: Typo fixes.
2021-02-24 19:33:03 +08:00
* A generic function to be used by various public functions
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
* gimp_procedure_dialog_fill_*_list(). Note in particular that
* @container is taken over by this function which may return it or not.
* @container is assumed to be a floating GtkContainer (i.e. newly
* created widget without a parent yet).
* If the object returns a different object (because @container_id
* already represents another widget) or %NULL, the function takes care
* of freeing @container. Calling code must therefore not reuse the
* pointer anymore.
*/
static GtkWidget *
gimp_procedure_dialog_fill_container_list (GimpProcedureDialog *dialog,
const gchar *container_id,
GtkContainer *container,
GList *properties)
{
libgimp: new GtkSizeGroup for widgets inside a container 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.
2021-06-18 02:11:15 +08:00
GList *iter;
gboolean free_properties = FALSE;
GtkSizeGroup *sz_group;
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
g_return_val_if_fail (container_id != NULL, NULL);
g_return_val_if_fail (GTK_IS_CONTAINER (container), NULL);
g_return_val_if_fail (g_object_is_floating (G_OBJECT (container)), NULL);
g_object_ref_sink (container);
if (g_object_class_find_property (G_OBJECT_GET_CLASS (dialog->priv->config),
container_id))
{
g_warning ("%s: container identifier '%s' cannot be an existing property name.",
G_STRFUNC, container_id);
g_object_unref (container);
return NULL;
}
if (g_hash_table_lookup (dialog->priv->widgets, container_id))
{
g_warning ("%s: container identifier '%s' was already configured.",
G_STRFUNC, container_id);
g_object_unref (container);
return g_hash_table_lookup (dialog->priv->widgets, container_id);
}
if (! properties)
{
GParamSpec **pspecs;
guint n_pspecs;
libgimp*, plug-ins: fix some warnings
2021-05-25 04:36:31 +08:00
guint i;
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
pspecs = g_object_class_list_properties (G_OBJECT_GET_CLASS (dialog->priv->config),
&n_pspecs);
for (i = 0; i < n_pspecs; i++)
{
const gchar *prop_name;
GParamSpec *pspec = pspecs[i];
/* skip our own properties */
if (pspec->owner_type == GIMP_TYPE_PROCEDURE_CONFIG)
continue;
prop_name = g_param_spec_get_name (pspec);
properties = g_list_prepend (properties, (gpointer) prop_name);
}
properties = g_list_reverse (properties);
if (properties)
free_properties = TRUE;
libgimp: some memory leak fixed.
2023-07-21 05:59:05 +08:00
g_free (pspecs);
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
}
libgimp: new GtkSizeGroup for widgets inside a container 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.
2021-06-18 02:11:15 +08:00
sz_group = gtk_size_group_new (GTK_SIZE_GROUP_HORIZONTAL);
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
for (iter = properties; iter; iter = iter->next)
{
GtkWidget *widget;
widget = gimp_procedure_dialog_get_widget (dialog, iter->data, G_TYPE_NONE);
if (widget)
{
gtk_container_add (container, widget);
libgimp: new GtkSizeGroup for widgets inside a container 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.
2021-06-18 02:11:15 +08:00
if (GIMP_IS_LABELED (widget))
{
GtkWidget *label = gimp_labeled_get_label (GIMP_LABELED (widget));
gtk_size_group_remove_widget (dialog->priv->label_group, label);
gtk_size_group_add_widget (sz_group, label);
}
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
gtk_widget_show (widget);
}
}
libgimp: do not leak dialog containers' size groups. 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.
2021-08-01 23:56:46 +08:00
g_clear_object (&sz_group);
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
if (free_properties)
g_list_free (properties);
g_hash_table_insert (dialog->priv->widgets, g_strdup (container_id), container);
libgimp: sink the floating references after adding them to hash table. 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().
2021-04-20 23:08:31 +08:00
if (g_object_is_floating (container))
g_object_ref_sink (container);
libgimp: improvements to GimpProcedureDialog API. - 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).
2020-11-24 22:00:34 +08:00
return GTK_WIDGET (container);
}
libgimp: new gimp_procedure_dialog_set_sensitive(). 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.
2021-04-07 02:10:46 +08:00
libgimp: new function gimp_procedure_dialog_set_sensitive_if_in(). This function allows to change the sensitivity of a widget depending on the value of another property. We already had gimp_procedure_dialog_set_sensitive() except it was only syncing with a boolean property, whereas the new function can compare with any property type.
2023-06-15 09:31:42 +08:00
static void
gimp_procedure_dialog_set_sensitive_if_in_cb (GObject *config,
GParamSpec *param_spec,
GimpProcedureDialogSensitiveData2 *data)
{
GimpProcedureDialog *dialog = data->dialog;
GtkWidget *widget;
widget = g_hash_table_lookup (dialog->priv->widgets, data->widget_property);
if (widget)
{
GValue param_value = G_VALUE_INIT;
gboolean sensitive;
gint n_values = gimp_value_array_length (data->values);
g_value_init (&param_value, param_spec->value_type);
g_object_get_property (config, param_spec->name, &param_value);
sensitive = (! data->in_values);
for (gint i = 0; i < n_values; i++)
{
GValue *value;
value = gimp_value_array_index (data->values, i);
if (g_param_values_cmp (param_spec, &param_value, value) == 0)
{
sensitive = data->in_values;
break;
}
}
gtk_widget_set_sensitive (widget, sensitive);
g_value_unset (&param_value);
}
else
{
g_printerr ("gimp_procedure_dialog_set_sensitive_if_in: "
"no widget was created for property \"%s\".\n",
data->widget_property);
}
}
libgimp: new gimp_procedure_dialog_set_sensitive(). 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.
2021-04-07 02:10:46 +08:00
static void
gimp_procedure_dialog_sensitive_data_free (GimpProcedureDialogSensitiveData *data)
{
g_free (data->config_property);
g_clear_object (&data->config);
g_slice_free (GimpProcedureDialogSensitiveData, data);
}
libgimp: new function gimp_procedure_dialog_set_sensitive_if_in(). This function allows to change the sensitivity of a widget depending on the value of another property. We already had gimp_procedure_dialog_set_sensitive() except it was only syncing with a boolean property, whereas the new function can compare with any property type.
2023-06-15 09:31:42 +08:00
static void
gimp_procedure_dialog_sensitive_cb_data_free (GimpProcedureDialogSensitiveData2 *data)
{
g_free (data->widget_property);
gimp_value_array_unref (data->values);
g_free (data);
}