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

2651 lines
78 KiB
C
Raw Normal View History

libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
/* GIMP - The GNU Image Manipulation Program
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
*
app, libgimp: add copyright notices to the new stuff, minor cleanup
2019-07-31 06:12:36 +08:00
* gimpprocedure.c
* Copyright (C) 2019 Michael Natterer <mitch@gimp.org>
*
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +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 <stdarg.h>
#include <sys/types.h>
libgimp, plug-ins: move gimp_pdb_run_procedure*() to gimp_procedure_run*(). The gimp_procedure_run() already existed, though it was with an ordered GimpValueArray array of arguments. Its usage feels redundant to the series of gimp_pdb_run_procedure*() functions (which is confusing), but gimp_procedure_run() was actually a bit more generic, because it does not necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a local GimpProcedure, such as the case of one procedure which would want to call another procedure in the same plug-in, but without having to go through PDB. Of course, for local code, you may as well run relevant functions directly, yet it makes sense that if one of the redundant-looking function is removed, it should be the more specific one. Also gimp_procedure_run() feels a lot simpler and logical, API wise. A main difference in usage is that now, plug-in developers have to first explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when they wish to call PDB procedures on the wire. This was done anyway in the gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name directly). Concretely: * gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and gimp_pdb_run_procedure_valist() are removed. * gimp_procedure_run() API is modified to use a variable args list instead of a GimpValueArray. * gimp_procedure_run_config() and gimp_procedure_run_valist() are added. * gimp_procedure_run_config() in particular will be the one used in bindings which don't have variable args support through a (rename-to gimp_procedure_run) annotation.
2023-10-18 23:11:20 +08:00
#include <gobject/gvaluecollector.h>
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
#include "gimp.h"
libgmp: move the remaining legacy code to gimplegacy, even PLUG_IN_INFO Add gimplegacy-private.h to keep it separate from gimp-private.h. The legacy code could now be removed and GimpPlugIn-ported plug-ins would not notice.
2019-08-07 05:06:15 +08:00
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
#include "libgimpbase/gimpprotocol.h"
#include "libgimpbase/gimpwire.h"
#include "gimpgpparams.h"
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
#include "gimppdb-private.h"
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
#include "gimpplugin-private.h"
pdb: move gimp_plugin_menu_register() from the "plugin" to the "pdb" group and call it gimp_pdb_add_proc_menu_path(). Move around and rename some code in app/ to prepare for more procedure setters to work this way.
2019-09-08 21:53:37 +08:00
#include "gimppdb_pdb.h"
Issue #3912: Object proxy management not happy with bindings. We cannot be 100% sure generically (i.e. for all possible bindings available with GObject Introspection) if bindings add their own reference to objects or not. Clearly we have cases when they always do (Lua, Javascript), cases when they do only in certain conditions (global Python variables) and cases when they don't (Vala). What we know for sure is that in these script languages, developers don't manually manage memory anyway. So the additional reference is not their fact. So let's just maintain a list of automatic memory managed binding languages, among the few we officially support (i.e. the ones for which we have working test plug-ins) and verify by executable extension if the plug-in is written in one of these. Both keeping a manually-updated list and verifying by extension are not so pretty solution, but for now it will do.
2023-10-15 22:34:11 +08:00
#include "gimpplugin-private.h"
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
#include "gimpplugin_pdb.h"
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
#include "gimpprocedure-private.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 a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
#include "libgimp-intl.h"
libgimp: fix libgimp introspection. - Fix a few broken references and an inconsistent argument name. - Add the new headers in the introspectable header list. - Add a few missing class descriptions for GimpProcedure and subclasses.
2024-04-24 22:02:08 +08:00
/**
* GimpProcedure:
*
* Procedures are registered functions which can be run across GIMP ecosystem.
* They can be created by plug-ins and can then run by the core application
* when called from menus (or through other interaction depending on specific
* procedure subclasses).
*
* A plug-in can also run procedures created by the core, but also the ones
* created by other plug-ins (see [class@PDB]).
**/
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
enum
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
{
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
PROP_0,
PROP_PLUG_IN,
PROP_NAME,
PROP_PROCEDURE_TYPE,
N_PROPS
};
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
typedef struct _GimpProcedurePrivate
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
{
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
GimpPlugIn *plug_in;
gchar *name;
GimpPDBProcType proc_type;
gchar *image_types;
libgimp: change GimpPlugIn and GimpProcedures so temp procs work
2019-07-31 03:02:58 +08:00
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
gchar *menu_label;
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
GList *menu_paths;
libgimp: move the GimpProcedure icon API next to the menu API
2019-08-18 20:04:45 +08:00
GimpIconType icon_type;
gpointer icon_data;
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
gchar *blurb;
gchar *help;
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
gchar *help_id;
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
gchar *authors;
gchar *copyright;
gchar *date;
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
app, libgimp, pdb: new API to advertize when procedures are sensitive. The new function gimp_procedure_set_sensitivity_mask() allows plug-ins to tell when a procedure should be marked as sensitive or not. gimp_procedure_get_sensitivity_mask() retrieves this information. Currently plug-ins are automatically marked as sensitive when an image is present and a single drawable is selected. Nowadays, we can have multiple selected layers so we should allow plug-ins to tell us if they support working on multiple drawables. Actually we could even imagine new plug-ins which would be made to work only on multiple drawables. Oppositely, there are a lot of plug-ins which don't care at all if any drawable is selected at all (so we should allow no drawable selected). Finally why not even imagine plug-ins which don't care if no image is shown? E.g. plug-ins to create new images or whatnot. This new API allows our core to know all this and show procedure sensitivity accordingly. By default, when the function is not called, the 1 image with 1 drawable selected case is the default, allowing existing plug-ins easier update. Note: this only handles the sensitivity part right now. A plug-in which would advertize working on several layer would still not work, because the core won't allow sending several layers. It's coming in further commits.
2021-04-02 05:49:11 +08:00
gint sensitivity_mask;
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
gint32 n_args;
GParamSpec **args;
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
gint32 n_aux_args;
GParamSpec **aux_args;
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
gint32 n_values;
GParamSpec **values;
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
GimpRunFunc run_func;
libgimp: add run_data and run_data_destroy parameters to procedure_new() so bindings work properly. Change plug-ins accordingly.
2019-08-02 04:45:49 +08:00
gpointer run_data;
GDestroyNotify run_data_destroy;
libgimp: allow to call gimp_procedure_add_menu_path() on installed procs Adding menu paths must be possible even after the procedure has been installed, script-fu registers all menu paths afer installing its procedures so they are properly sorted.
2019-08-13 01:06:13 +08:00
gboolean installed;
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
GHashTable *displays;
GHashTable *images;
GHashTable *items;
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
GHashTable *resources;
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
} GimpProcedurePrivate;
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: gimp_procedure_new_arguments() can now be made static.
2023-10-19 00:43:08 +08:00
static void gimp_procedure_constructed (GObject *object);
static void gimp_procedure_finalize (GObject *object);
static void gimp_procedure_set_property (GObject *object,
guint property_id,
const GValue *value,
GParamSpec *pspec);
static void gimp_procedure_get_property (GObject *object,
guint property_id,
GValue *value,
GParamSpec *pspec);
static void gimp_procedure_real_install (GimpProcedure *procedure);
static void gimp_procedure_real_uninstall (GimpProcedure *procedure);
static GimpValueArray * gimp_procedure_real_run (GimpProcedure *procedure,
const GimpValueArray *args);
static GimpProcedureConfig * gimp_procedure_real_create_config (GimpProcedure *procedure,
GParamSpec **args,
gint n_args);
libgimp: reimplement gimp_procedure_run_config() for public usage. Previous gimp_procedure_run_config() was in fact only good for private usage inside the various run() methods for the different GimpProcedure subtypes. The problem with this implementation is that the returned config object is not complete. For instance, for a GimpLoadProcedure, the "run-mode" and "file" properties are not part of the config object so you cannot call a GimpLoadProcedure with any of the gimp_procedure_run*() functions. Note: we had some working usage, e.g. in file-openraster, but only because it was running the load procedure as a GimpPDBProcedure whose returned config object was indeed always complete! As a consequence, I rename gimp_procedure_run_config() as an internal-only function _gimp_procedure_create_run_config() and I create a new gimp_procedure_run_config() which always return a full config with all arguments.
2024-05-02 03:47:55 +08:00
static GimpProcedureConfig *
gimp_procedure_create_config_with_prefix (GimpProcedure *procedure,
const gchar *prefix,
GParamSpec **args,
gint n_args);
libgimp: gimp_procedure_new_arguments() can now be made static.
2023-10-19 00:43:08 +08:00
static GimpValueArray * gimp_procedure_new_arguments (GimpProcedure *procedure);
static gboolean gimp_procedure_validate_args (GimpProcedure *procedure,
GParamSpec **param_specs,
gint n_param_specs,
GimpValueArray *args,
gboolean return_vals,
GError **error);
static void gimp_procedure_set_icon (GimpProcedure *procedure,
GimpIconType icon_type,
gconstpointer icon_data);
libimp*, app: get rid of inline pixbufs in the API and in pluginrc because they are deprecated. Change GIMP_ICON_TYPE_INLINE_PIXBUF to GIMP_ICON_TYPE_PIXBUF and the libgimp API to (icon-name, GdkPixbuf, GFile). Use the file's uri and a PNG blob of the pixbuf to pass around on the wire and for storage in pluginrc.
2019-08-09 06:05:49 +08:00
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
G_DEFINE_TYPE_WITH_PRIVATE (GimpProcedure, gimp_procedure, G_TYPE_OBJECT)
#define parent_class gimp_procedure_parent_class
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
static GParamSpec *props[N_PROPS] = { NULL, };
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
static void
gimp_procedure_class_init (GimpProcedureClass *klass)
{
GObjectClass *object_class = G_OBJECT_CLASS (klass);
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
object_class->constructed = gimp_procedure_constructed;
object_class->finalize = gimp_procedure_finalize;
object_class->set_property = gimp_procedure_set_property;
object_class->get_property = gimp_procedure_get_property;
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
klass->install = gimp_procedure_real_install;
klass->uninstall = gimp_procedure_real_uninstall;
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
klass->run = gimp_procedure_real_run;
libgimp: add GimpProcedureConfig which implements the GimpConfig interface It's the base for bringing proper management of saved settings (including the last used values) and generated GUI using prop_widgets to plug-ins.
2019-09-20 18:31:11 +08:00
klass->create_config = gimp_procedure_real_create_config;
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
props[PROP_PLUG_IN] =
g_param_spec_object ("plug-in",
"Plug-In",
"The GimpPlugIn of this plug-in process",
GIMP_TYPE_PLUG_IN,
GIMP_PARAM_READWRITE |
G_PARAM_CONSTRUCT_ONLY);
props[PROP_NAME] =
g_param_spec_string ("name",
"Name",
"The procedure's name",
NULL,
GIMP_PARAM_READWRITE |
G_PARAM_CONSTRUCT_ONLY);
props[PROP_PROCEDURE_TYPE] =
g_param_spec_enum ("procedure-type",
"Procedure type",
"The procedure's type",
GIMP_TYPE_PDB_PROC_TYPE,
Properly prefix the values of enum GimpPDBProcType to be GIMP_PDB_PROC_TYPE_PLUGIN, _EXTENSION etc.
2019-08-30 18:52:28 +08:00
GIMP_PDB_PROC_TYPE_PLUGIN,
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
GIMP_PARAM_READWRITE |
G_PARAM_CONSTRUCT_ONLY);
g_object_class_install_properties (object_class, N_PROPS, props);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
}
static void
gimp_procedure_init (GimpProcedure *procedure)
{
}
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
static void
gimp_procedure_constructed (GObject *object)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedure *procedure = GIMP_PROCEDURE (object);
GimpProcedurePrivate *priv = gimp_procedure_get_instance_private (procedure);
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
G_OBJECT_CLASS (parent_class)->constructed (object);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_assert (GIMP_IS_PLUG_IN (priv->plug_in));
g_assert (priv->name != NULL);
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
}
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
static void
gimp_procedure_finalize (GObject *object)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedure *procedure = GIMP_PROCEDURE (object);
GimpProcedurePrivate *priv = gimp_procedure_get_instance_private (procedure);
gint i;
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
if (priv->run_data_destroy)
priv->run_data_destroy (priv->run_data);
libgimp: add run_data and run_data_destroy parameters to procedure_new() so bindings work properly. Change plug-ins accordingly.
2019-08-02 04:45:49 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_clear_object (&priv->plug_in);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_clear_pointer (&priv->name, g_free);
g_clear_pointer (&priv->image_types, g_free);
g_clear_pointer (&priv->menu_label, g_free);
g_clear_pointer (&priv->blurb, g_free);
g_clear_pointer (&priv->help, g_free);
g_clear_pointer (&priv->help_id, g_free);
g_clear_pointer (&priv->authors, g_free);
g_clear_pointer (&priv->copyright, g_free);
g_clear_pointer (&priv->date, g_free);
libgimp: add more registering API to GimpPlugIn and GimpProcedure Icon, menu branch, translation domain and help domain can now be registered using the objects' API instead of the direct PDB calls.
2019-07-31 01:21:57 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_list_free_full (priv->menu_paths, g_free);
priv->menu_paths = NULL;
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
libimp*, app: get rid of inline pixbufs in the API and in pluginrc because they are deprecated. Change GIMP_ICON_TYPE_INLINE_PIXBUF to GIMP_ICON_TYPE_PIXBUF and the libgimp API to (icon-name, GdkPixbuf, GFile). Use the file's uri and a PNG blob of the pixbuf to pass around on the wire and for storage in pluginrc.
2019-08-09 06:05:49 +08:00
gimp_procedure_set_icon (procedure, GIMP_ICON_TYPE_ICON_NAME, NULL);
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
if (priv->args)
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
for (i = 0; i < priv->n_args; i++)
g_param_spec_unref (priv->args[i]);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_clear_pointer (&priv->args, g_free);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
}
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
if (priv->aux_args)
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
for (i = 0; i < priv->n_aux_args; i++)
g_param_spec_unref (priv->aux_args[i]);
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_clear_pointer (&priv->aux_args, g_free);
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
}
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
if (priv->values)
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
for (i = 0; i < priv->n_values; i++)
g_param_spec_unref (priv->values[i]);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_clear_pointer (&priv->values, g_free);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
}
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
_gimp_procedure_destroy_proxies (procedure);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
G_OBJECT_CLASS (parent_class)->finalize (object);
}
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
static void
gimp_procedure_set_property (GObject *object,
guint property_id,
const GValue *value,
GParamSpec *pspec)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedure *procedure = GIMP_PROCEDURE (object);
GimpProcedurePrivate *priv = gimp_procedure_get_instance_private (procedure);
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
switch (property_id)
{
case PROP_PLUG_IN:
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_set_object (&priv->plug_in, g_value_get_object (value));
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
break;
case PROP_NAME:
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_free (priv->name);
priv->name = g_value_dup_string (value);
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
break;
case PROP_PROCEDURE_TYPE:
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->proc_type = g_value_get_enum (value);
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
break;
}
}
static void
gimp_procedure_get_property (GObject *object,
guint property_id,
GValue *value,
GParamSpec *pspec)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedure *procedure = GIMP_PROCEDURE (object);
GimpProcedurePrivate *priv = gimp_procedure_get_instance_private (procedure);
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
switch (property_id)
{
case PROP_PLUG_IN:
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_value_set_object (value, priv->plug_in);
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
break;
case PROP_NAME:
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_value_set_string (value, priv->name);
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
break;
case PROP_PROCEDURE_TYPE:
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_value_set_enum (value, priv->proc_type);
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
break;
}
}
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
static void
pdb: move gimp_plugin_icon_register_invoker() from "plugin" to "pdb" and call it gimp_pdb_set_proc_icon(). Change icon registration code in libgimp/ and app/ so it's now possible to register icons for temporary procedures.
2019-09-08 22:22:32 +08:00
gimp_procedure_install_icon (GimpProcedure *procedure)
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
{
pdb: move gimp_plugin_icon_register_invoker() from "plugin" to "pdb" and call it gimp_pdb_set_proc_icon(). Change icon registration code in libgimp/ and app/ so it's now possible to register icons for temporary procedures.
2019-09-08 22:22:32 +08:00
GimpIconType icon_type;
guint8 *icon_data = NULL;
gsize icon_data_length = 0;
Remove GimpUint8Array in favor of GBytes GLib has a specific type for byte arrays: `GBytes` (and it's underlying GType `G_TYPE_BYTES`). By using this type, we can avoid having a `GimpUint8Array` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GBytes`, we allow other languages to pass on byte arrays as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with byte arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2023-05-24 05:37:46 +08:00
GBytes *icon_bytes = NULL;
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
icon_type = gimp_procedure_get_icon_type (procedure);
switch (icon_type)
{
case GIMP_ICON_TYPE_ICON_NAME:
{
icon_data = (guint8 *) gimp_procedure_get_icon_name (procedure);
if (icon_data)
Remove GimpUint8Array in favor of GBytes GLib has a specific type for byte arrays: `GBytes` (and it's underlying GType `G_TYPE_BYTES`). By using this type, we can avoid having a `GimpUint8Array` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GBytes`, we allow other languages to pass on byte arrays as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with byte arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2023-05-24 05:37:46 +08:00
icon_bytes = g_bytes_new_static (icon_data,
strlen ((gchar *) icon_data) + 1);
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
}
break;
case GIMP_ICON_TYPE_PIXBUF:
{
GdkPixbuf *pixbuf = gimp_procedure_get_icon_pixbuf (procedure);
if (pixbuf)
Remove GimpUint8Array in favor of GBytes GLib has a specific type for byte arrays: `GBytes` (and it's underlying GType `G_TYPE_BYTES`). By using this type, we can avoid having a `GimpUint8Array` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GBytes`, we allow other languages to pass on byte arrays as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with byte arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2023-05-24 05:37:46 +08:00
{
libgimp: Fix checks when writing GdkPixbuf over the wire * We need to check if `icon_bytes` is NULL, not `icon_data` * We should not set `icon_bytes` if `gdk_pixbuf_save_to_buffer` fails
2023-05-26 05:19:58 +08:00
if (gdk_pixbuf_save_to_buffer (pixbuf,
(gchar **) &icon_data, &icon_data_length,
"png", NULL, NULL))
icon_bytes = g_bytes_new_take (icon_data, icon_data_length);
Remove GimpUint8Array in favor of GBytes GLib has a specific type for byte arrays: `GBytes` (and it's underlying GType `G_TYPE_BYTES`). By using this type, we can avoid having a `GimpUint8Array` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GBytes`, we allow other languages to pass on byte arrays as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with byte arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2023-05-24 05:37:46 +08:00
}
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
}
break;
case GIMP_ICON_TYPE_IMAGE_FILE:
{
GFile *file = gimp_procedure_get_icon_file (procedure);
if (file)
{
icon_data = (guchar *) g_file_get_uri (file);
icon_data_length = strlen ((gchar *) icon_data) + 1;
Remove GimpUint8Array in favor of GBytes GLib has a specific type for byte arrays: `GBytes` (and it's underlying GType `G_TYPE_BYTES`). By using this type, we can avoid having a `GimpUint8Array` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GBytes`, we allow other languages to pass on byte arrays as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with byte arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2023-05-24 05:37:46 +08:00
icon_bytes = g_bytes_new_take (icon_data, icon_data_length);
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
}
}
break;
}
libgimp: Fix checks when writing GdkPixbuf over the wire * We need to check if `icon_bytes` is NULL, not `icon_data` * We should not set `icon_bytes` if `gdk_pixbuf_save_to_buffer` fails
2023-05-26 05:19:58 +08:00
if (icon_bytes)
pdb: move gimp_plugin_icon_register_invoker() from "plugin" to "pdb" and call it gimp_pdb_set_proc_icon(). Change icon registration code in libgimp/ and app/ so it's now possible to register icons for temporary procedures.
2019-09-08 22:22:32 +08:00
_gimp_pdb_set_proc_icon (gimp_procedure_get_name (procedure),
Remove GimpUint8Array in favor of GBytes GLib has a specific type for byte arrays: `GBytes` (and it's underlying GType `G_TYPE_BYTES`). By using this type, we can avoid having a `GimpUint8Array` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GBytes`, we allow other languages to pass on byte arrays as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with byte arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2023-05-24 05:37:46 +08:00
icon_type, icon_bytes);
libgimp: fix a GBytes leak.
2023-05-26 06:30:47 +08:00
g_bytes_unref (icon_bytes);
pdb: move gimp_plugin_icon_register_invoker() from "plugin" to "pdb" and call it gimp_pdb_set_proc_icon(). Change icon registration code in libgimp/ and app/ so it's now possible to register icons for temporary procedures.
2019-09-08 22:22:32 +08:00
}
static void
gimp_procedure_real_install (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
GParamSpec **args;
GParamSpec **return_vals;
gint n_args = 0;
gint n_return_vals = 0;
GList *list;
GimpPlugIn *plug_in;
GPProcInstall proc_install;
gint i;
priv = gimp_procedure_get_instance_private (procedure);
pdb: move gimp_plugin_icon_register_invoker() from "plugin" to "pdb" and call it gimp_pdb_set_proc_icon(). Change icon registration code in libgimp/ and app/ so it's now possible to register icons for temporary procedures.
2019-09-08 22:22:32 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_return_if_fail (priv->installed == FALSE);
pdb: move gimp_plugin_icon_register_invoker() from "plugin" to "pdb" and call it gimp_pdb_set_proc_icon(). Change icon registration code in libgimp/ and app/ so it's now possible to register icons for temporary procedures.
2019-09-08 22:22:32 +08:00
args = gimp_procedure_get_arguments (procedure, &n_args);
return_vals = gimp_procedure_get_return_values (procedure, &n_return_vals);
Rename all "nparams" and "nreturn_vals" members in the wire protocol to "n_params" and "n_return_vals".
2019-09-09 07:00:54 +08:00
proc_install.name = (gchar *) gimp_procedure_get_name (procedure);
proc_install.type = gimp_procedure_get_proc_type (procedure);
proc_install.n_params = n_args;
proc_install.n_return_vals = n_return_vals;
proc_install.params = g_new0 (GPParamDef, n_args);
proc_install.return_vals = g_new0 (GPParamDef, n_return_vals);
pdb: move gimp_plugin_icon_register_invoker() from "plugin" to "pdb" and call it gimp_pdb_set_proc_icon(). Change icon registration code in libgimp/ and app/ so it's now possible to register icons for temporary procedures.
2019-09-08 22:22:32 +08:00
for (i = 0; i < n_args; i++)
{
_gimp_param_spec_to_gp_param_def (args[i],
&proc_install.params[i]);
}
for (i = 0; i < n_return_vals; i++)
{
_gimp_param_spec_to_gp_param_def (return_vals[i],
&proc_install.return_vals[i]);
}
plug_in = gimp_procedure_get_plug_in (procedure);
if (! gp_proc_install_write (_gimp_plug_in_get_write_channel (plug_in),
&proc_install, plug_in))
gimp_quit ();
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
g_free (proc_install.params);
g_free (proc_install.return_vals);
pdb: move gimp_plugin_icon_register_invoker() from "plugin" to "pdb" and call it gimp_pdb_set_proc_icon(). Change icon registration code in libgimp/ and app/ so it's now possible to register icons for temporary procedures.
2019-09-08 22:22:32 +08:00
gimp_procedure_install_icon (procedure);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
if (priv->image_types)
pdb: add gimp_pdb_set_proc_documentation() and _attribution() and all the needed code in libgimp/ and app/ to set them on a procedure using the new API. Remove the strings from GPProcInstall.
2019-09-09 06:36:24 +08:00
{
_gimp_pdb_set_proc_image_types (gimp_procedure_get_name (procedure),
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->image_types);
pdb: add gimp_pdb_set_proc_documentation() and _attribution() and all the needed code in libgimp/ and app/ to set them on a procedure using the new API. Remove the strings from GPProcInstall.
2019-09-09 06:36:24 +08:00
}
pdb: add gimp_pdb_set_proc_image_types() and all the needed code in libgimp/ and app/ to set a plug-in procedure's image types using the new API. Remove the image types from GPProcInstall.
2019-09-08 22:54:08 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
if (priv->menu_label)
pdb: add gimp_pdb_set_proc_documentation() and _attribution() and all the needed code in libgimp/ and app/ to set them on a procedure using the new API. Remove the strings from GPProcInstall.
2019-09-09 06:36:24 +08:00
{
_gimp_pdb_set_proc_menu_label (gimp_procedure_get_name (procedure),
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->menu_label);
pdb: add gimp_pdb_set_proc_documentation() and _attribution() and all the needed code in libgimp/ and app/ to set them on a procedure using the new API. Remove the strings from GPProcInstall.
2019-09-09 06:36:24 +08:00
}
pdb: add gimp_pdb_set_proc_menu_label() and all the needed code in libgimp/ and app/ to set a plug-in procedure's menu label using the new API. Remove the menu label from GPProcInstall.
2019-09-08 23:30:54 +08:00
app, libgimp, pdb: new API to advertize when procedures are sensitive. The new function gimp_procedure_set_sensitivity_mask() allows plug-ins to tell when a procedure should be marked as sensitive or not. gimp_procedure_get_sensitivity_mask() retrieves this information. Currently plug-ins are automatically marked as sensitive when an image is present and a single drawable is selected. Nowadays, we can have multiple selected layers so we should allow plug-ins to tell us if they support working on multiple drawables. Actually we could even imagine new plug-ins which would be made to work only on multiple drawables. Oppositely, there are a lot of plug-ins which don't care at all if any drawable is selected at all (so we should allow no drawable selected). Finally why not even imagine plug-ins which don't care if no image is shown? E.g. plug-ins to create new images or whatnot. This new API allows our core to know all this and show procedure sensitivity accordingly. By default, when the function is not called, the 1 image with 1 drawable selected case is the default, allowing existing plug-ins easier update. Note: this only handles the sensitivity part right now. A plug-in which would advertize working on several layer would still not work, because the core won't allow sending several layers. It's coming in further commits.
2021-04-02 05:49:11 +08:00
_gimp_pdb_set_proc_sensitivity_mask (gimp_procedure_get_name (procedure),
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->sensitivity_mask);
app, libgimp, pdb: new API to advertize when procedures are sensitive. The new function gimp_procedure_set_sensitivity_mask() allows plug-ins to tell when a procedure should be marked as sensitive or not. gimp_procedure_get_sensitivity_mask() retrieves this information. Currently plug-ins are automatically marked as sensitive when an image is present and a single drawable is selected. Nowadays, we can have multiple selected layers so we should allow plug-ins to tell us if they support working on multiple drawables. Actually we could even imagine new plug-ins which would be made to work only on multiple drawables. Oppositely, there are a lot of plug-ins which don't care at all if any drawable is selected at all (so we should allow no drawable selected). Finally why not even imagine plug-ins which don't care if no image is shown? E.g. plug-ins to create new images or whatnot. This new API allows our core to know all this and show procedure sensitivity accordingly. By default, when the function is not called, the 1 image with 1 drawable selected case is the default, allowing existing plug-ins easier update. Note: this only handles the sensitivity part right now. A plug-in which would advertize working on several layer would still not work, because the core won't allow sending several layers. It's coming in further commits.
2021-04-02 05:49:11 +08:00
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
for (list = gimp_procedure_get_menu_paths (procedure);
list;
list = g_list_next (list))
{
pdb: move gimp_plugin_menu_register() from the "plugin" to the "pdb" group and call it gimp_pdb_add_proc_menu_path(). Move around and rename some code in app/ to prepare for more procedure setters to work this way.
2019-09-08 21:53:37 +08:00
_gimp_pdb_add_proc_menu_path (gimp_procedure_get_name (procedure),
list->data);
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
}
libgimp: allow to call gimp_procedure_add_menu_path() on installed procs Adding menu paths must be possible even after the procedure has been installed, script-fu registers all menu paths afer installing its procedures so they are properly sorted.
2019-08-13 01:06:13 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
if (priv->blurb ||
priv->help ||
priv->help_id)
pdb: add gimp_pdb_set_proc_documentation() and _attribution() and all the needed code in libgimp/ and app/ to set them on a procedure using the new API. Remove the strings from GPProcInstall.
2019-09-09 06:36:24 +08:00
{
_gimp_pdb_set_proc_documentation (gimp_procedure_get_name (procedure),
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->blurb,
priv->help,
priv->help_id);
pdb: add gimp_pdb_set_proc_documentation() and _attribution() and all the needed code in libgimp/ and app/ to set them on a procedure using the new API. Remove the strings from GPProcInstall.
2019-09-09 06:36:24 +08:00
}
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
if (priv->authors ||
priv->copyright ||
priv->date)
pdb: add gimp_pdb_set_proc_documentation() and _attribution() and all the needed code in libgimp/ and app/ to set them on a procedure using the new API. Remove the strings from GPProcInstall.
2019-09-09 06:36:24 +08:00
{
_gimp_pdb_set_proc_attribution (gimp_procedure_get_name (procedure),
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->authors,
priv->copyright,
priv->date);
pdb: add gimp_pdb_set_proc_documentation() and _attribution() and all the needed code in libgimp/ and app/ to set them on a procedure using the new API. Remove the strings from GPProcInstall.
2019-09-09 06:36:24 +08:00
}
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->installed = TRUE;
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
}
static void
gimp_procedure_real_uninstall (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv = gimp_procedure_get_instance_private (procedure);
GimpPlugIn *plug_in;
GPProcUninstall proc_uninstall;
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_return_if_fail (priv->installed == TRUE);
libgimp: allow to call gimp_procedure_add_menu_path() on installed procs Adding menu paths must be possible even after the procedure has been installed, script-fu registers all menu paths afer installing its procedures so they are properly sorted.
2019-08-13 01:06:13 +08:00
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
proc_uninstall.name = (gchar *) gimp_procedure_get_name (procedure);
plug_in = gimp_procedure_get_plug_in (procedure);
if (! gp_proc_uninstall_write (_gimp_plug_in_get_write_channel (plug_in),
&proc_uninstall, plug_in))
gimp_quit ();
libgimp: allow to call gimp_procedure_add_menu_path() on installed procs Adding menu paths must be possible even after the procedure has been installed, script-fu registers all menu paths afer installing its procedures so they are properly sorted.
2019-08-13 01:06:13 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->installed = FALSE;
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
}
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
static GimpValueArray *
gimp_procedure_real_run (GimpProcedure *procedure,
const GimpValueArray *args)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv = gimp_procedure_get_instance_private (procedure);
GimpPlugIn *plug_in;
GimpProcedureConfig *config;
GimpImage *image = NULL;
GimpRunMode run_mode = GIMP_RUN_NONINTERACTIVE;
GimpValueArray *retvals;
GimpPDBStatusType status = GIMP_PDB_EXECUTION_ERROR;
libgimp, plug-ins: rename gimp_procedure_new2() as gimp_procedure_new() and… … remove the latter. Now all GimpProcedure use this new implementation with use a config object.
2023-06-17 00:34:53 +08:00
if (gimp_value_array_length (args) > 0 &&
G_VALUE_HOLDS_ENUM (gimp_value_array_index (args, 0)))
Issue #50: new gimp_procedure_new2() which automatically stores procedure config. This new function is meant to replace gimp_procedure_new() when all plug-in usage will have been switched. This function creates the GimpProcedureConfig object on behalf of the plug-in and calls gimp_procedure_config_begin_run() and gimp_procedure_config_end_run(). This way we ensure that all plug-in calls with successful result are properly stored without asking the developer not to forget to call these (if a "good practice" is in fact something we request to do every time, especially for good user experience, we might as well make it rather a core process). Advantages: * Better interactive experience: using any plug-in will result in saved previously used settings. * for developers, working on config objects is also much more comfortable than working on GValueArray; * step forward for the future macro infrastructure: if we can ensure that all plug-in calls are properly logged, then we can replay plug-in actions, in NON_INTERACTIVE with the same settings.
2023-06-12 23:56:06 +08:00
{
libgimp, plug-ins: rename gimp_procedure_new2() as gimp_procedure_new() and… … remove the latter. Now all GimpProcedure use this new implementation with use a config object.
2023-06-17 00:34:53 +08:00
run_mode = GIMP_VALUES_GET_ENUM (args, 0);
if (gimp_value_array_length (args) > 1 &&
GIMP_VALUE_HOLDS_IMAGE (gimp_value_array_index (args, 1)))
image = GIMP_VALUES_GET_IMAGE (args, 1);
Issue #50: new gimp_procedure_new2() which automatically stores procedure config. This new function is meant to replace gimp_procedure_new() when all plug-in usage will have been switched. This function creates the GimpProcedureConfig object on behalf of the plug-in and calls gimp_procedure_config_begin_run() and gimp_procedure_config_end_run(). This way we ensure that all plug-in calls with successful result are properly stored without asking the developer not to forget to call these (if a "good practice" is in fact something we request to do every time, especially for good user experience, we might as well make it rather a core process). Advantages: * Better interactive experience: using any plug-in will result in saved previously used settings. * for developers, working on config objects is also much more comfortable than working on GValueArray; * step forward for the future macro infrastructure: if we can ensure that all plug-in calls are properly logged, then we can replay plug-in actions, in NON_INTERACTIVE with the same settings.
2023-06-12 23:56:06 +08:00
}
libgimp, plug-ins: rename gimp_procedure_new2() as gimp_procedure_new() and… … remove the latter. Now all GimpProcedure use this new implementation with use a config object.
2023-06-17 00:34:53 +08:00
libgimp: reimplement gimp_procedure_run_config() for public usage. Previous gimp_procedure_run_config() was in fact only good for private usage inside the various run() methods for the different GimpProcedure subtypes. The problem with this implementation is that the returned config object is not complete. For instance, for a GimpLoadProcedure, the "run-mode" and "file" properties are not part of the config object so you cannot call a GimpLoadProcedure with any of the gimp_procedure_run*() functions. Note: we had some working usage, e.g. in file-openraster, but only because it was running the load procedure as a GimpPDBProcedure whose returned config object was indeed always complete! As a consequence, I rename gimp_procedure_run_config() as an internal-only function _gimp_procedure_create_run_config() and I create a new gimp_procedure_run_config() which always return a full config with all arguments.
2024-05-02 03:47:55 +08:00
config = _gimp_procedure_create_run_config (procedure);
libgimp: all _gimp_procedure_config_begin|end_*() functions made private. Since now all GimpProcedure and subclasses run these before and after the relevant run() functions, there is no need to keep these public.
2023-10-15 23:01:47 +08:00
_gimp_procedure_config_begin_run (config, image, run_mode, args);
libgimp, plug-ins: rename gimp_procedure_new2() as gimp_procedure_new() and… … remove the latter. Now all GimpProcedure use this new implementation with use a config object.
2023-06-17 00:34:53 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
retvals = priv->run_func (procedure, config, priv->run_data);
libgimp, plug-ins: rename gimp_procedure_new2() as gimp_procedure_new() and… … remove the latter. Now all GimpProcedure use this new implementation with use a config object.
2023-06-17 00:34:53 +08:00
if (retvals != NULL &&
gimp_value_array_length (retvals) > 0 &&
G_VALUE_HOLDS_ENUM (gimp_value_array_index (retvals, 0)))
status = GIMP_VALUES_GET_ENUM (retvals, 0);
libgimp: all _gimp_procedure_config_begin|end_*() functions made private. Since now all GimpProcedure and subclasses run these before and after the relevant run() functions, there is no need to keep these public.
2023-10-15 23:01:47 +08:00
_gimp_procedure_config_end_run (config, status);
libgimp: some debug printing for plug-in developers. This will be useful for plug-in developers but also for us. Seeing we leak the config object is often a good indication that something is wrong in our handling of internal references (since everything relies on the config object in plug-ins now, in particular all the GUI).
2023-07-18 05:31:26 +08:00
/* This is debug printing to help plug-in developers figure out best
* practices.
*/
Issue #3912: Object proxy management not happy with bindings. We cannot be 100% sure generically (i.e. for all possible bindings available with GObject Introspection) if bindings add their own reference to objects or not. Clearly we have cases when they always do (Lua, Javascript), cases when they do only in certain conditions (global Python variables) and cases when they don't (Vala). What we know for sure is that in these script languages, developers don't manually manage memory anyway. So the additional reference is not their fact. So let's just maintain a list of automatic memory managed binding languages, among the few we officially support (i.e. the ones for which we have working test plug-ins) and verify by executable extension if the plug-in is written in one of these. Both keeping a manually-updated list and verifying by extension are not so pretty solution, but for now it will do.
2023-10-15 22:34:11 +08:00
plug_in = gimp_procedure_get_plug_in (procedure);
if (G_OBJECT (config)->ref_count > 1 &&
_gimp_plug_in_manage_memory_manually (plug_in))
libgimp: some debug printing for plug-in developers. This will be useful for plug-in developers but also for us. Seeing we leak the config object is often a good indication that something is wrong in our handling of internal references (since everything relies on the config object in plug-ins now, in particular all the GUI).
2023-07-18 05:31:26 +08:00
g_printerr ("%s: ERROR: the GimpProcedureConfig object was refed "
"by plug-in, it MUST NOT do that!\n", G_STRFUNC);
libgimp, plug-ins: rename gimp_procedure_new2() as gimp_procedure_new() and… … remove the latter. Now all GimpProcedure use this new implementation with use a config object.
2023-06-17 00:34:53 +08:00
g_object_unref (config);
return retvals;
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
}
libgimp: add GimpProcedureConfig which implements the GimpConfig interface It's the base for bringing proper management of saved settings (including the last used values) and generated GUI using prop_widgets to plug-ins.
2019-09-20 18:31:11 +08:00
static GimpProcedureConfig *
gimp_procedure_real_create_config (GimpProcedure *procedure,
GParamSpec **args,
gint n_args)
libgimp: reimplement gimp_procedure_run_config() for public usage. Previous gimp_procedure_run_config() was in fact only good for private usage inside the various run() methods for the different GimpProcedure subtypes. The problem with this implementation is that the returned config object is not complete. For instance, for a GimpLoadProcedure, the "run-mode" and "file" properties are not part of the config object so you cannot call a GimpLoadProcedure with any of the gimp_procedure_run*() functions. Note: we had some working usage, e.g. in file-openraster, but only because it was running the load procedure as a GimpPDBProcedure whose returned config object was indeed always complete! As a consequence, I rename gimp_procedure_run_config() as an internal-only function _gimp_procedure_create_run_config() and I create a new gimp_procedure_run_config() which always return a full config with all arguments.
2024-05-02 03:47:55 +08:00
{
return gimp_procedure_create_config_with_prefix (procedure,
"GimpProcedureConfigRun",
args, n_args);
}
static GimpProcedureConfig *
gimp_procedure_create_config_with_prefix (GimpProcedure *procedure,
const gchar *prefix,
GParamSpec **args,
gint n_args)
libgimp: add GimpProcedureConfig which implements the GimpConfig interface It's the base for bringing proper management of saved settings (including the last used values) and generated GUI using prop_widgets to plug-ins.
2019-09-20 18:31:11 +08:00
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv = gimp_procedure_get_instance_private (procedure);
gchar *type_name;
GType type;
libgimp: add GimpProcedureConfig which implements the GimpConfig interface It's the base for bringing proper management of saved settings (including the last used values) and generated GUI using prop_widgets to plug-ins.
2019-09-20 18:31:11 +08:00
libgimp: reimplement gimp_procedure_run_config() for public usage. Previous gimp_procedure_run_config() was in fact only good for private usage inside the various run() methods for the different GimpProcedure subtypes. The problem with this implementation is that the returned config object is not complete. For instance, for a GimpLoadProcedure, the "run-mode" and "file" properties are not part of the config object so you cannot call a GimpLoadProcedure with any of the gimp_procedure_run*() functions. Note: we had some working usage, e.g. in file-openraster, but only because it was running the load procedure as a GimpPDBProcedure whose returned config object was indeed always complete! As a consequence, I rename gimp_procedure_run_config() as an internal-only function _gimp_procedure_create_run_config() and I create a new gimp_procedure_run_config() which always return a full config with all arguments.
2024-05-02 03:47:55 +08:00
type_name = g_strdup_printf ("%s-%s", prefix,
libgimp: add GimpProcedureConfig which implements the GimpConfig interface It's the base for bringing proper management of saved settings (including the last used values) and generated GUI using prop_widgets to plug-ins.
2019-09-20 18:31:11 +08:00
gimp_procedure_get_name (procedure));
type = g_type_from_name (type_name);
if (! type)
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
{
GParamSpec **config_args;
gint n_config_args;
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
n_config_args = n_args + priv->n_aux_args;
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
config_args = g_new0 (GParamSpec *, n_config_args);
memcpy (config_args,
args,
n_args * sizeof (GParamSpec *));
memcpy (config_args + n_args,
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->aux_args,
priv->n_aux_args * sizeof (GParamSpec *));
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
type = gimp_config_type_register (GIMP_TYPE_PROCEDURE_CONFIG,
type_name,
config_args, n_config_args);
g_free (config_args);
}
libgimp: add GimpProcedureConfig which implements the GimpConfig interface It's the base for bringing proper management of saved settings (including the last used values) and generated GUI using prop_widgets to plug-ins.
2019-09-20 18:31:11 +08:00
g_free (type_name);
return g_object_new (type,
"procedure", procedure,
NULL);
}
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
/* public functions */
libgimp, libgimpbase: add some documentation for new functions. Just for a few of them just now as I needed these for my binding plug-in tests, and without the proper annotations, these functions were unavailable.
2019-08-01 17:57:17 +08:00
/**
* gimp_procedure_new:
* @plug_in: a #GimpPlugIn.
* @name: the new procedure's name.
* @proc_type: the new procedure's #GimpPDBProcType.
libgimp: add run_data and run_data_destroy parameters to procedure_new() so bindings work properly. Change plug-ins accordingly.
2019-08-02 04:45:49 +08:00
* @run_func: the run function for the new procedure.
* @run_data: user data passed to @run_func.
libgimp: fix various docs typos or small errors.
2019-08-02 08:30:07 +08:00
* @run_data_destroy: (nullable): free function for @run_data, or %NULL.
libgimp, libgimpbase: add some documentation for new functions. Just for a few of them just now as I needed these for my binding plug-in tests, and without the proper annotations, these functions were unavailable.
2019-08-01 17:57:17 +08:00
*
* Creates a new procedure named @name which will call @run_func when
* invoked.
*
libgimp: add gimp_procedure_set_image_types() and remove the "image_types" parameter from gimp_procedure_set_strings(), which is only a bad hack copied from the core procedure class.
2019-08-02 05:09:01 +08:00
* The @name parameter is mandatory and should be unique, or it will
* overwrite an already existing procedure (overwrite procedures only
* if you know what you're doing).
*
Properly prefix the values of enum GimpPDBProcType to be GIMP_PDB_PROC_TYPE_PLUGIN, _EXTENSION etc.
2019-08-30 18:52:28 +08:00
* @proc_type should be %GIMP_PDB_PROC_TYPE_PLUGIN for "normal" plug-ins.
libgimp: add gimp_procedure_extension_ready() which must be called by GIMP_EXTENSION procedures when they are ready to run their temporary procedures. Move gimp_extension_ack() to gimpobsolete.[ch].
2019-08-02 05:24:49 +08:00
*
Properly prefix the values of enum GimpPDBProcType to be GIMP_PDB_PROC_TYPE_PLUGIN, _EXTENSION etc.
2019-08-30 18:52:28 +08:00
* Using %GIMP_PDB_PROC_TYPE_EXTENSION means that the plug-in will add
* temporary procedures. Therefore, the GIMP core will wait until the
* %GIMP_PDB_PROC_TYPE_EXTENSION procedure has called
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* [method@Procedure.extension_ready], which means that the procedure
libgimp: more GimpPlugIn and GimpProcedure docs and annotations They are now GI-warning-free.
2019-08-02 07:32:16 +08:00
* has done its initialization, installed its temporary procedures and
* is ready to run.
*
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* *Not calling [method@Procedure.extension_ready] from a
Properly prefix the values of enum GimpPDBProcType to be GIMP_PDB_PROC_TYPE_PLUGIN, _EXTENSION etc.
2019-08-30 18:52:28 +08:00
* %GIMP_PDB_PROC_TYPE_EXTENSION procedure will cause the GIMP core to
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* lock up.*
libgimp: more GimpPlugIn and GimpProcedure docs and annotations They are now GI-warning-free.
2019-08-02 07:32:16 +08:00
*
Properly prefix the values of enum GimpPDBProcType to be GIMP_PDB_PROC_TYPE_PLUGIN, _EXTENSION etc.
2019-08-30 18:52:28 +08:00
* Additionally, a %GIMP_PDB_PROC_TYPE_EXTENSION procedure with no
* arguments added is an "automatic" extension that will be
* automatically started on each GIMP startup.
libgimp: add gimp_procedure_extension_ready() which must be called by GIMP_EXTENSION procedures when they are ready to run their temporary procedures. Move gimp_extension_ack() to gimpobsolete.[ch].
2019-08-02 05:24:49 +08:00
*
Properly prefix the values of enum GimpPDBProcType to be GIMP_PDB_PROC_TYPE_PLUGIN, _EXTENSION etc.
2019-08-30 18:52:28 +08:00
* %GIMP_PDB_PROC_TYPE_TEMPORARY must be used for temporary procedures
* that are created during a plug-ins lifetime. They must be added to
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* the #GimpPlugIn using [method@PlugIn.add_temp_procedure].
libgimp: add gimp_procedure_set_image_types() and remove the "image_types" parameter from gimp_procedure_set_strings(), which is only a bad hack copied from the core procedure class.
2019-08-02 05:09:01 +08:00
*
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* @run_func is called via [method@Procedure.run].
libgimp: cleanup and more docs for GimpProcedure
2019-08-02 05:46:25 +08:00
*
Properly prefix the values of enum GimpPDBProcType to be GIMP_PDB_PROC_TYPE_PLUGIN, _EXTENSION etc.
2019-08-30 18:52:28 +08:00
* For %GIMP_PDB_PROC_TYPE_PLUGIN and %GIMP_PDB_PROC_TYPE_EXTENSION
* procedures the call of @run_func is basically the lifetime of the
* plug-in.
libgimp: cleanup and more docs for GimpProcedure
2019-08-02 05:46:25 +08:00
*
libgimp, libgimpbase: add some documentation for new functions. Just for a few of them just now as I needed these for my binding plug-in tests, and without the proper annotations, these functions were unavailable.
2019-08-01 17:57:17 +08:00
* Returns: a new #GimpProcedure.
libgimp: remove includes and add "Since: 3.0" in gimpprocecure.c
2019-08-06 05:33:49 +08:00
*
* Since: 3.0
libgimp, libgimpbase: add some documentation for new functions. Just for a few of them just now as I needed these for my binding plug-in tests, and without the proper annotations, these functions were unavailable.
2019-08-01 17:57:17 +08:00
**/
libgimp*: various doc fixes
2019-08-10 18:32:25 +08:00
GimpProcedure *
libgimp, plug-ins: rename gimp_procedure_new2() as gimp_procedure_new() and… … remove the latter. Now all GimpProcedure use this new implementation with use a config object.
2023-06-17 00:34:53 +08:00
gimp_procedure_new (GimpPlugIn *plug_in,
const gchar *name,
GimpPDBProcType proc_type,
GimpRunFunc run_func,
gpointer run_data,
GDestroyNotify run_data_destroy)
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedure *procedure;
GimpProcedurePrivate *priv;
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: change GimpPlugIn and GimpProcedures so temp procs work
2019-07-31 03:02:58 +08:00
g_return_val_if_fail (GIMP_IS_PLUG_IN (plug_in), NULL);
libgimp: fail gimp_procedure_new() on non-canonical procedure names
2019-08-06 05:22:39 +08:00
g_return_val_if_fail (gimp_is_canonical_identifier (name), NULL);
Properly prefix the values of enum GimpPDBProcType to be GIMP_PDB_PROC_TYPE_PLUGIN, _EXTENSION etc.
2019-08-30 18:52:28 +08:00
g_return_val_if_fail (proc_type != GIMP_PDB_PROC_TYPE_INTERNAL, NULL);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
g_return_val_if_fail (run_func != NULL, NULL);
libgimp: add a GimpPDB class and subclass GimpProcedure as GimpPDBProcedure The idea is that we already have a GimpProcedure object in libgimp which has name, help, blurb, arguments, return values and everything, so we really don't need a parallel API to query PDB procedures for their properties. - make run() a virtual function of GimpProcedure - move GIMP_PDB_ERROR to GimpPDB - GimpPDBProcedure is a trivial subblass which populates GimpProcedure's members by querying the PDB. - make "plug-in", "procedure-type" and "name" construct-only properties of GimpProcedure. This is all work in progress.
2019-08-06 18:17:27 +08:00
procedure = g_object_new (GIMP_TYPE_PROCEDURE,
"plug-in", plug_in,
"name", name,
"procedure-type", proc_type,
NULL);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
priv->run_func = run_func;
priv->run_data = run_data;
priv->run_data_destroy = run_data_destroy;
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
return procedure;
}
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
/**
* gimp_procedure_get_plug_in:
* @procedure: A #GimpProcedure.
*
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* Returns: (transfer none): The #GimpPlugIn given in [ctor@Procedure.new].
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
*
* Since: 3.0
**/
libgimp: change GimpPlugIn and GimpProcedures so temp procs work
2019-07-31 03:02:58 +08:00
GimpPlugIn *
gimp_procedure_get_plug_in (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
libgimp: change GimpPlugIn and GimpProcedures so temp procs work
2019-07-31 03:02:58 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
return priv->plug_in;
libgimp: change GimpPlugIn and GimpProcedures so temp procs work
2019-07-31 03:02:58 +08:00
}
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
/**
* gimp_procedure_get_name:
* @procedure: A #GimpProcedure.
*
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* Returns: The procedure's name given in [ctor@Procedure.new].
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
*
* Since: 3.0
**/
libgimp: cleanup and more docs for GimpProcedure
2019-08-02 05:46:25 +08:00
const gchar *
gimp_procedure_get_name (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
libgimp: cleanup and more docs for GimpProcedure
2019-08-02 05:46:25 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
return priv->name;
libgimp: cleanup and more docs for GimpProcedure
2019-08-02 05:46:25 +08:00
}
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
/**
* gimp_procedure_get_proc_type:
* @procedure: A #GimpProcedure.
*
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* Returns: The procedure's type given in [ctor@Procedure.new].
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
*
* Since: 3.0
**/
libgimp: change GimpPlugIn and GimpProcedures so temp procs work
2019-07-31 03:02:58 +08:00
GimpPDBProcType
gimp_procedure_get_proc_type (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
Properly prefix the values of enum GimpPDBProcType to be GIMP_PDB_PROC_TYPE_PLUGIN, _EXTENSION etc.
2019-08-30 18:52:28 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure),
GIMP_PDB_PROC_TYPE_PLUGIN);
libgimp: change GimpPlugIn and GimpProcedures so temp procs work
2019-07-31 03:02:58 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
return priv->proc_type;
libgimp: change GimpPlugIn and GimpProcedures so temp procs work
2019-07-31 03:02:58 +08:00
}
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
/**
* gimp_procedure_set_image_types:
pdb, libgimp: fix various doc issues found by gtk-doc
2019-08-10 17:08:06 +08:00
* @procedure: A #GimpProcedure.
* @image_types: The image types this procedure can operate on.
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
*
* This is a comma separated list of image types, or actually drawable
* types, that this procedure can deal with. Wildcards are possible
* here, so you could say "RGB*" instead of "RGB, RGBA" or "*" for all
* image types.
*
* Supported types are "RGB", "GRAY", "INDEXED" and their variants
* with alpha.
*
* Since: 3.0
**/
void
gimp_procedure_set_image_types (GimpProcedure *procedure,
const gchar *image_types)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
g_return_if_fail (GIMP_IS_PROCEDURE (procedure));
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
pdb: add gimp_pdb_set_proc_image_types() and all the needed code in libgimp/ and app/ to set a plug-in procedure's image types using the new API. Remove the image types from GPProcInstall.
2019-09-08 22:54:08 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_free (priv->image_types);
priv->image_types = g_strdup (image_types);
if (priv->installed)
pdb: add gimp_pdb_set_proc_image_types() and all the needed code in libgimp/ and app/ to set a plug-in procedure's image types using the new API. Remove the image types from GPProcInstall.
2019-09-08 22:54:08 +08:00
_gimp_pdb_set_proc_image_types (gimp_procedure_get_name (procedure),
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->image_types);
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
}
/**
* gimp_procedure_get_image_types:
pdb, libgimp: fix various doc issues found by gtk-doc
2019-08-10 17:08:06 +08:00
* @procedure: A #GimpProcedure.
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
*
pdb, libgimp: fix various doc issues found by gtk-doc
2019-08-10 17:08:06 +08:00
* This function retrieves the list of image types the procedure can
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
* operate on. See gimp_procedure_set_image_types().
*
* Returns: The image types.
*
* Since: 3.0
**/
const gchar *
gimp_procedure_get_image_types (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
return priv->image_types;
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
}
app, libgimp, pdb: new API to advertize when procedures are sensitive. The new function gimp_procedure_set_sensitivity_mask() allows plug-ins to tell when a procedure should be marked as sensitive or not. gimp_procedure_get_sensitivity_mask() retrieves this information. Currently plug-ins are automatically marked as sensitive when an image is present and a single drawable is selected. Nowadays, we can have multiple selected layers so we should allow plug-ins to tell us if they support working on multiple drawables. Actually we could even imagine new plug-ins which would be made to work only on multiple drawables. Oppositely, there are a lot of plug-ins which don't care at all if any drawable is selected at all (so we should allow no drawable selected). Finally why not even imagine plug-ins which don't care if no image is shown? E.g. plug-ins to create new images or whatnot. This new API allows our core to know all this and show procedure sensitivity accordingly. By default, when the function is not called, the 1 image with 1 drawable selected case is the default, allowing existing plug-ins easier update. Note: this only handles the sensitivity part right now. A plug-in which would advertize working on several layer would still not work, because the core won't allow sending several layers. It's coming in further commits.
2021-04-02 05:49:11 +08:00
/**
* gimp_procedure_set_sensitivity_mask:
* @procedure: A #GimpProcedure.
* @sensitivity_mask: A binary mask of #GimpProcedureSensitivityMask.
*
* Sets the case when @procedure is supposed to be sensitive or not.
* Note that it will be used by the core to determine whether to show a
* procedure as sensitive (hence forbid running it otherwise), yet it
* will not forbid thid-party plug-ins for instance to run manually your
* registered procedure. Therefore you should still handle non-supported
* cases appropriately by returning with %GIMP_PDB_EXECUTION_ERROR and a
* suitable error message.
*
* Similarly third-party plug-ins should verify they are allowed to call
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* a procedure with [method@Procedure.get_sensitivity_mask] when running
app, libgimp, pdb: new API to advertize when procedures are sensitive. The new function gimp_procedure_set_sensitivity_mask() allows plug-ins to tell when a procedure should be marked as sensitive or not. gimp_procedure_get_sensitivity_mask() retrieves this information. Currently plug-ins are automatically marked as sensitive when an image is present and a single drawable is selected. Nowadays, we can have multiple selected layers so we should allow plug-ins to tell us if they support working on multiple drawables. Actually we could even imagine new plug-ins which would be made to work only on multiple drawables. Oppositely, there are a lot of plug-ins which don't care at all if any drawable is selected at all (so we should allow no drawable selected). Finally why not even imagine plug-ins which don't care if no image is shown? E.g. plug-ins to create new images or whatnot. This new API allows our core to know all this and show procedure sensitivity accordingly. By default, when the function is not called, the 1 image with 1 drawable selected case is the default, allowing existing plug-ins easier update. Note: this only handles the sensitivity part right now. A plug-in which would advertize working on several layer would still not work, because the core won't allow sending several layers. It's coming in further commits.
2021-04-02 05:49:11 +08:00
* with dynamic contents.
*
* Note that by default, a procedure works on an image with a single
* drawable selected. Hence not setting the mask, setting it with 0 or
* setting it with a mask of %GIMP_PROCEDURE_SENSITIVE_DRAWABLE only are
* equivalent.
*
* Since: 3.0
**/
void
gimp_procedure_set_sensitivity_mask (GimpProcedure *procedure,
gint sensitivity_mask)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
gboolean success = TRUE;
Issue #6767: sensitivity API NO_IMAGE not working in Python. When GIMP_PROCEDURE_SENSITIVE_NO_IMAGE is set on a GimpImageProcedure, add GIMP_PARAM_NO_VALIDATE to the param spec flags, allowing to pass a NULL image.
2021-04-30 05:53:35 +08:00
app, libgimp, pdb: new API to advertize when procedures are sensitive. The new function gimp_procedure_set_sensitivity_mask() allows plug-ins to tell when a procedure should be marked as sensitive or not. gimp_procedure_get_sensitivity_mask() retrieves this information. Currently plug-ins are automatically marked as sensitive when an image is present and a single drawable is selected. Nowadays, we can have multiple selected layers so we should allow plug-ins to tell us if they support working on multiple drawables. Actually we could even imagine new plug-ins which would be made to work only on multiple drawables. Oppositely, there are a lot of plug-ins which don't care at all if any drawable is selected at all (so we should allow no drawable selected). Finally why not even imagine plug-ins which don't care if no image is shown? E.g. plug-ins to create new images or whatnot. This new API allows our core to know all this and show procedure sensitivity accordingly. By default, when the function is not called, the 1 image with 1 drawable selected case is the default, allowing existing plug-ins easier update. Note: this only handles the sensitivity part right now. A plug-in which would advertize working on several layer would still not work, because the core won't allow sending several layers. It's coming in further commits.
2021-04-02 05:49:11 +08:00
g_return_if_fail (GIMP_IS_PROCEDURE (procedure));
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
Issue #6767: sensitivity API NO_IMAGE not working in Python. When GIMP_PROCEDURE_SENSITIVE_NO_IMAGE is set on a GimpImageProcedure, add GIMP_PARAM_NO_VALIDATE to the param spec flags, allowing to pass a NULL image.
2021-04-30 05:53:35 +08:00
if (GIMP_PROCEDURE_GET_CLASS (procedure)->set_sensitivity)
success = GIMP_PROCEDURE_GET_CLASS (procedure)->set_sensitivity (procedure,
sensitivity_mask);
app, libgimp, pdb: new API to advertize when procedures are sensitive. The new function gimp_procedure_set_sensitivity_mask() allows plug-ins to tell when a procedure should be marked as sensitive or not. gimp_procedure_get_sensitivity_mask() retrieves this information. Currently plug-ins are automatically marked as sensitive when an image is present and a single drawable is selected. Nowadays, we can have multiple selected layers so we should allow plug-ins to tell us if they support working on multiple drawables. Actually we could even imagine new plug-ins which would be made to work only on multiple drawables. Oppositely, there are a lot of plug-ins which don't care at all if any drawable is selected at all (so we should allow no drawable selected). Finally why not even imagine plug-ins which don't care if no image is shown? E.g. plug-ins to create new images or whatnot. This new API allows our core to know all this and show procedure sensitivity accordingly. By default, when the function is not called, the 1 image with 1 drawable selected case is the default, allowing existing plug-ins easier update. Note: this only handles the sensitivity part right now. A plug-in which would advertize working on several layer would still not work, because the core won't allow sending several layers. It's coming in further commits.
2021-04-02 05:49:11 +08:00
Issue #6767: sensitivity API NO_IMAGE not working in Python. When GIMP_PROCEDURE_SENSITIVE_NO_IMAGE is set on a GimpImageProcedure, add GIMP_PARAM_NO_VALIDATE to the param spec flags, allowing to pass a NULL image.
2021-04-30 05:53:35 +08:00
if (success)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->sensitivity_mask = sensitivity_mask;
Issue #6767: sensitivity API NO_IMAGE not working in Python. When GIMP_PROCEDURE_SENSITIVE_NO_IMAGE is set on a GimpImageProcedure, add GIMP_PARAM_NO_VALIDATE to the param spec flags, allowing to pass a NULL image.
2021-04-30 05:53:35 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
if (priv->installed)
Issue #6767: sensitivity API NO_IMAGE not working in Python. When GIMP_PROCEDURE_SENSITIVE_NO_IMAGE is set on a GimpImageProcedure, add GIMP_PARAM_NO_VALIDATE to the param spec flags, allowing to pass a NULL image.
2021-04-30 05:53:35 +08:00
_gimp_pdb_set_proc_sensitivity_mask (gimp_procedure_get_name (procedure),
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->sensitivity_mask);
Issue #6767: sensitivity API NO_IMAGE not working in Python. When GIMP_PROCEDURE_SENSITIVE_NO_IMAGE is set on a GimpImageProcedure, add GIMP_PARAM_NO_VALIDATE to the param spec flags, allowing to pass a NULL image.
2021-04-30 05:53:35 +08:00
}
app, libgimp, pdb: new API to advertize when procedures are sensitive. The new function gimp_procedure_set_sensitivity_mask() allows plug-ins to tell when a procedure should be marked as sensitive or not. gimp_procedure_get_sensitivity_mask() retrieves this information. Currently plug-ins are automatically marked as sensitive when an image is present and a single drawable is selected. Nowadays, we can have multiple selected layers so we should allow plug-ins to tell us if they support working on multiple drawables. Actually we could even imagine new plug-ins which would be made to work only on multiple drawables. Oppositely, there are a lot of plug-ins which don't care at all if any drawable is selected at all (so we should allow no drawable selected). Finally why not even imagine plug-ins which don't care if no image is shown? E.g. plug-ins to create new images or whatnot. This new API allows our core to know all this and show procedure sensitivity accordingly. By default, when the function is not called, the 1 image with 1 drawable selected case is the default, allowing existing plug-ins easier update. Note: this only handles the sensitivity part right now. A plug-in which would advertize working on several layer would still not work, because the core won't allow sending several layers. It's coming in further commits.
2021-04-02 05:49:11 +08:00
}
/**
* gimp_procedure_get_sensitivity_mask:
* @procedure: A #GimpProcedure.
*
* Returns: The procedure's sensitivity mask given in
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* [method@Procedure.set_sensitivity_mask].
app, libgimp, pdb: new API to advertize when procedures are sensitive. The new function gimp_procedure_set_sensitivity_mask() allows plug-ins to tell when a procedure should be marked as sensitive or not. gimp_procedure_get_sensitivity_mask() retrieves this information. Currently plug-ins are automatically marked as sensitive when an image is present and a single drawable is selected. Nowadays, we can have multiple selected layers so we should allow plug-ins to tell us if they support working on multiple drawables. Actually we could even imagine new plug-ins which would be made to work only on multiple drawables. Oppositely, there are a lot of plug-ins which don't care at all if any drawable is selected at all (so we should allow no drawable selected). Finally why not even imagine plug-ins which don't care if no image is shown? E.g. plug-ins to create new images or whatnot. This new API allows our core to know all this and show procedure sensitivity accordingly. By default, when the function is not called, the 1 image with 1 drawable selected case is the default, allowing existing plug-ins easier update. Note: this only handles the sensitivity part right now. A plug-in which would advertize working on several layer would still not work, because the core won't allow sending several layers. It's coming in further commits.
2021-04-02 05:49:11 +08:00
*
* Since: 3.0
**/
gint
gimp_procedure_get_sensitivity_mask (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
app, libgimp, pdb: new API to advertize when procedures are sensitive. The new function gimp_procedure_set_sensitivity_mask() allows plug-ins to tell when a procedure should be marked as sensitive or not. gimp_procedure_get_sensitivity_mask() retrieves this information. Currently plug-ins are automatically marked as sensitive when an image is present and a single drawable is selected. Nowadays, we can have multiple selected layers so we should allow plug-ins to tell us if they support working on multiple drawables. Actually we could even imagine new plug-ins which would be made to work only on multiple drawables. Oppositely, there are a lot of plug-ins which don't care at all if any drawable is selected at all (so we should allow no drawable selected). Finally why not even imagine plug-ins which don't care if no image is shown? E.g. plug-ins to create new images or whatnot. This new API allows our core to know all this and show procedure sensitivity accordingly. By default, when the function is not called, the 1 image with 1 drawable selected case is the default, allowing existing plug-ins easier update. Note: this only handles the sensitivity part right now. A plug-in which would advertize working on several layer would still not work, because the core won't allow sending several layers. It's coming in further commits.
2021-04-02 05:49:11 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), 0);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
return priv->sensitivity_mask;
app, libgimp, pdb: new API to advertize when procedures are sensitive. The new function gimp_procedure_set_sensitivity_mask() allows plug-ins to tell when a procedure should be marked as sensitive or not. gimp_procedure_get_sensitivity_mask() retrieves this information. Currently plug-ins are automatically marked as sensitive when an image is present and a single drawable is selected. Nowadays, we can have multiple selected layers so we should allow plug-ins to tell us if they support working on multiple drawables. Actually we could even imagine new plug-ins which would be made to work only on multiple drawables. Oppositely, there are a lot of plug-ins which don't care at all if any drawable is selected at all (so we should allow no drawable selected). Finally why not even imagine plug-ins which don't care if no image is shown? E.g. plug-ins to create new images or whatnot. This new API allows our core to know all this and show procedure sensitivity accordingly. By default, when the function is not called, the 1 image with 1 drawable selected case is the default, allowing existing plug-ins easier update. Note: this only handles the sensitivity part right now. A plug-in which would advertize working on several layer would still not work, because the core won't allow sending several layers. It's coming in further commits.
2021-04-02 05:49:11 +08:00
}
libgimp: add gimp_procedure_set_menu_label() and _set_documentation() which replace _set_strings(). Add more docs.
2019-08-02 06:56:00 +08:00
/**
* gimp_procedure_set_menu_label:
* @procedure: A #GimpProcedure.
* @menu_label: The @procedure's menu label.
*
* Sets the label to use for the @procedure's menu entry, The
* location(s) where to register in the menu hierarchy is chosen using
* gimp_procedure_add_menu_path().
*
libgimp: remove outdated recommendation about sending non-localized strings. gimp_plug_in_set_translation_domain() was removed in GIMP 2.99.12. Plug-ins are now fully responsible for their own localization.
2023-07-22 22:17:24 +08:00
* Plug-ins are responsible for their own translations. You are expected to send
* localized strings to GIMP if your plug-in is internationalized.
libgimp: add gimp_procedure_set_menu_label() and _set_documentation() which replace _set_strings(). Add more docs.
2019-08-02 06:56:00 +08:00
*
* Since: 3.0
**/
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
void
libgimp: add gimp_procedure_set_menu_label() and _set_documentation() which replace _set_strings(). Add more docs.
2019-08-02 06:56:00 +08:00
gimp_procedure_set_menu_label (GimpProcedure *procedure,
const gchar *menu_label)
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
g_return_if_fail (GIMP_IS_PROCEDURE (procedure));
pdb: add gimp_pdb_set_proc_menu_label() and all the needed code in libgimp/ and app/ to set a plug-in procedure's menu label using the new API. Remove the menu label from GPProcInstall.
2019-09-08 23:30:54 +08:00
g_return_if_fail (menu_label != NULL && strlen (menu_label));
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
g_clear_pointer (&priv->menu_label, g_free);
priv->menu_label = g_strdup (menu_label);
pdb: add gimp_pdb_set_proc_menu_label() and all the needed code in libgimp/ and app/ to set a plug-in procedure's menu label using the new API. Remove the menu label from GPProcInstall.
2019-09-08 23:30:54 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
if (priv->installed)
pdb: add gimp_pdb_set_proc_menu_label() and all the needed code in libgimp/ and app/ to set a plug-in procedure's menu label using the new API. Remove the menu label from GPProcInstall.
2019-09-08 23:30:54 +08:00
_gimp_pdb_set_proc_menu_label (gimp_procedure_get_name (procedure),
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->menu_label);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
}
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
/**
* gimp_procedure_get_menu_label:
* @procedure: A #GimpProcedure.
*
* Returns: The procedure's menu label given in
libgimp: fix various docs typos or small errors.
2019-08-02 08:30:07 +08:00
* gimp_procedure_set_menu_label().
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
*
* Since: 3.0
**/
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
const gchar *
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
gimp_procedure_get_menu_label (GimpProcedure *procedure)
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
return priv->menu_label;
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
}
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
/**
* gimp_procedure_add_menu_path:
* @procedure: A #GimpProcedure.
* @menu_path: The @procedure's additional menu path.
*
libgimp/ documentation typo fixes Found via `codespell -i 3 -w -S ./ChangeLog*,*.po -I ../gimp-word-whitelist.txt ./libgimp`
2019-08-20 08:52:05 +08:00
* Adds a menu path to the procedure. Only procedures which have a menu
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
* label can add a menu path.
*
libgimp: improve gimp_procedure_add_menu_path() docs regarding localization. This was the last remaining bit in #8124. Basically I needed to check how localization of menu paths worked. I was thinking of maybe have 2 arguments to gimp_procedure_add_menu_path(), one non-localized (for default menu paths) and one localized by the plug-in (for custom menus). That would break all plug-ins, but also looking at our code, it's complicated to do right. Instead let's just keep current API and add an example in function docs. We'll see how we can improve the API if the very hypothetical problem I am foreseeing actually happens some day: say a word in English translates to e.g. "Filters" in some other language, whereas English "Filters" translates to yet another term; in such case, this new menu would still merge with the default /Filters/ menu when localized in this language, so we'd have the weird situation where the custom menu label would have passed through 2 translations somehow. But let's see how it goes. If we really need, in the future, we can deprecate gimp_procedure_add_menu_path() and add a gimp_procedure_add_menu_paths() with a base_path and a custom_path, while the custom_path would be expected to be already translated.
2022-10-26 06:39:40 +08:00
* Menu paths are untranslated paths to known menus and submenus with the
* syntax `<Prefix>/Path/To/Submenu`, for example `<Image>/Layer/Transform`.
* GIMP will localize these.
* Nevertheless you should localize unknown parts of the path. For instance, say
* you want to create procedure to create customized layers and add a `Create`
* submenu which you want to localize from your plug-in with gettext. You could
* call:
*
libgimp: update function's documentation.
2023-07-14 23:02:19 +08:00
* ```C
* path = g_build_path ("/", "<Image>/Layer", _("Create"), NULL);
* gimp_procedure_add_menu_path (procedure, path);
* g_free (path);
libgimp: improve gimp_procedure_add_menu_path() docs regarding localization. This was the last remaining bit in #8124. Basically I needed to check how localization of menu paths worked. I was thinking of maybe have 2 arguments to gimp_procedure_add_menu_path(), one non-localized (for default menu paths) and one localized by the plug-in (for custom menus). That would break all plug-ins, but also looking at our code, it's complicated to do right. Instead let's just keep current API and add an example in function docs. We'll see how we can improve the API if the very hypothetical problem I am foreseeing actually happens some day: say a word in English translates to e.g. "Filters" in some other language, whereas English "Filters" translates to yet another term; in such case, this new menu would still merge with the default /Filters/ menu when localized in this language, so we'd have the weird situation where the custom menu label would have passed through 2 translations somehow. But let's see how it goes. If we really need, in the future, we can deprecate gimp_procedure_add_menu_path() and add a gimp_procedure_add_menu_paths() with a base_path and a custom_path, while the custom_path would be expected to be already translated.
2022-10-26 06:39:40 +08:00
* ```
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
*
* See also: gimp_plug_in_add_menu_branch().
*
libgimp: update function's documentation.
2023-07-14 23:02:19 +08:00
* GIMP menus also have a concept of named section. For instance, say you are
* creating a plug-in which you want to show next to the "Export", "Export As"
* plug-ins in the File menu. You would add it to the menu path "File/[Export]".
* If you actually wanted to create a submenu called "[Export]" (with square
* brackets), double the brackets: "File/[[Export]]"
*
* See also: https://gitlab.gnome.org/GNOME/gimp/-/blob/master/menus/image-menu.ui.in.in
*
* This function will place your procedure to the bottom of the selected path or
* section. Order is not assured relatively to other plug-ins.
*
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
* Since: 3.0
**/
void
gimp_procedure_add_menu_path (GimpProcedure *procedure,
const gchar *menu_path)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
g_return_if_fail (GIMP_IS_PROCEDURE (procedure));
g_return_if_fail (menu_path != NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
libgimp: allow to call gimp_procedure_add_menu_path() on installed procs Adding menu paths must be possible even after the procedure has been installed, script-fu registers all menu paths afer installing its procedures so they are properly sorted.
2019-08-13 01:06:13 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_return_if_fail (priv->menu_label != NULL);
priv->menu_paths = g_list_append (priv->menu_paths, g_strdup (menu_path));
if (priv->installed)
pdb: move gimp_plugin_menu_register() from the "plugin" to the "pdb" group and call it gimp_pdb_add_proc_menu_path(). Move around and rename some code in app/ to prepare for more procedure setters to work this way.
2019-09-08 21:53:37 +08:00
_gimp_pdb_add_proc_menu_path (gimp_procedure_get_name (procedure),
menu_path);
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
}
/**
* gimp_procedure_get_menu_paths:
* @procedure: A #GimpProcedure.
*
* Returns: (transfer none) (element-type gchar*): the @procedure's
* menu paths as added with gimp_procedure_add_menu_path().
*
* Since: 3.0
**/
GList *
gimp_procedure_get_menu_paths (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
return priv->menu_paths;
libgimp: reorder functions and members of GimpProcedure to make more sense, as long as the file has little git history.
2019-08-06 05:01:25 +08:00
}
libgimp: move the GimpProcedure icon API next to the menu API
2019-08-18 20:04:45 +08:00
/**
* gimp_procedure_set_icon_name:
* @procedure: a #GimpProcedure.
* @icon_name: (nullable): an icon name.
*
* Sets the icon for @procedure to the icon referenced by @icon_name.
*
* Since: 3.0
*/
void
gimp_procedure_set_icon_name (GimpProcedure *procedure,
const gchar *icon_name)
{
g_return_if_fail (GIMP_IS_PROCEDURE (procedure));
gimp_procedure_set_icon (procedure,
GIMP_ICON_TYPE_ICON_NAME,
icon_name);
}
/**
* gimp_procedure_set_icon_pixbuf:
* @procedure: a #GimpProcedure.
* @pixbuf: (nullable): a #GdkPixbuf.
*
* Sets the icon for @procedure to @pixbuf.
*
* Since: 3.0
*/
void
gimp_procedure_set_icon_pixbuf (GimpProcedure *procedure,
GdkPixbuf *pixbuf)
{
g_return_if_fail (GIMP_IS_PROCEDURE (procedure));
g_return_if_fail (pixbuf == NULL || GDK_IS_PIXBUF (pixbuf));
gimp_procedure_set_icon (procedure,
GIMP_ICON_TYPE_PIXBUF,
pixbuf);
}
/**
* gimp_procedure_set_icon_file:
* @procedure: a #GimpProcedure.
* @file: (nullable): a #GFile pointing to an image file.
*
* Sets the icon for @procedure to the contents of an image file.
*
* Since: 3.0
*/
void
gimp_procedure_set_icon_file (GimpProcedure *procedure,
GFile *file)
{
g_return_if_fail (GIMP_IS_PROCEDURE (procedure));
g_return_if_fail (file == NULL || G_IS_FILE (file));
gimp_procedure_set_icon (procedure,
GIMP_ICON_TYPE_IMAGE_FILE,
file);
}
/**
* gimp_procedure_get_icon_type:
* @procedure: a #GimpProcedure.
*
* Gets the type of data set as @procedure's icon. Depending on the
* result, you can call the relevant specific function, such as
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* [method@Procedure.get_icon_name].
libgimp: move the GimpProcedure icon API next to the menu API
2019-08-18 20:04:45 +08:00
*
* Returns: the #GimpIconType of @procedure's icon.
*
* Since: 3.0
*/
GimpIconType
gimp_procedure_get_icon_type (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
libgimp: move the GimpProcedure icon API next to the menu API
2019-08-18 20:04:45 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), -1);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
return priv->icon_type;
libgimp: move the GimpProcedure icon API next to the menu API
2019-08-18 20:04:45 +08:00
}
/**
* gimp_procedure_get_icon_name:
* @procedure: a #GimpProcedure.
*
* Gets the name of the icon if one was set for @procedure.
*
* Returns: (nullable): the icon name or %NULL if no icon name was set.
*
* Since: 3.0
*/
const gchar *
gimp_procedure_get_icon_name (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
priv = gimp_procedure_get_instance_private (procedure);
libgimp: move the GimpProcedure icon API next to the menu API
2019-08-18 20:04:45 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
if (priv->icon_type == GIMP_ICON_TYPE_ICON_NAME)
return (const gchar *) priv->icon_data;
libgimp: move the GimpProcedure icon API next to the menu API
2019-08-18 20:04:45 +08:00
return NULL;
}
/**
* gimp_procedure_get_icon_file:
* @procedure: a #GimpProcedure.
*
* Gets the file of the icon if one was set for @procedure.
*
* Returns: (nullable) (transfer none): the icon #GFile or %NULL if no
* file was set.
*
* Since: 3.0
*/
GFile *
gimp_procedure_get_icon_file (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
priv = gimp_procedure_get_instance_private (procedure);
libgimp: move the GimpProcedure icon API next to the menu API
2019-08-18 20:04:45 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
if (priv->icon_type == GIMP_ICON_TYPE_IMAGE_FILE)
return (GFile *) priv->icon_data;
libgimp: move the GimpProcedure icon API next to the menu API
2019-08-18 20:04:45 +08:00
return NULL;
}
/**
* gimp_procedure_get_icon_pixbuf:
* @procedure: a #GimpProcedure.
*
* Gets the #GdkPixbuf of the icon if an icon was set this way for
* @procedure.
*
* Returns: (nullable) (transfer none): the icon pixbuf or %NULL if no
* icon name was set.
*
* Since: 3.0
*/
GdkPixbuf *
gimp_procedure_get_icon_pixbuf (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
priv = gimp_procedure_get_instance_private (procedure);
libgimp: move the GimpProcedure icon API next to the menu API
2019-08-18 20:04:45 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
if (priv->icon_type == GIMP_ICON_TYPE_PIXBUF)
return (GdkPixbuf *) priv->icon_data;
libgimp: move the GimpProcedure icon API next to the menu API
2019-08-18 20:04:45 +08:00
return NULL;
}
libgimp: add gimp_procedure_set_menu_label() and _set_documentation() which replace _set_strings(). Add more docs.
2019-08-02 06:56:00 +08:00
/**
* gimp_procedure_set_documentation:
Issue #9655: both @blurb and @help arguments should be localized. Looking further, the @help is only used in gimp_proc_view_new() so far (for the Procedure Browser) where the blurb and argument descriptions are already localized. It makes no sense to only keep this in English. So let's ask to have both arguments translated. Now clearly we should not ask for @help to be mandatory. Very often, it makes no sense to have a longer help string (the small blurb and the few arguments may be very self-explanatory). So I make this argument nullable. There is only the @help_id which I wonder if we could not have a simpler function gimp_procedure_set_documentation_uri(). Indeed while having a unified infrastructure with a XML summary and help IDs and whatelse makes sense for GIMP as a whole, I think that many third-party plug-ins would work much better with a very simple direct URL. Or it could even be a GFile to a local file (for plug-ins which want to embed their documentation in the plug-in folder for instance). To be continued…
2023-07-28 04:59:51 +08:00
* @procedure: A #GimpProcedure.
* @blurb: The @procedure's blurb.
* @help: (nullable): The @procedure's help text.
* @help_id: (nullable): The @procedure's help ID.
libgimp: add gimp_procedure_set_menu_label() and _set_documentation() which replace _set_strings(). Add more docs.
2019-08-02 06:56:00 +08:00
*
Issue #9655: both @blurb and @help arguments should be localized. Looking further, the @help is only used in gimp_proc_view_new() so far (for the Procedure Browser) where the blurb and argument descriptions are already localized. It makes no sense to only keep this in English. So let's ask to have both arguments translated. Now clearly we should not ask for @help to be mandatory. Very often, it makes no sense to have a longer help string (the small blurb and the few arguments may be very self-explanatory). So I make this argument nullable. There is only the @help_id which I wonder if we could not have a simpler function gimp_procedure_set_documentation_uri(). Indeed while having a unified infrastructure with a XML summary and help IDs and whatelse makes sense for GIMP as a whole, I think that many third-party plug-ins would work much better with a very simple direct URL. Or it could even be a GFile to a local file (for plug-ins which want to embed their documentation in the plug-in folder for instance). To be continued…
2023-07-28 04:59:51 +08:00
* Sets various documentation strings on @procedure:
libgimp: add gimp_procedure_set_menu_label() and _set_documentation() which replace _set_strings(). Add more docs.
2019-08-02 06:56:00 +08:00
*
Issue #9655: both @blurb and @help arguments should be localized. Looking further, the @help is only used in gimp_proc_view_new() so far (for the Procedure Browser) where the blurb and argument descriptions are already localized. It makes no sense to only keep this in English. So let's ask to have both arguments translated. Now clearly we should not ask for @help to be mandatory. Very often, it makes no sense to have a longer help string (the small blurb and the few arguments may be very self-explanatory). So I make this argument nullable. There is only the @help_id which I wonder if we could not have a simpler function gimp_procedure_set_documentation_uri(). Indeed while having a unified infrastructure with a XML summary and help IDs and whatelse makes sense for GIMP as a whole, I think that many third-party plug-ins would work much better with a very simple direct URL. Or it could even be a GFile to a local file (for plug-ins which want to embed their documentation in the plug-in folder for instance). To be continued…
2023-07-28 04:59:51 +08:00
* * @blurb is used for instance as the @procedure's tooltip when represented in
* the UI such as a menu entry.
* * @help is a free-form text that's meant as additional documentation for
* developers of scripts and plug-ins. If the @blurb and the argument names
* and descriptions are enough for a quite self-explanatory procedure, you may
* set @help to %NULL, rather than setting an uninformative @help (avoid
* setting the same text as @blurb or redundant information).
libgimp: add gimp_procedure_set_menu_label() and _set_documentation() which replace _set_strings(). Add more docs.
2019-08-02 06:56:00 +08:00
*
Issue #9655: both @blurb and @help arguments should be localized. Looking further, the @help is only used in gimp_proc_view_new() so far (for the Procedure Browser) where the blurb and argument descriptions are already localized. It makes no sense to only keep this in English. So let's ask to have both arguments translated. Now clearly we should not ask for @help to be mandatory. Very often, it makes no sense to have a longer help string (the small blurb and the few arguments may be very self-explanatory). So I make this argument nullable. There is only the @help_id which I wonder if we could not have a simpler function gimp_procedure_set_documentation_uri(). Indeed while having a unified infrastructure with a XML summary and help IDs and whatelse makes sense for GIMP as a whole, I think that many third-party plug-ins would work much better with a very simple direct URL. Or it could even be a GFile to a local file (for plug-ins which want to embed their documentation in the plug-in folder for instance). To be continued…
2023-07-28 04:59:51 +08:00
* Plug-ins are responsible for their own translations. You are expected to send
* localized strings of @blurb and @help to GIMP if your plug-in is
* internationalized.
libgimp: add gimp_procedure_set_menu_label() and _set_documentation() which replace _set_strings(). Add more docs.
2019-08-02 06:56:00 +08:00
*
* Since: 3.0
**/
void
gimp_procedure_set_documentation (GimpProcedure *procedure,
const gchar *blurb,
const gchar *help,
const gchar *help_id)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
priv = gimp_procedure_get_instance_private (procedure);
libgimp: add gimp_procedure_set_menu_label() and _set_documentation() which replace _set_strings(). Add more docs.
2019-08-02 06:56:00 +08:00
g_return_if_fail (GIMP_IS_PROCEDURE (procedure));
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
g_clear_pointer (&priv->blurb, g_free);
g_clear_pointer (&priv->help, g_free);
g_clear_pointer (&priv->help_id, g_free);
libgimp: add gimp_procedure_set_menu_label() and _set_documentation() which replace _set_strings(). Add more docs.
2019-08-02 06:56:00 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->blurb = g_strdup (blurb);
priv->help = g_strdup (help);
priv->help_id = g_strdup (help_id);
pdb: add gimp_pdb_set_proc_documentation() and _attribution() and all the needed code in libgimp/ and app/ to set them on a procedure using the new API. Remove the strings from GPProcInstall.
2019-09-09 06:36:24 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
if (priv->installed)
pdb: add gimp_pdb_set_proc_documentation() and _attribution() and all the needed code in libgimp/ and app/ to set them on a procedure using the new API. Remove the strings from GPProcInstall.
2019-09-09 06:36:24 +08:00
_gimp_pdb_set_proc_documentation (gimp_procedure_get_name (procedure),
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->blurb,
priv->help,
priv->help_id);
libgimp: add gimp_procedure_set_menu_label() and _set_documentation() which replace _set_strings(). Add more docs.
2019-08-02 06:56:00 +08:00
}
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
/**
* gimp_procedure_get_blurb:
* @procedure: A #GimpProcedure.
*
libgimp: fix various docs typos or small errors.
2019-08-02 08:30:07 +08:00
* Returns: The procedure's blurb given in
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* [method@Procedure.set_documentation].
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
*
* Since: 3.0
**/
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
const gchar *
gimp_procedure_get_blurb (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
priv = gimp_procedure_get_instance_private (procedure);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
return priv->blurb;
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
}
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
/**
* gimp_procedure_get_help:
* @procedure: A #GimpProcedure.
*
* Returns: The procedure's help text given in
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* [method@Procedure.set_documentation].
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
*
* Since: 3.0
**/
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
const gchar *
gimp_procedure_get_help (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
priv = gimp_procedure_get_instance_private (procedure);
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
return priv->help;
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
}
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
/**
* gimp_procedure_get_help_id:
* @procedure: A #GimpProcedure.
*
* Returns: The procedure's help ID given in
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* [method@Procedure.set_documentation].
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
*
* Since: 3.0
**/
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
const gchar *
gimp_procedure_get_help_id (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
priv = gimp_procedure_get_instance_private (procedure);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
return priv->help_id;
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
}
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
/**
* gimp_procedure_set_attribution:
* @procedure: A #GimpProcedure.
* @authors: The @procedure's author(s).
* @copyright: The @procedure's copyright.
libgimp: fix various docs typos or small errors.
2019-08-02 08:30:07 +08:00
* @date: The @procedure's date (written or published).
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
*
* Sets various attribution strings on @procedure.
*
* Since: 3.0
**/
void
gimp_procedure_set_attribution (GimpProcedure *procedure,
const gchar *authors,
const gchar *copyright,
const gchar *date)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
priv = gimp_procedure_get_instance_private (procedure);
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
g_return_if_fail (GIMP_IS_PROCEDURE (procedure));
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
g_free (priv->authors);
g_free (priv->copyright);
g_free (priv->date);
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->authors = g_strdup (authors);
priv->copyright = g_strdup (copyright);
priv->date = g_strdup (date);
pdb: add gimp_pdb_set_proc_documentation() and _attribution() and all the needed code in libgimp/ and app/ to set them on a procedure using the new API. Remove the strings from GPProcInstall.
2019-09-09 06:36:24 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
if (priv->installed)
pdb: add gimp_pdb_set_proc_documentation() and _attribution() and all the needed code in libgimp/ and app/ to set them on a procedure using the new API. Remove the strings from GPProcInstall.
2019-09-09 06:36:24 +08:00
_gimp_pdb_set_proc_attribution (gimp_procedure_get_name (procedure),
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->authors,
priv->copyright,
priv->date);
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
}
/**
libgimp*: various doc fixes
2019-08-10 18:32:25 +08:00
* gimp_procedure_get_authors:
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
* @procedure: A #GimpProcedure.
*
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* Returns: The procedure's authors given in [method@Procedure.set_attribution].
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
*
* Since: 3.0
**/
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
const gchar *
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
gimp_procedure_get_authors (GimpProcedure *procedure)
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
priv = gimp_procedure_get_instance_private (procedure);
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
return priv->authors;
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
}
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
/**
* gimp_procedure_get_copyright:
* @procedure: A #GimpProcedure.
*
* Returns: The procedure's copyright given in
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* [method@Procedure.set_attribution].
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
*
* Since: 3.0
**/
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
const gchar *
gimp_procedure_get_copyright (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
priv = gimp_procedure_get_instance_private (procedure);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
return priv->copyright;
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
}
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
/**
* gimp_procedure_get_date:
* @procedure: A #GimpProcedure.
*
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* Returns: The procedure's date given in [method@Procedure.set_attribution].
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
*
* Since: 3.0
**/
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
const gchar *
gimp_procedure_get_date (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
priv = gimp_procedure_get_instance_private (procedure);
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
return priv->date;
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
}
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp, libgimpbase: add some documentation for new functions. Just for a few of them just now as I needed these for my binding plug-in tests, and without the proper annotations, these functions were unavailable.
2019-08-01 17:57:17 +08:00
/**
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-06 04:29:35 +08:00
* _gimp_procedure_add_argument:
libgimp, libgimpbase: add some documentation for new functions. Just for a few of them just now as I needed these for my binding plug-in tests, and without the proper annotations, these functions were unavailable.
2019-08-01 17:57:17 +08:00
* @procedure: the #GimpProcedure.
libgimp: do not return a possibly invalid pointer. Fixes the patch from !470 which is mostly right, except that g_param_spec_sink() may possibly lead to finalizing the GParamSpec (typically if it was a just-created floating spec). We don't want to return pointer to freed data. Let's return NULL instead. Also looking closer at the memory handling here, it looks the right annotation for @pspec is (transfer floating). Basically we are sinking a floating object into a full object and taking ownership of this sunk object. But if the object was already sunk, we are reffing it and keeping this additional reference, not the passed argument's. Hopefully it's right since the annotation and handling of floating object with GObject Introspection seems very unclear to me (even in core GObject code, I see what looks like contradictory annotations).
2021-10-13 00:45:50 +08:00
* @pspec: (transfer floating): the argument specification.
libgimp, libgimpbase: add some documentation for new functions. Just for a few of them just now as I needed these for my binding plug-in tests, and without the proper annotations, these functions were unavailable.
2019-08-01 17:57:17 +08:00
*
* Add a new argument to @procedure according to @pspec specifications.
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-06 04:29:35 +08:00
* The arguments will be ordered according to the calls order.
libgimp: remove includes and add "Since: 3.0" in gimpprocecure.c
2019-08-06 05:33:49 +08:00
*
libgimp: do not return a possibly invalid pointer. Fixes the patch from !470 which is mostly right, except that g_param_spec_sink() may possibly lead to finalizing the GParamSpec (typically if it was a just-created floating spec). We don't want to return pointer to freed data. Let's return NULL instead. Also looking closer at the memory handling here, it looks the right annotation for @pspec is (transfer floating). Basically we are sinking a floating object into a full object and taking ownership of this sunk object. But if the object was already sunk, we are reffing it and keeping this additional reference, not the passed argument's. Hopefully it's right since the annotation and handling of floating object with GObject Introspection seems very unclear to me (even in core GObject code, I see what looks like contradictory annotations).
2021-10-13 00:45:50 +08:00
* If @pspec is floating, ownership will be taken over by @procedure,
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* allowing to pass directly `g*_param_spec_*()` calls as arguments.
libgimp: do not return a possibly invalid pointer. Fixes the patch from !470 which is mostly right, except that g_param_spec_sink() may possibly lead to finalizing the GParamSpec (typically if it was a just-created floating spec). We don't want to return pointer to freed data. Let's return NULL instead. Also looking closer at the memory handling here, it looks the right annotation for @pspec is (transfer floating). Basically we are sinking a floating object into a full object and taking ownership of this sunk object. But if the object was already sunk, we are reffing it and keeping this additional reference, not the passed argument's. Hopefully it's right since the annotation and handling of floating object with GObject Introspection seems very unclear to me (even in core GObject code, I see what looks like contradictory annotations).
2021-10-13 00:45:50 +08:00
*
* Returns: (transfer none): the same @pspec or %NULL in case of error.
libgimp: return the added GParamSpec from all GimpProcedure... ...functions which add arguments or return values. So code can do stuff with them without an additional lookup call.
2020-06-12 18:15:22 +08:00
*
libgimp: remove includes and add "Since: 3.0" in gimpprocecure.c
2019-08-06 05:33:49 +08:00
* Since: 3.0
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
**/
libgimp: return the added GParamSpec from all GimpProcedure... ...functions which add arguments or return values. So code can do stuff with them without an additional lookup call.
2020-06-12 18:15:22 +08:00
GParamSpec *
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-06 04:29:35 +08:00
_gimp_procedure_add_argument (GimpProcedure *procedure,
GParamSpec *pspec)
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
priv = gimp_procedure_get_instance_private (procedure);
libgimp: return the added GParamSpec from all GimpProcedure... ...functions which add arguments or return values. So code can do stuff with them without an additional lookup call.
2020-06-12 18:15:22 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
g_return_val_if_fail (G_IS_PARAM_SPEC (pspec), NULL);
g_return_val_if_fail (gimp_is_canonical_identifier (pspec->name), NULL);
libgimp: GimpProcedure args and return values must have have unique and canonical names now.
2019-09-03 00:53:30 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
libgimp: add gimp_procedure_find_argument(), aux_argument(), return_value()
2019-10-12 18:49:32 +08:00
if (gimp_procedure_find_argument (procedure, pspec->name))
{
g_warning ("Argument with name '%s' already exists on procedure '%s'",
pspec->name,
gimp_procedure_get_name (procedure));
libgimp: fix pspec leak when procedure argument has already been specified In the normal flow, pspec is persisted in the arguments array, and is g_param_spec_ref_sink()'d in order to sink a possible floating ref. To avoid a leak in the error case, we need to add some g_param_spec_sink().
2021-08-27 23:54:33 +08:00
g_param_spec_sink (pspec);
libgimp: do not return a possibly invalid pointer. Fixes the patch from !470 which is mostly right, except that g_param_spec_sink() may possibly lead to finalizing the GParamSpec (typically if it was a just-created floating spec). We don't want to return pointer to freed data. Let's return NULL instead. Also looking closer at the memory handling here, it looks the right annotation for @pspec is (transfer floating). Basically we are sinking a floating object into a full object and taking ownership of this sunk object. But if the object was already sunk, we are reffing it and keeping this additional reference, not the passed argument's. Hopefully it's right since the annotation and handling of floating object with GObject Introspection seems very unclear to me (even in core GObject code, I see what looks like contradictory annotations).
2021-10-13 00:45:50 +08:00
return NULL;
libgimp: add gimp_procedure_find_argument(), aux_argument(), return_value()
2019-10-12 18:49:32 +08:00
}
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: add gimp_procedure_find_argument(), aux_argument(), return_value()
2019-10-12 18:49:32 +08:00
if (gimp_procedure_find_aux_argument (procedure, pspec->name))
{
g_warning ("Auxiliary argument with name '%s' already exists "
"on procedure '%s'",
pspec->name,
gimp_procedure_get_name (procedure));
libgimp: fix pspec leak when procedure argument has already been specified In the normal flow, pspec is persisted in the arguments array, and is g_param_spec_ref_sink()'d in order to sink a possible floating ref. To avoid a leak in the error case, we need to add some g_param_spec_sink().
2021-08-27 23:54:33 +08:00
g_param_spec_sink (pspec);
libgimp: do not return a possibly invalid pointer. Fixes the patch from !470 which is mostly right, except that g_param_spec_sink() may possibly lead to finalizing the GParamSpec (typically if it was a just-created floating spec). We don't want to return pointer to freed data. Let's return NULL instead. Also looking closer at the memory handling here, it looks the right annotation for @pspec is (transfer floating). Basically we are sinking a floating object into a full object and taking ownership of this sunk object. But if the object was already sunk, we are reffing it and keeping this additional reference, not the passed argument's. Hopefully it's right since the annotation and handling of floating object with GObject Introspection seems very unclear to me (even in core GObject code, I see what looks like contradictory annotations).
2021-10-13 00:45:50 +08:00
return NULL;
libgimp: add gimp_procedure_find_argument(), aux_argument(), return_value()
2019-10-12 18:49:32 +08:00
}
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->args = g_renew (GParamSpec *, priv->args,
priv->n_args + 1);
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->args[priv->n_args] = pspec;
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
g_param_spec_ref_sink (pspec);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->n_args++;
libgimp: return the added GParamSpec from all GimpProcedure... ...functions which add arguments or return values. So code can do stuff with them without an additional lookup call.
2020-06-12 18:15:22 +08:00
return pspec;
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
}
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
/**
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-06 04:29:35 +08:00
* _gimp_procedure_add_aux_argument:
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
* @procedure: the #GimpProcedure.
* @pspec: (transfer full): the argument specification.
*
* Add a new auxiliary argument to @procedure according to @pspec
* specifications.
*
* Auxiliary arguments are not passed to the @procedure in run() and
* are not known to the PDB. They are however members of the
* #GimpProcedureConfig created by gimp_procedure_create_config() and
* can be used to persistently store whatever last used values the
* @procedure wants to remember across invocations
*
libgimp: return the added GParamSpec from all GimpProcedure... ...functions which add arguments or return values. So code can do stuff with them without an additional lookup call.
2020-06-12 18:15:22 +08:00
* Returns: (transfer none): the same @pspec.
*
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
* Since: 3.0
**/
libgimp: return the added GParamSpec from all GimpProcedure... ...functions which add arguments or return values. So code can do stuff with them without an additional lookup call.
2020-06-12 18:15:22 +08:00
GParamSpec *
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-06 04:29:35 +08:00
_gimp_procedure_add_aux_argument (GimpProcedure *procedure,
GParamSpec *pspec)
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
libgimp: return the added GParamSpec from all GimpProcedure... ...functions which add arguments or return values. So code can do stuff with them without an additional lookup call.
2020-06-12 18:15:22 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), pspec);
g_return_val_if_fail (G_IS_PARAM_SPEC (pspec), pspec);
g_return_val_if_fail (gimp_is_canonical_identifier (pspec->name), pspec);
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
libgimp: add gimp_procedure_find_argument(), aux_argument(), return_value()
2019-10-12 18:49:32 +08:00
if (gimp_procedure_find_argument (procedure, pspec->name))
{
g_warning ("Argument with name '%s' already exists on procedure '%s'",
pspec->name,
gimp_procedure_get_name (procedure));
libgimp: return the added GParamSpec from all GimpProcedure... ...functions which add arguments or return values. So code can do stuff with them without an additional lookup call.
2020-06-12 18:15:22 +08:00
return pspec;
libgimp: add gimp_procedure_find_argument(), aux_argument(), return_value()
2019-10-12 18:49:32 +08:00
}
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
libgimp: add gimp_procedure_find_argument(), aux_argument(), return_value()
2019-10-12 18:49:32 +08:00
if (gimp_procedure_find_aux_argument (procedure, pspec->name))
{
g_warning ("Auxiliary argument with name '%s' already exists "
"on procedure '%s'",
pspec->name,
gimp_procedure_get_name (procedure));
libgimp: return the added GParamSpec from all GimpProcedure... ...functions which add arguments or return values. So code can do stuff with them without an additional lookup call.
2020-06-12 18:15:22 +08:00
return pspec;
libgimp: add gimp_procedure_find_argument(), aux_argument(), return_value()
2019-10-12 18:49:32 +08:00
}
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->aux_args = g_renew (GParamSpec *, priv->aux_args,
priv->n_aux_args + 1);
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->aux_args[priv->n_aux_args] = pspec;
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
g_param_spec_ref_sink (pspec);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->n_aux_args++;
libgimp: return the added GParamSpec from all GimpProcedure... ...functions which add arguments or return values. So code can do stuff with them without an additional lookup call.
2020-06-12 18:15:22 +08:00
return pspec;
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
}
libgimp, libgimpbase: add some documentation for new functions. Just for a few of them just now as I needed these for my binding plug-in tests, and without the proper annotations, these functions were unavailable.
2019-08-01 17:57:17 +08:00
/**
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-06 04:29:35 +08:00
* _gimp_procedure_add_return_value:
libgimp, libgimpbase: add some documentation for new functions. Just for a few of them just now as I needed these for my binding plug-in tests, and without the proper annotations, these functions were unavailable.
2019-08-01 17:57:17 +08:00
* @procedure: the #GimpProcedure.
libgimp: fix annotation for gimp_procedure_add_argument() and _add_return_value(), the GParamSpecs are (transfer full).
2019-08-01 18:58:39 +08:00
* @pspec: (transfer full): the return value specification.
libgimp, libgimpbase: add some documentation for new functions. Just for a few of them just now as I needed these for my binding plug-in tests, and without the proper annotations, these functions were unavailable.
2019-08-01 17:57:17 +08:00
*
* Add a new return value to @procedure according to @pspec
libgimp: add gimp_procedure_add_(argument|return_value)_from_property(). This will be used at least for the Python plug-ins. There is currently a bug preventing to set a GParamSpec in a binded API. See pygobject#227. Please don't revert this. At least it allows to use the new GimpPlugIn API for Python plug-ins. Anyway even with the old API, I had to add ugly temporary API for the introspection (which I will now remove as they never made it to release). So we are trading an ugly situation for a less ugly one. We can always remove these 2 new functions before release if we find or implement better solutions before.
2019-08-02 20:57:42 +08:00
* specifications.
*
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-06 04:29:35 +08:00
* The returned values will be ordered according to the calls order.
libgimp: remove includes and add "Since: 3.0" in gimpprocecure.c
2019-08-06 05:33:49 +08:00
*
libgimp: return the added GParamSpec from all GimpProcedure... ...functions which add arguments or return values. So code can do stuff with them without an additional lookup call.
2020-06-12 18:15:22 +08:00
* Returns: (transfer none): the same @pspec.
*
libgimp: remove includes and add "Since: 3.0" in gimpprocecure.c
2019-08-06 05:33:49 +08:00
* Since: 3.0
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
**/
libgimp: return the added GParamSpec from all GimpProcedure... ...functions which add arguments or return values. So code can do stuff with them without an additional lookup call.
2020-06-12 18:15:22 +08:00
GParamSpec *
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-06 04:29:35 +08:00
_gimp_procedure_add_return_value (GimpProcedure *procedure,
GParamSpec *pspec)
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
libgimp: return the added GParamSpec from all GimpProcedure... ...functions which add arguments or return values. So code can do stuff with them without an additional lookup call.
2020-06-12 18:15:22 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), pspec);
g_return_val_if_fail (G_IS_PARAM_SPEC (pspec), pspec);
g_return_val_if_fail (gimp_is_canonical_identifier (pspec->name), pspec);
libgimp: GimpProcedure args and return values must have have unique and canonical names now.
2019-09-03 00:53:30 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
libgimp: add gimp_procedure_find_argument(), aux_argument(), return_value()
2019-10-12 18:49:32 +08:00
if (gimp_procedure_find_return_value (procedure, pspec->name))
{
g_warning ("Return value with name '%s' already exists on procedure '%s'",
pspec->name,
gimp_procedure_get_name (procedure));
libgimp: return the added GParamSpec from all GimpProcedure... ...functions which add arguments or return values. So code can do stuff with them without an additional lookup call.
2020-06-12 18:15:22 +08:00
return pspec;
libgimp: add gimp_procedure_find_argument(), aux_argument(), return_value()
2019-10-12 18:49:32 +08:00
}
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->values = g_renew (GParamSpec *, priv->values,
priv->n_values + 1);
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->values[priv->n_values] = pspec;
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
g_param_spec_ref_sink (pspec);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->n_values++;
libgimp: return the added GParamSpec from all GimpProcedure... ...functions which add arguments or return values. So code can do stuff with them without an additional lookup call.
2020-06-12 18:15:22 +08:00
return pspec;
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
}
libgimp: add gimp_procedure_find_argument(), aux_argument(), return_value()
2019-10-12 18:49:32 +08:00
/**
* gimp_procedure_find_argument:
* @procedure: A #GimpProcedure
* @name: An argument name
*
* Searches the @procedure's arguments for a #GParamSpec called @name.
*
* Returns: (transfer none): The @procedure's argument with @name if it
* exists, or %NULL otherwise.
*
* Since: 3.0
**/
GParamSpec *
gimp_procedure_find_argument (GimpProcedure *procedure,
const gchar *name)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
gint i;
libgimp: add gimp_procedure_find_argument(), aux_argument(), return_value()
2019-10-12 18:49:32 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
g_return_val_if_fail (name != NULL, NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
for (i = 0; i < priv->n_args; i++)
if (! strcmp (name, priv->args[i]->name))
return priv->args[i];
libgimp: add gimp_procedure_find_argument(), aux_argument(), return_value()
2019-10-12 18:49:32 +08:00
return NULL;
}
/**
* gimp_procedure_find_aux_argument:
* @procedure: A #GimpProcedure
* @name: An auxiliary argument name
*
* Searches the @procedure's auxiliary arguments for a #GParamSpec
* called @name.
*
* Returns: (transfer none): The @procedure's auxiliary argument with
* @name if it exists, or %NULL otherwise.
*
* Since: 3.0
**/
GParamSpec *
gimp_procedure_find_aux_argument (GimpProcedure *procedure,
const gchar *name)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
gint i;
priv = gimp_procedure_get_instance_private (procedure);
libgimp: add gimp_procedure_find_argument(), aux_argument(), return_value()
2019-10-12 18:49:32 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
g_return_val_if_fail (name != NULL, NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
for (i = 0; i < priv->n_aux_args; i++)
if (! strcmp (name, priv->aux_args[i]->name))
return priv->aux_args[i];
libgimp: add gimp_procedure_find_argument(), aux_argument(), return_value()
2019-10-12 18:49:32 +08:00
return NULL;
}
/**
* gimp_procedure_find_return_value:
* @procedure: A #GimpProcedure
* @name: A return value name
*
* Searches the @procedure's return values for a #GParamSpec called
* @name.
*
* Returns: (transfer none): The @procedure's return values with @name
* if it exists, or %NULL otherwise.
*
* Since: 3.0
**/
GParamSpec *
gimp_procedure_find_return_value (GimpProcedure *procedure,
const gchar *name)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
gint i;
priv = gimp_procedure_get_instance_private (procedure);
libgimp: add gimp_procedure_find_argument(), aux_argument(), return_value()
2019-10-12 18:49:32 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
g_return_val_if_fail (name != NULL, NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
for (i = 0; i < priv->n_values; i++)
if (! strcmp (name, priv->values[i]->name))
return priv->values[i];
libgimp: add gimp_procedure_find_argument(), aux_argument(), return_value()
2019-10-12 18:49:32 +08:00
return NULL;
}
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
/**
* gimp_procedure_get_arguments:
* @procedure: A #GimpProcedure.
libgimp: fix some annotations.
2019-08-02 09:21:59 +08:00
* @n_arguments: (out): Returns the number of arguments.
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
*
libgimp: fix some annotations.
2019-08-02 09:21:59 +08:00
* Returns: (transfer none) (array length=n_arguments): An array
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-06 04:29:35 +08:00
* of @GParamSpec in the order they were added in.
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
*
* Since: 3.0
**/
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
GParamSpec **
gimp_procedure_get_arguments (GimpProcedure *procedure,
gint *n_arguments)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
g_return_val_if_fail (n_arguments != NULL, NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
*n_arguments = priv->n_args;
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
return priv->args;
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
}
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
/**
* gimp_procedure_get_aux_arguments:
* @procedure: A #GimpProcedure.
* @n_arguments: (out): Returns the number of auxiliary arguments.
*
* Returns: (transfer none) (array length=n_arguments): An array
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-06 04:29:35 +08:00
* of @GParamSpec in the order they were added in.
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
*
* Since: 3.0
**/
GParamSpec **
gimp_procedure_get_aux_arguments (GimpProcedure *procedure,
gint *n_arguments)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
g_return_val_if_fail (n_arguments != NULL, NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
*n_arguments = priv->n_aux_args;
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
return priv->aux_args;
libgimp: add the concept of "Auxiliary arguments" to GimpProcedure Aux arguments are arbitrary values the procedure wants managed and remembered across invocations in GimpProcedureConfig. They are not passed to run() and are not known to the PDB, they only exist in the procedure's config object.
2019-09-24 18:39:02 +08:00
}
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
/**
* gimp_procedure_get_return_values:
* @procedure: A #GimpProcedure.
libgimp: fix some annotations.
2019-08-02 09:21:59 +08:00
* @n_return_values: (out): Returns the number of return values.
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
*
libgimp: fix some annotations.
2019-08-02 09:21:59 +08:00
* Returns: (transfer none) (array length=n_return_values): An array
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-06 04:29:35 +08:00
* of @GParamSpec in the order they were added in.
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
*
* Since: 3.0
**/
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
GParamSpec **
gimp_procedure_get_return_values (GimpProcedure *procedure,
gint *n_return_values)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
g_return_val_if_fail (n_return_values != NULL, NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
*n_return_values = priv->n_values;
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
return priv->values;
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
}
libgimp: add the concept of "argument sync" to GimpProcedure which can be set to GIMP_ARGUMENT_SYNC_NONE (the default) or GIMP_ARGUMENT_SYNC_PARASITE, which indicates that the argument should be synced with an image parasite of the same name.
2020-06-16 04:55:58 +08:00
/**
* gimp_procedure_set_argument_sync:
* @procedure: a #GimpProcedure.
* @arg_name: the name of one of @procedure's arguments or auxiliary arguments.
* @sync: how to sync the argument or auxiliary argument.
*
libgimp: all _gimp_procedure_config_begin|end_*() functions made private. Since now all GimpProcedure and subclasses run these before and after the relevant run() functions, there is no need to keep these public.
2023-10-15 23:01:47 +08:00
* When the procedure's run() function exits, a #GimpProcedure's arguments
* or auxiliary arguments can be automatically synced with a #GimpParasite of
* the #GimpImage the procedure is running on.
libgimp: add the concept of "argument sync" to GimpProcedure which can be set to GIMP_ARGUMENT_SYNC_NONE (the default) or GIMP_ARGUMENT_SYNC_PARASITE, which indicates that the argument should be synced with an image parasite of the same name.
2020-06-16 04:55:58 +08:00
*
* In order to enable this, set @sync to %GIMP_ARGUMENT_SYNC_PARASITE.
*
* Currently, it is possible to sync a string argument of type
* #GParamSpecString with an image parasite of the same name, for
* example the "gimp-comment" parasite in file save procedures.
*
* Since: 3.0
**/
void
gimp_procedure_set_argument_sync (GimpProcedure *procedure,
const gchar *arg_name,
GimpArgumentSync sync)
{
GParamSpec *pspec;
g_return_if_fail (GIMP_IS_PROCEDURE (procedure));
g_return_if_fail (arg_name != NULL);
pspec = gimp_procedure_find_argument (procedure, arg_name);
if (! pspec)
pspec = gimp_procedure_find_aux_argument (procedure, arg_name);
g_return_if_fail (pspec != NULL);
switch (sync)
{
case GIMP_ARGUMENT_SYNC_NONE:
gegl_param_spec_set_property_key (pspec, "gimp-argument-sync", NULL);
break;
case GIMP_ARGUMENT_SYNC_PARASITE:
gegl_param_spec_set_property_key (pspec, "gimp-argument-sync", "parasite");
break;
}
}
/**
* gimp_procedure_get_argument_sync:
* @procedure: a #GimpProcedure
* @arg_name: the name of one of @procedure's arguments or auxiliary arguments
*
* Returns: The #GimpArgumentSync value set with
* gimp_procedure_set_argument_sync():
*
* Since: 3.0
**/
GimpArgumentSync
gimp_procedure_get_argument_sync (GimpProcedure *procedure,
const gchar *arg_name)
{
GParamSpec *pspec;
GimpArgumentSync sync = GIMP_ARGUMENT_SYNC_NONE;
const gchar *value;
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), GIMP_ARGUMENT_SYNC_NONE);
g_return_val_if_fail (arg_name != NULL, GIMP_ARGUMENT_SYNC_NONE);
pspec = gimp_procedure_find_argument (procedure, arg_name);
if (! pspec)
pspec = gimp_procedure_find_aux_argument (procedure, arg_name);
g_return_val_if_fail (pspec != NULL, GIMP_ARGUMENT_SYNC_NONE);
value = gegl_param_spec_get_property_key (pspec, "gimp-argument-sync");
if (value)
{
if (! strcmp (value, "parasite"))
sync = GIMP_ARGUMENT_SYNC_PARASITE;
}
return sync;
}
libgimp, libgimpbase: add some documentation for new functions. Just for a few of them just now as I needed these for my binding plug-in tests, and without the proper annotations, these functions were unavailable.
2019-08-01 17:57:17 +08:00
/**
* gimp_procedure_new_return_values:
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* @procedure: the procedure.
libgimp: fix annotation for gimp_procedure_add_argument() and _add_return_value(), the GParamSpecs are (transfer full).
2019-08-01 18:58:39 +08:00
* @status: the success status of the procedure run.
libgimp: transfer ownership of @error parameter to... ... gimp_procedure_new_return_values(). When we see how this has been used in help or goat-exercise plug-ins so far, we clearly see that we expect this function to be used as last call in a run callback. Well we could save the result, free the error, then return the result, but it's cumbersome. So instead let's officially expect gimp_procedure_new_return_values() to take ownership of the GError (i.e. it will free it in the end). For this reason, remove the `const`.
2019-08-01 22:00:36 +08:00
* @error: (in) (nullable) (transfer full):
* an optional #GError. This parameter should be set if
* @status is either #GIMP_PDB_EXECUTION_ERROR or
libgimp: fix annotation for gimp_procedure_add_argument() and _add_return_value(), the GParamSpecs are (transfer full).
2019-08-01 18:58:39 +08:00
* #GIMP_PDB_CALLING_ERROR.
libgimp, libgimpbase: add some documentation for new functions. Just for a few of them just now as I needed these for my binding plug-in tests, and without the proper annotations, these functions were unavailable.
2019-08-01 17:57:17 +08:00
*
libgimp, plug-ins: make generic gimp_procedure_add_argument() private. Same for gimp_procedure_add_aux_argument() and gimp_procedure_add_return_value(). We now have specific public functions for every supported type and it's in fact much better to use them. The generic functions gave the feeling that we could use any GParamSpec as procedure argument, whereas we in fact depend on what the PDB support, and only these subtypes.
2024-07-06 04:29:35 +08:00
* Format the expected return values from procedures.
libgimp, libgimpbase: add some documentation for new functions. Just for a few of them just now as I needed these for my binding plug-in tests, and without the proper annotations, these functions were unavailable.
2019-08-01 17:57:17 +08:00
*
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* Returns: (transfer full): the expected #GimpValueArray as could be returned
* by a [callback@RunFunc].
libgimp: remove includes and add "Since: 3.0" in gimpprocecure.c
2019-08-06 05:33:49 +08:00
*
* Since: 3.0
libgimp: add gimp_procedure_set_attribution() Also rename "author" to "authors" and add some docs.
2019-08-02 06:35:17 +08:00
**/
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
GimpValueArray *
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
gimp_procedure_new_return_values (GimpProcedure *procedure,
GimpPDBStatusType status,
libgimp: transfer ownership of @error parameter to... ... gimp_procedure_new_return_values(). When we see how this has been used in help or goat-exercise plug-ins so far, we clearly see that we expect this function to be used as last call in a run callback. Well we could save the result, free the error, then return the result, but it's cumbersome. So instead let's officially expect gimp_procedure_new_return_values() to take ownership of the GError (i.e. it will free it in the end). For this reason, remove the `const`.
2019-08-01 22:00:36 +08:00
GError *error)
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
GimpValueArray *args;
GValue value = G_VALUE_INIT;
gint i;
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
g_return_val_if_fail (status != GIMP_PDB_PASS_THROUGH, NULL);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
switch (status)
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
{
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
case GIMP_PDB_SUCCESS:
case GIMP_PDB_CANCEL:
libgimp: add more comfortable ways to run procedures to GimpPDB return_vals = gimp_pdb_run_procedure (pdb, "procedure-name", G_TYPE_STRING, "string arg", G_TYPE_INT 23, G_TYPE_BOOLEAN, FALSE, G_TYPE_NONE);
2019-08-07 01:10:04 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
args = gimp_value_array_new (priv->n_values + 1);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
g_value_init (&value, GIMP_TYPE_PDB_STATUS_TYPE);
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
g_value_set_enum (&value, status);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
gimp_value_array_append (args, &value);
g_value_unset (&value);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
for (i = 0; i < priv->n_values; i++)
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GParamSpec *pspec = priv->values[i];
libgimp: set a procedure's arguments and return values to defaults We need this for named parameters, and it's cleaner anyway.
2019-08-02 06:39:22 +08:00
g_value_init (&value, G_PARAM_SPEC_VALUE_TYPE (pspec));
g_param_value_set_default (pspec, &value);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
gimp_value_array_append (args, &value);
g_value_unset (&value);
}
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
break;
case GIMP_PDB_EXECUTION_ERROR:
case GIMP_PDB_CALLING_ERROR:
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
args = gimp_value_array_new ((error && error->message) ? 2 : 1);
g_value_init (&value, GIMP_TYPE_PDB_STATUS_TYPE);
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
g_value_set_enum (&value, status);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
gimp_value_array_append (args, &value);
g_value_unset (&value);
if (error && error->message)
{
g_value_init (&value, G_TYPE_STRING);
g_value_set_string (&value, error->message);
gimp_value_array_append (args, &value);
g_value_unset (&value);
}
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
break;
default:
g_return_val_if_reached (NULL);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
}
libgimp: add more comfortable ways to run procedures to GimpPDB return_vals = gimp_pdb_run_procedure (pdb, "procedure-name", G_TYPE_STRING, "string arg", G_TYPE_INT 23, G_TYPE_BOOLEAN, FALSE, G_TYPE_NONE);
2019-08-07 01:10:04 +08:00
libgimp: transfer ownership of @error parameter to... ... gimp_procedure_new_return_values(). When we see how this has been used in help or goat-exercise plug-ins so far, we clearly see that we expect this function to be used as last call in a run callback. Well we could save the result, free the error, then return the result, but it's cumbersome. So instead let's officially expect gimp_procedure_new_return_values() to take ownership of the GError (i.e. it will free it in the end). For this reason, remove the `const`.
2019-08-01 22:00:36 +08:00
g_clear_error (&error);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
return args;
}
libgimp: cleanup and more docs for GimpProcedure
2019-08-02 05:46:25 +08:00
/**
libgimp, plug-ins: move gimp_pdb_run_procedure*() to gimp_procedure_run*(). The gimp_procedure_run() already existed, though it was with an ordered GimpValueArray array of arguments. Its usage feels redundant to the series of gimp_pdb_run_procedure*() functions (which is confusing), but gimp_procedure_run() was actually a bit more generic, because it does not necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a local GimpProcedure, such as the case of one procedure which would want to call another procedure in the same plug-in, but without having to go through PDB. Of course, for local code, you may as well run relevant functions directly, yet it makes sense that if one of the redundant-looking function is removed, it should be the more specific one. Also gimp_procedure_run() feels a lot simpler and logical, API wise. A main difference in usage is that now, plug-in developers have to first explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when they wish to call PDB procedures on the wire. This was done anyway in the gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name directly). Concretely: * gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and gimp_pdb_run_procedure_valist() are removed. * gimp_procedure_run() API is modified to use a variable args list instead of a GimpValueArray. * gimp_procedure_run_config() and gimp_procedure_run_valist() are added. * gimp_procedure_run_config() in particular will be the one used in bindings which don't have variable args support through a (rename-to gimp_procedure_run) annotation.
2023-10-18 23:11:20 +08:00
* gimp_procedure_run: (skip)
Fix gobject introspection references Newer gi-docgen will fail otherwise. Signed-off-by: Nils Philippsen <nils@tiptoe.de>
2024-06-11 18:34:15 +08:00
* @procedure: the [class@Gimp.Procedure] to run.
libgimp: fixing annotations.
2023-12-08 20:18:03 +08:00
* @first_arg_name: the name of an argument of @procedure or %NULL to
* run @procedure with default arguments.
* @...: the value of @first_arg_name and any more argument
* names and values as needed.
libgimp, plug-ins: move gimp_pdb_run_procedure*() to gimp_procedure_run*(). The gimp_procedure_run() already existed, though it was with an ordered GimpValueArray array of arguments. Its usage feels redundant to the series of gimp_pdb_run_procedure*() functions (which is confusing), but gimp_procedure_run() was actually a bit more generic, because it does not necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a local GimpProcedure, such as the case of one procedure which would want to call another procedure in the same plug-in, but without having to go through PDB. Of course, for local code, you may as well run relevant functions directly, yet it makes sense that if one of the redundant-looking function is removed, it should be the more specific one. Also gimp_procedure_run() feels a lot simpler and logical, API wise. A main difference in usage is that now, plug-in developers have to first explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when they wish to call PDB procedures on the wire. This was done anyway in the gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name directly). Concretely: * gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and gimp_pdb_run_procedure_valist() are removed. * gimp_procedure_run() API is modified to use a variable args list instead of a GimpValueArray. * gimp_procedure_run_config() and gimp_procedure_run_valist() are added. * gimp_procedure_run_config() in particular will be the one used in bindings which don't have variable args support through a (rename-to gimp_procedure_run) annotation.
2023-10-18 23:11:20 +08:00
*
* Runs the procedure named @procedure_name with arguments given as
* list of `(name, value)` pairs, terminated by %NULL.
*
* The order of arguments does not matter and if any argument is missing, its
* default value will be used. The value type must correspond to the argument
* type as registered for @procedure_name.
*
* Returns: (transfer full): the return values for the procedure call.
*
* Since: 3.0
*/
GimpValueArray *
gimp_procedure_run (GimpProcedure *procedure,
const gchar *first_arg_name,
...)
{
GimpValueArray *return_values;
va_list args;
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
va_start (args, first_arg_name);
return_values = gimp_procedure_run_valist (procedure, first_arg_name, args);
va_end (args);
return return_values;
}
/**
* gimp_procedure_run_valist: (skip)
Fix gobject introspection references Newer gi-docgen will fail otherwise. Signed-off-by: Nils Philippsen <nils@tiptoe.de>
2024-06-11 18:34:15 +08:00
* @procedure: the [class@Gimp.Procedure] to run.
libgimp: fixing annotations.
2023-12-08 20:18:03 +08:00
* @first_arg_name: the name of an argument of @procedure or %NULL to
* run @procedure with default arguments.
* @args the value of @first_arg_name and any more argument
* names and values as needed.
libgimp, plug-ins: move gimp_pdb_run_procedure*() to gimp_procedure_run*(). The gimp_procedure_run() already existed, though it was with an ordered GimpValueArray array of arguments. Its usage feels redundant to the series of gimp_pdb_run_procedure*() functions (which is confusing), but gimp_procedure_run() was actually a bit more generic, because it does not necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a local GimpProcedure, such as the case of one procedure which would want to call another procedure in the same plug-in, but without having to go through PDB. Of course, for local code, you may as well run relevant functions directly, yet it makes sense that if one of the redundant-looking function is removed, it should be the more specific one. Also gimp_procedure_run() feels a lot simpler and logical, API wise. A main difference in usage is that now, plug-in developers have to first explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when they wish to call PDB procedures on the wire. This was done anyway in the gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name directly). Concretely: * gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and gimp_pdb_run_procedure_valist() are removed. * gimp_procedure_run() API is modified to use a variable args list instead of a GimpValueArray. * gimp_procedure_run_config() and gimp_procedure_run_valist() are added. * gimp_procedure_run_config() in particular will be the one used in bindings which don't have variable args support through a (rename-to gimp_procedure_run) annotation.
2023-10-18 23:11:20 +08:00
*
* Runs @procedure with arguments names and values, given in the order as passed
* to [method@Procedure.run].
*
* Returns: (transfer full): the return values for the procedure call.
*
* Since: 3.0
*/
GimpValueArray *
gimp_procedure_run_valist (GimpProcedure *procedure,
const gchar *first_arg_name,
va_list args)
{
GimpValueArray *return_values;
GimpProcedureConfig *config;
const gchar *arg_name;
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
config = gimp_procedure_create_config (procedure);
arg_name = first_arg_name;
while (arg_name != NULL)
{
GParamSpec *pspec;
gchar *error = NULL;
GValue value = G_VALUE_INIT;
pspec = g_object_class_find_property (G_OBJECT_GET_CLASS (config), arg_name);
if (pspec == NULL)
{
g_warning ("%s: %s has no property named '%s'",
G_STRFUNC,
g_type_name (G_TYPE_FROM_INSTANCE (config)),
arg_name);
g_clear_object (&config);
return NULL;
}
g_value_init (&value, pspec->value_type);
G_VALUE_COLLECT (&value, args, G_VALUE_NOCOPY_CONTENTS, &error);
if (error)
{
g_warning ("%s: %s", G_STRFUNC, error);
g_free (error);
g_clear_object (&config);
return NULL;
}
g_object_set_property (G_OBJECT (config), arg_name, &value);
g_value_unset (&value);
arg_name = va_arg (args, const gchar *);
}
return_values = gimp_procedure_run_config (procedure, config);
g_clear_object (&config);
return return_values;
}
/**
* gimp_procedure_run_config: (rename-to gimp_procedure_run)
Fix gobject introspection references Newer gi-docgen will fail otherwise. Signed-off-by: Nils Philippsen <nils@tiptoe.de>
2024-06-11 18:34:15 +08:00
* @procedure: the [class@Gimp.Procedure] to run.
libgimp: allow to run gimp_procedure_run_config() with no config object. This is the equivalent to run the procedure with its defaults.
2024-02-29 23:33:32 +08:00
* @config: (nullable): the @procedure's arguments.
libgimp: cleanup and more docs for GimpProcedure
2019-08-02 05:46:25 +08:00
*
libgimp, plug-ins: move gimp_pdb_run_procedure*() to gimp_procedure_run*(). The gimp_procedure_run() already existed, though it was with an ordered GimpValueArray array of arguments. Its usage feels redundant to the series of gimp_pdb_run_procedure*() functions (which is confusing), but gimp_procedure_run() was actually a bit more generic, because it does not necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a local GimpProcedure, such as the case of one procedure which would want to call another procedure in the same plug-in, but without having to go through PDB. Of course, for local code, you may as well run relevant functions directly, yet it makes sense that if one of the redundant-looking function is removed, it should be the more specific one. Also gimp_procedure_run() feels a lot simpler and logical, API wise. A main difference in usage is that now, plug-in developers have to first explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when they wish to call PDB procedures on the wire. This was done anyway in the gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name directly). Concretely: * gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and gimp_pdb_run_procedure_valist() are removed. * gimp_procedure_run() API is modified to use a variable args list instead of a GimpValueArray. * gimp_procedure_run_config() and gimp_procedure_run_valist() are added. * gimp_procedure_run_config() in particular will be the one used in bindings which don't have variable args support through a (rename-to gimp_procedure_run) annotation.
2023-10-18 23:11:20 +08:00
* Runs @procedure, calling the run_func given in [ctor@Procedure.new].
libgimp: cleanup and more docs for GimpProcedure
2019-08-02 05:46:25 +08:00
*
libgimp: fixing annotations.
2023-12-08 20:18:03 +08:00
* Create @config at default values with
* [method@Gimp.Procedure.create_config] then set any argument you wish
* to change from defaults with [method@GObject.Object.set].
*
libgimp: allow to run gimp_procedure_run_config() with no config object. This is the equivalent to run the procedure with its defaults.
2024-02-29 23:33:32 +08:00
* If @config is %NULL, the default arguments of @procedure will be used.
*
libgimp: fix some annotations.
2019-08-02 09:21:59 +08:00
* Returns: (transfer full): The @procedure's return values.
libgimp: cleanup and more docs for GimpProcedure
2019-08-02 05:46:25 +08:00
*
* Since: 3.0
**/
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
GimpValueArray *
libgimp, plug-ins: move gimp_pdb_run_procedure*() to gimp_procedure_run*(). The gimp_procedure_run() already existed, though it was with an ordered GimpValueArray array of arguments. Its usage feels redundant to the series of gimp_pdb_run_procedure*() functions (which is confusing), but gimp_procedure_run() was actually a bit more generic, because it does not necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a local GimpProcedure, such as the case of one procedure which would want to call another procedure in the same plug-in, but without having to go through PDB. Of course, for local code, you may as well run relevant functions directly, yet it makes sense that if one of the redundant-looking function is removed, it should be the more specific one. Also gimp_procedure_run() feels a lot simpler and logical, API wise. A main difference in usage is that now, plug-in developers have to first explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when they wish to call PDB procedures on the wire. This was done anyway in the gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name directly). Concretely: * gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and gimp_pdb_run_procedure_valist() are removed. * gimp_procedure_run() API is modified to use a variable args list instead of a GimpValueArray. * gimp_procedure_run_config() and gimp_procedure_run_valist() are added. * gimp_procedure_run_config() in particular will be the one used in bindings which don't have variable args support through a (rename-to gimp_procedure_run) annotation.
2023-10-18 23:11:20 +08:00
gimp_procedure_run_config (GimpProcedure *procedure,
GimpProcedureConfig *config)
{
GimpValueArray *return_vals;
GimpValueArray *args;
libgimp: allow to run gimp_procedure_run_config() with no config object. This is the equivalent to run the procedure with its defaults.
2024-02-29 23:33:32 +08:00
gboolean free_config = FALSE;
libgimp, plug-ins: move gimp_pdb_run_procedure*() to gimp_procedure_run*(). The gimp_procedure_run() already existed, though it was with an ordered GimpValueArray array of arguments. Its usage feels redundant to the series of gimp_pdb_run_procedure*() functions (which is confusing), but gimp_procedure_run() was actually a bit more generic, because it does not necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a local GimpProcedure, such as the case of one procedure which would want to call another procedure in the same plug-in, but without having to go through PDB. Of course, for local code, you may as well run relevant functions directly, yet it makes sense that if one of the redundant-looking function is removed, it should be the more specific one. Also gimp_procedure_run() feels a lot simpler and logical, API wise. A main difference in usage is that now, plug-in developers have to first explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when they wish to call PDB procedures on the wire. This was done anyway in the gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name directly). Concretely: * gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and gimp_pdb_run_procedure_valist() are removed. * gimp_procedure_run() API is modified to use a variable args list instead of a GimpValueArray. * gimp_procedure_run_config() and gimp_procedure_run_valist() are added. * gimp_procedure_run_config() in particular will be the one used in bindings which don't have variable args support through a (rename-to gimp_procedure_run) annotation.
2023-10-18 23:11:20 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: allow to run gimp_procedure_run_config() with no config object. This is the equivalent to run the procedure with its defaults.
2024-02-29 23:33:32 +08:00
g_return_val_if_fail (config == NULL || GIMP_IS_PROCEDURE_CONFIG (config), NULL);
g_return_val_if_fail (config == NULL || gimp_procedure_config_get_procedure (config) == procedure, NULL);
if (config == NULL)
{
config = gimp_procedure_create_config (procedure);
free_config = TRUE;
}
libgimp, plug-ins: move gimp_pdb_run_procedure*() to gimp_procedure_run*(). The gimp_procedure_run() already existed, though it was with an ordered GimpValueArray array of arguments. Its usage feels redundant to the series of gimp_pdb_run_procedure*() functions (which is confusing), but gimp_procedure_run() was actually a bit more generic, because it does not necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a local GimpProcedure, such as the case of one procedure which would want to call another procedure in the same plug-in, but without having to go through PDB. Of course, for local code, you may as well run relevant functions directly, yet it makes sense that if one of the redundant-looking function is removed, it should be the more specific one. Also gimp_procedure_run() feels a lot simpler and logical, API wise. A main difference in usage is that now, plug-in developers have to first explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when they wish to call PDB procedures on the wire. This was done anyway in the gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name directly). Concretely: * gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and gimp_pdb_run_procedure_valist() are removed. * gimp_procedure_run() API is modified to use a variable args list instead of a GimpValueArray. * gimp_procedure_run_config() and gimp_procedure_run_valist() are added. * gimp_procedure_run_config() in particular will be the one used in bindings which don't have variable args support through a (rename-to gimp_procedure_run) annotation.
2023-10-18 23:11:20 +08:00
args = gimp_procedure_new_arguments (procedure);
_gimp_procedure_config_get_values (config, args);
return_vals = _gimp_procedure_run_array (procedure, args);
gimp_value_array_unref (args);
libgimp: allow to run gimp_procedure_run_config() with no config object. This is the equivalent to run the procedure with its defaults.
2024-02-29 23:33:32 +08:00
if (free_config)
g_object_unref (config);
libgimp, plug-ins: move gimp_pdb_run_procedure*() to gimp_procedure_run*(). The gimp_procedure_run() already existed, though it was with an ordered GimpValueArray array of arguments. Its usage feels redundant to the series of gimp_pdb_run_procedure*() functions (which is confusing), but gimp_procedure_run() was actually a bit more generic, because it does not necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a local GimpProcedure, such as the case of one procedure which would want to call another procedure in the same plug-in, but without having to go through PDB. Of course, for local code, you may as well run relevant functions directly, yet it makes sense that if one of the redundant-looking function is removed, it should be the more specific one. Also gimp_procedure_run() feels a lot simpler and logical, API wise. A main difference in usage is that now, plug-in developers have to first explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when they wish to call PDB procedures on the wire. This was done anyway in the gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name directly). Concretely: * gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and gimp_pdb_run_procedure_valist() are removed. * gimp_procedure_run() API is modified to use a variable args list instead of a GimpValueArray. * gimp_procedure_run_config() and gimp_procedure_run_valist() are added. * gimp_procedure_run_config() in particular will be the one used in bindings which don't have variable args support through a (rename-to gimp_procedure_run) annotation.
2023-10-18 23:11:20 +08:00
return return_vals;
}
libgimp: reimplement gimp_procedure_run_config() for public usage. Previous gimp_procedure_run_config() was in fact only good for private usage inside the various run() methods for the different GimpProcedure subtypes. The problem with this implementation is that the returned config object is not complete. For instance, for a GimpLoadProcedure, the "run-mode" and "file" properties are not part of the config object so you cannot call a GimpLoadProcedure with any of the gimp_procedure_run*() functions. Note: we had some working usage, e.g. in file-openraster, but only because it was running the load procedure as a GimpPDBProcedure whose returned config object was indeed always complete! As a consequence, I rename gimp_procedure_run_config() as an internal-only function _gimp_procedure_create_run_config() and I create a new gimp_procedure_run_config() which always return a full config with all arguments.
2024-05-02 03:47:55 +08:00
/**
* _gimp_procedure_create_run_config:
* @procedure: A #GimpProcedure
*
* Create a #GimpConfig with properties that match @procedure's arguments, to be
* used in the run() method for @procedure.
*
* This is an internal function to be used only by libgimp code.
*
* Returns: (transfer full): The new #GimpConfig.
*
* Since: 3.0
**/
GimpProcedureConfig *
_gimp_procedure_create_run_config (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
libgimp: reimplement gimp_procedure_run_config() for public usage. Previous gimp_procedure_run_config() was in fact only good for private usage inside the various run() methods for the different GimpProcedure subtypes. The problem with this implementation is that the returned config object is not complete. For instance, for a GimpLoadProcedure, the "run-mode" and "file" properties are not part of the config object so you cannot call a GimpLoadProcedure with any of the gimp_procedure_run*() functions. Note: we had some working usage, e.g. in file-openraster, but only because it was running the load procedure as a GimpPDBProcedure whose returned config object was indeed always complete! As a consequence, I rename gimp_procedure_run_config() as an internal-only function _gimp_procedure_create_run_config() and I create a new gimp_procedure_run_config() which always return a full config with all arguments.
2024-05-02 03:47:55 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
libgimp: reimplement gimp_procedure_run_config() for public usage. Previous gimp_procedure_run_config() was in fact only good for private usage inside the various run() methods for the different GimpProcedure subtypes. The problem with this implementation is that the returned config object is not complete. For instance, for a GimpLoadProcedure, the "run-mode" and "file" properties are not part of the config object so you cannot call a GimpLoadProcedure with any of the gimp_procedure_run*() functions. Note: we had some working usage, e.g. in file-openraster, but only because it was running the load procedure as a GimpPDBProcedure whose returned config object was indeed always complete! As a consequence, I rename gimp_procedure_run_config() as an internal-only function _gimp_procedure_create_run_config() and I create a new gimp_procedure_run_config() which always return a full config with all arguments.
2024-05-02 03:47:55 +08:00
return GIMP_PROCEDURE_GET_CLASS (procedure)->create_config (procedure,
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->args,
priv->n_args);
libgimp: reimplement gimp_procedure_run_config() for public usage. Previous gimp_procedure_run_config() was in fact only good for private usage inside the various run() methods for the different GimpProcedure subtypes. The problem with this implementation is that the returned config object is not complete. For instance, for a GimpLoadProcedure, the "run-mode" and "file" properties are not part of the config object so you cannot call a GimpLoadProcedure with any of the gimp_procedure_run*() functions. Note: we had some working usage, e.g. in file-openraster, but only because it was running the load procedure as a GimpPDBProcedure whose returned config object was indeed always complete! As a consequence, I rename gimp_procedure_run_config() as an internal-only function _gimp_procedure_create_run_config() and I create a new gimp_procedure_run_config() which always return a full config with all arguments.
2024-05-02 03:47:55 +08:00
}
libgimp, plug-ins: move gimp_pdb_run_procedure*() to gimp_procedure_run*(). The gimp_procedure_run() already existed, though it was with an ordered GimpValueArray array of arguments. Its usage feels redundant to the series of gimp_pdb_run_procedure*() functions (which is confusing), but gimp_procedure_run() was actually a bit more generic, because it does not necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a local GimpProcedure, such as the case of one procedure which would want to call another procedure in the same plug-in, but without having to go through PDB. Of course, for local code, you may as well run relevant functions directly, yet it makes sense that if one of the redundant-looking function is removed, it should be the more specific one. Also gimp_procedure_run() feels a lot simpler and logical, API wise. A main difference in usage is that now, plug-in developers have to first explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when they wish to call PDB procedures on the wire. This was done anyway in the gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name directly). Concretely: * gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and gimp_pdb_run_procedure_valist() are removed. * gimp_procedure_run() API is modified to use a variable args list instead of a GimpValueArray. * gimp_procedure_run_config() and gimp_procedure_run_valist() are added. * gimp_procedure_run_config() in particular will be the one used in bindings which don't have variable args support through a (rename-to gimp_procedure_run) annotation.
2023-10-18 23:11:20 +08:00
GimpValueArray *
_gimp_procedure_run_array (GimpProcedure *procedure,
GimpValueArray *args)
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
GimpValueArray *return_vals;
GError *error = NULL;
gint i;
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
g_return_val_if_fail (args != NULL, NULL);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
if (! gimp_procedure_validate_args (procedure,
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->args,
priv->n_args,
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
args, FALSE, &error))
{
return_vals = gimp_procedure_new_return_values (procedure,
GIMP_PDB_CALLING_ERROR,
error);
return return_vals;
}
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: make sure GimpProcedures always get all their arguments gimp_procedure_run(): fill the value array with default values so a procedure's run callback always gets a complete value array. No more number-of-arguments checking in any new-style plug-in.
2019-08-03 22:56:31 +08:00
/* add missing args with default values */
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
if (gimp_value_array_length (args) < priv->n_args)
libgimp: make sure GimpProcedures always get all their arguments gimp_procedure_run(): fill the value array with default values so a procedure's run callback always gets a complete value array. No more number-of-arguments checking in any new-style plug-in.
2019-08-03 22:56:31 +08:00
{
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 *config;
GObjectClass *config_class = NULL;
GimpValueArray *complete;
/* if saved defaults exist, they override GParamSpec */
libgimp: reimplement gimp_procedure_run_config() for public usage. Previous gimp_procedure_run_config() was in fact only good for private usage inside the various run() methods for the different GimpProcedure subtypes. The problem with this implementation is that the returned config object is not complete. For instance, for a GimpLoadProcedure, the "run-mode" and "file" properties are not part of the config object so you cannot call a GimpLoadProcedure with any of the gimp_procedure_run*() functions. Note: we had some working usage, e.g. in file-openraster, but only because it was running the load procedure as a GimpPDBProcedure whose returned config object was indeed always complete! As a consequence, I rename gimp_procedure_run_config() as an internal-only function _gimp_procedure_create_run_config() and I create a new gimp_procedure_run_config() which always return a full config with all arguments.
2024-05-02 03:47:55 +08:00
config = _gimp_procedure_create_run_config (procedure);
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 (config, NULL))
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
config_class = G_OBJECT_GET_CLASS (config);
else
g_clear_object (&config);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
complete = gimp_value_array_new (priv->n_args);
libgimp: make sure GimpProcedures always get all their arguments gimp_procedure_run(): fill the value array with default values so a procedure's run callback always gets a complete value array. No more number-of-arguments checking in any new-style plug-in.
2019-08-03 22:56:31 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
for (i = 0; i < priv->n_args; i++)
libgimp: add some const to input parameters, like const GimpValueArray* for procedure arguments. This implies creating a new value array in gimp_procedure_run() if the passed array is too short, instead of just appending to the passed array, which was ugly anyway.
2019-08-07 06:02:29 +08:00
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GParamSpec *pspec = priv->args[i];
libgimp: add some const to input parameters, like const GimpValueArray* for procedure arguments. This implies creating a new value array in gimp_procedure_run() if the passed array is too short, instead of just appending to the passed array, which was ugly anyway.
2019-08-07 06:02:29 +08:00
GValue value = G_VALUE_INIT;
g_value_init (&value, G_PARAM_SPEC_VALUE_TYPE (pspec));
libgimp: make sure GimpProcedures always get all their arguments gimp_procedure_run(): fill the value array with default values so a procedure's run callback always gets a complete value array. No more number-of-arguments checking in any new-style plug-in.
2019-08-03 22:56:31 +08:00
libgimp: add some const to input parameters, like const GimpValueArray* for procedure arguments. This implies creating a new value array in gimp_procedure_run() if the passed array is too short, instead of just appending to the passed array, which was ugly anyway.
2019-08-07 06:02:29 +08:00
if (i < gimp_value_array_length (args))
{
GValue *orig = gimp_value_array_index (args, i);
g_value_copy (orig, &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
else if (config &&
g_object_class_find_property (config_class, pspec->name))
{
g_object_get_property (G_OBJECT (config), pspec->name,
&value);
}
libgimp: add some const to input parameters, like const GimpValueArray* for procedure arguments. This implies creating a new value array in gimp_procedure_run() if the passed array is too short, instead of just appending to the passed array, which was ugly anyway.
2019-08-07 06:02:29 +08:00
else
{
g_param_value_set_default (pspec, &value);
}
gimp_value_array_append (complete, &value);
g_value_unset (&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
g_clear_object (&config);
libgimp: add some const to input parameters, like const GimpValueArray* for procedure arguments. This implies creating a new value array in gimp_procedure_run() if the passed array is too short, instead of just appending to the passed array, which was ugly anyway.
2019-08-07 06:02:29 +08:00
/* call the procedure */
return_vals = GIMP_PROCEDURE_GET_CLASS (procedure)->run (procedure,
complete);
gimp_value_array_unref (complete);
}
else
{
/* call the procedure */
return_vals = GIMP_PROCEDURE_GET_CLASS (procedure)->run (procedure,
args);
}
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
if (! return_vals)
{
g_warning ("%s: no return values, shouldn't happen", G_STRFUNC);
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
libgimp: too many arguments to g_error_new().
2019-08-29 22:25:14 +08:00
error = g_error_new (0, 0,
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
_("Procedure '%s' returned no return values"),
gimp_procedure_get_name (procedure));
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
return_vals = gimp_procedure_new_return_values (procedure,
GIMP_PDB_EXECUTION_ERROR,
error);
}
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
app, libgimp, libgimpbase: plug-in and PDB protocol refactoring part two - Change the wire protocol's GPProcInstall to transmit the entire information needed for constructing all GParamSpecs we use, don't use GimpPDBArgType in GPProcInstall but an enum private to the wire protocol plus the GParamSpec's GType name. Bump the wire protocol version. - Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which take care of converting between GPParamDef and GParamSpec. They share code as far as possible. - Change pluginrc writing and parsing to re-use GPParamDef and the utility functions from gimpgpparamspecs. - Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch], the entire core uses proper GParamSpecs from the wire protocol now, the whole file will follow down the drain once we use a GValue representation on the wire too. - In gimp_plug_in_handle_proc_install(), change the "run-mode" parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not already an enum). and change all places in app/ to treat it as an enum value. - plug-ins: fix cml-explorer to register correctly, a typo in "run-mode" was never noticed until now. - Add gimpgpcompat.[ch] in libgimp to deal with all the transforms between old-style wire communication and using GParamSpec and GValue, it contains some functions that are subject to change or even removal in the next steps. - Change the libgimp GimpProcedure and GimpPlugIn in many ways to be able to actually install procedures the new way. - plug-ins: change goat-exercise to completely use the new GimpPlugIn and GimpProcedure API, look here to see how plug-ins will look in the future, of course subject to change until this is finished. - Next: changing GPParam to transmit all information about a GValue.
2019-07-27 22:37:55 +08:00
return return_vals;
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
}
libgimp: add gimp_procedure_extension_ready() which must be called by GIMP_EXTENSION procedures when they are ready to run their temporary procedures. Move gimp_extension_ack() to gimpobsolete.[ch].
2019-08-02 05:24:49 +08:00
/**
* gimp_procedure_extension_ready:
pdb, libgimp: fix various doc issues found by gtk-doc
2019-08-10 17:08:06 +08:00
* @procedure: A #GimpProcedure
libgimp: add gimp_procedure_extension_ready() which must be called by GIMP_EXTENSION procedures when they are ready to run their temporary procedures. Move gimp_extension_ack() to gimpobsolete.[ch].
2019-08-02 05:24:49 +08:00
*
* Notify the main GIMP application that the extension has been
* properly initialized and is ready to run.
*
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* This function _must_ be called from every procedure's [callback@RunFunc]
* that was created as #GIMP_PDB_PROC_TYPE_EXTENSION.
libgimp: add gimp_procedure_extension_ready() which must be called by GIMP_EXTENSION procedures when they are ready to run their temporary procedures. Move gimp_extension_ack() to gimpobsolete.[ch].
2019-08-02 05:24:49 +08:00
*
* Subsequently, extensions can process temporary procedure run
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* requests using either [method@PlugIn.extension_enable] or
* [method@PlugIn.extension_process].
libgimp: add gimp_procedure_extension_ready() which must be called by GIMP_EXTENSION procedures when they are ready to run their temporary procedures. Move gimp_extension_ack() to gimpobsolete.[ch].
2019-08-02 05:24:49 +08:00
*
docs: Migrate from gtk-doc to gi-docgen gtk-doc has been slowly dying for the past few years; with gi-docgen we have a nice successor. This also makes sure the C documentation also uses the GIR file, which in turn means faster build times (since all the C code doesn't have to be parsed and recompiled again), and has a clear dependency graph. See the [gi-docgen tutorial] for more info on how the system works. [gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
2021-11-29 02:36:07 +08:00
* See also: [ctor@Procedure.new].
libgimp: add gimp_procedure_extension_ready() which must be called by GIMP_EXTENSION procedures when they are ready to run their temporary procedures. Move gimp_extension_ack() to gimpobsolete.[ch].
2019-08-02 05:24:49 +08:00
*
* Since: 3.0
**/
void
gimp_procedure_extension_ready (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
GimpPlugIn *plug_in;
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
libgimp: add gimp_procedure_extension_ready() which must be called by GIMP_EXTENSION procedures when they are ready to run their temporary procedures. Move gimp_extension_ack() to gimpobsolete.[ch].
2019-08-02 05:24:49 +08:00
g_return_if_fail (GIMP_IS_PROCEDURE (procedure));
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
g_return_if_fail (priv->proc_type == GIMP_PDB_PROC_TYPE_EXTENSION);
libgimp: add gimp_procedure_extension_ready() which must be called by GIMP_EXTENSION procedures when they are ready to run their temporary procedures. Move gimp_extension_ack() to gimpobsolete.[ch].
2019-08-02 05:24:49 +08:00
libgimp: add GimpFileProcedure, GimpLoadProcedure and GimpSaveProcedure which are GimpProcedure subclasses with API to register as load/save handlers and their own kind of run functions that get their standard arguments passed directly instead of packed into a GimpValueArray. They also register their standard arguments themselves, which removes quite some boilerplate from load/save plug-ins. Remove gimpprocedure-private.[ch] because install() and uninstall() are now virtual functions of GimpProcedure.
2019-08-11 02:25:37 +08:00
plug_in = gimp_procedure_get_plug_in (procedure);
if (! gp_extension_ack_write (_gimp_plug_in_get_write_channel (plug_in),
plug_in))
gimp_quit ();
libgimp: add gimp_procedure_extension_ready() which must be called by GIMP_EXTENSION procedures when they are ready to run their temporary procedures. Move gimp_extension_ack() to gimpobsolete.[ch].
2019-08-02 05:24:49 +08:00
}
libgimp: add GimpProcedureConfig which implements the GimpConfig interface It's the base for bringing proper management of saved settings (including the last used values) and generated GUI using prop_widgets to plug-ins.
2019-09-20 18:31:11 +08:00
/**
* gimp_procedure_create_config:
* @procedure: A #GimpProcedure
*
libgimp: reimplement gimp_procedure_run_config() for public usage. Previous gimp_procedure_run_config() was in fact only good for private usage inside the various run() methods for the different GimpProcedure subtypes. The problem with this implementation is that the returned config object is not complete. For instance, for a GimpLoadProcedure, the "run-mode" and "file" properties are not part of the config object so you cannot call a GimpLoadProcedure with any of the gimp_procedure_run*() functions. Note: we had some working usage, e.g. in file-openraster, but only because it was running the load procedure as a GimpPDBProcedure whose returned config object was indeed always complete! As a consequence, I rename gimp_procedure_run_config() as an internal-only function _gimp_procedure_create_run_config() and I create a new gimp_procedure_run_config() which always return a full config with all arguments.
2024-05-02 03:47:55 +08:00
* Create a #GimpConfig with properties that match @procedure's arguments, to be
* used in [method@Procedure.run_config] method.
libgimp: add GimpProcedureConfig which implements the GimpConfig interface It's the base for bringing proper management of saved settings (including the last used values) and generated GUI using prop_widgets to plug-ins.
2019-09-20 18:31:11 +08:00
*
* Returns: (transfer full): The new #GimpConfig.
*
* Since: 3.0
**/
GimpProcedureConfig *
gimp_procedure_create_config (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
libgimp: add GimpProcedureConfig which implements the GimpConfig interface It's the base for bringing proper management of saved settings (including the last used values) and generated GUI using prop_widgets to plug-ins.
2019-09-20 18:31:11 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
libgimp: reimplement gimp_procedure_run_config() for public usage. Previous gimp_procedure_run_config() was in fact only good for private usage inside the various run() methods for the different GimpProcedure subtypes. The problem with this implementation is that the returned config object is not complete. For instance, for a GimpLoadProcedure, the "run-mode" and "file" properties are not part of the config object so you cannot call a GimpLoadProcedure with any of the gimp_procedure_run*() functions. Note: we had some working usage, e.g. in file-openraster, but only because it was running the load procedure as a GimpPDBProcedure whose returned config object was indeed always complete! As a consequence, I rename gimp_procedure_run_config() as an internal-only function _gimp_procedure_create_run_config() and I create a new gimp_procedure_run_config() which always return a full config with all arguments.
2024-05-02 03:47:55 +08:00
return gimp_procedure_create_config_with_prefix (procedure,
"GimpProcedureConfig",
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->args,
priv->n_args);
libgimp: add GimpProcedureConfig which implements the GimpConfig interface It's the base for bringing proper management of saved settings (including the last used values) and generated GUI using prop_widgets to plug-ins.
2019-09-20 18:31:11 +08:00
}
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
/* private functions */
libgimp: gimp_procedure_new_arguments() can now be made static.
2023-10-19 00:43:08 +08:00
/**
* gimp_procedure_new_arguments:
* @procedure: the #GimpProcedure.
*
* Format the expected argument values of procedures, in the order as
* added with [method@Procedure.add_argument].
*
* Returns: (transfer full): the expected #GimpValueArray which could be given as
* arguments to run @procedure, with all values set to
* defaults. Free with gimp_value_array_unref().
*
* Since: 3.0
**/
static GimpValueArray *
gimp_procedure_new_arguments (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
GimpValueArray *args;
GValue value = G_VALUE_INIT;
gint i;
libgimp: gimp_procedure_new_arguments() can now be made static.
2023-10-19 00:43:08 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
args = gimp_value_array_new (priv->n_args);
libgimp: gimp_procedure_new_arguments() can now be made static.
2023-10-19 00:43:08 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
for (i = 0; i < priv->n_args; i++)
libgimp: gimp_procedure_new_arguments() can now be made static.
2023-10-19 00:43:08 +08:00
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GParamSpec *pspec = priv->args[i];
libgimp: gimp_procedure_new_arguments() can now be made static.
2023-10-19 00:43:08 +08:00
g_value_init (&value, G_PARAM_SPEC_VALUE_TYPE (pspec));
g_param_value_set_default (pspec, &value);
gimp_value_array_append (args, &value);
g_value_unset (&value);
}
return args;
}
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
static gboolean
libgimp: allow object GimpImage as procedure parameter. Though it is still possible to use an image ID as procedure parameter, it is now possible to pass a GimpImage GParamSpecObject. Over the wire, this will transform back and forth into a GimpImageID, totally transparently for the plug-in which will only always get a GimpImage.
2019-08-13 18:34:09 +08:00
gimp_procedure_validate_args (GimpProcedure *procedure,
GParamSpec **param_specs,
gint n_param_specs,
GimpValueArray *args,
gboolean return_vals,
GError **error)
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
{
gint i;
for (i = 0; i < MIN (gimp_value_array_length (args), n_param_specs); i++)
{
GValue *arg = gimp_value_array_index (args, i);
GParamSpec *pspec = param_specs[i];
GType arg_type = G_VALUE_TYPE (arg);
GType spec_type = G_PARAM_SPEC_VALUE_TYPE (pspec);
app, libgimp: validate procedure arguments taking class heritage into… … account.
2021-04-21 06:00:32 +08:00
if (! g_type_is_a (arg_type, spec_type))
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
{
if (return_vals)
{
g_set_error (error,
GIMP_PDB_ERROR, GIMP_PDB_ERROR_INVALID_RETURN_VALUE,
_("Procedure '%s' returned a wrong value type "
"for return value '%s' (#%d). "
"Expected %s, got %s."),
gimp_procedure_get_name (procedure),
g_param_spec_get_name (pspec),
i + 1, g_type_name (spec_type),
g_type_name (arg_type));
}
else
{
g_set_error (error,
GIMP_PDB_ERROR, GIMP_PDB_ERROR_INVALID_ARGUMENT,
_("Procedure '%s' has been called with a "
"wrong value type for argument '%s' (#%d). "
"Expected %s, got %s."),
gimp_procedure_get_name (procedure),
g_param_spec_get_name (pspec),
i + 1, g_type_name (spec_type),
g_type_name (arg_type));
}
return FALSE;
}
libgimp: gimp_procedure_validate_args() support GIMP_PARAM_NO_VALIDATE The flag is defined in libgimp now.
2019-08-13 19:37:52 +08:00
else if (! (pspec->flags & GIMP_PARAM_NO_VALIDATE))
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
{
GValue string_value = G_VALUE_INIT;
g_value_init (&string_value, G_TYPE_STRING);
if (g_value_type_transformable (arg_type, G_TYPE_STRING))
g_value_transform (arg, &string_value);
else
g_value_set_static_string (&string_value,
"<not transformable to string>");
if (g_param_value_validate (pspec, arg))
{
const gchar *value = g_value_get_string (&string_value);
if (value == NULL)
value = "(null)";
if (return_vals)
{
g_set_error (error,
GIMP_PDB_ERROR,
GIMP_PDB_ERROR_INVALID_RETURN_VALUE,
_("Procedure '%s' returned "
"'%s' as return value '%s' "
"(#%d, type %s). "
"This value is out of range."),
gimp_procedure_get_name (procedure),
value,
g_param_spec_get_name (pspec),
i + 1, g_type_name (spec_type));
}
else
{
g_set_error (error,
GIMP_PDB_ERROR,
GIMP_PDB_ERROR_INVALID_ARGUMENT,
_("Procedure '%s' has been called with "
"value '%s' for argument '%s' "
"(#%d, type %s). "
"This value is out of range."),
gimp_procedure_get_name (procedure),
value,
g_param_spec_get_name (pspec),
i + 1, g_type_name (spec_type));
}
g_value_unset (&string_value);
return FALSE;
}
app, libgimp: UTF-8 validate all string arguments and return values The only way for a plug-in to prevent this is now using GIMP_PARAM_NO_VALIDATE.
2019-08-19 19:11:02 +08:00
/* UTT-8 validate all strings */
app, libgimp: also UTF-8-validate all elements of PDB string arrays
2019-08-20 07:46:56 +08:00
if (G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_STRING ||
Remove GimpStringArray in favor of GStrv GLib has a specific type of NULL-terminated string arrays: `G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`. By using this type, we can avoid having a `GimpStringArray` which is a bit cumbersome to use for both the C API, as well as bindings. By using `GStrv`, we allow other languages to pass on string lists as they are used to, while the bindings will make sure to do the right thing. In the end, it makes the API a little bit simpler for everyone, and reduces confusion for people who are used to working with string arrays in other C/GLib based code (and not having 2 different types to denote the same thing). Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
2020-12-24 04:15:43 +08:00
(G_PARAM_SPEC_TYPE (pspec) == G_TYPE_BOXED &&
G_PARAM_SPEC_VALUE_TYPE (pspec) == G_TYPE_STRV))
app, libgimp: UTF-8 validate all string arguments and return values The only way for a plug-in to prevent this is now using GIMP_PARAM_NO_VALIDATE.
2019-08-19 19:11:02 +08:00
{
app, libgimp: also UTF-8-validate all elements of PDB string arrays
2019-08-20 07:46:56 +08:00
gboolean valid = TRUE;
app, libgimp: UTF-8 validate all string arguments and return values The only way for a plug-in to prevent this is now using GIMP_PARAM_NO_VALIDATE.
2019-08-19 19:11:02 +08:00
app, libgimp: also UTF-8-validate all elements of PDB string arrays
2019-08-20 07:46:56 +08:00
if (G_PARAM_SPEC_TYPE (pspec) == G_TYPE_PARAM_STRING)
{
const gchar *string = g_value_get_string (arg);
if (string)
valid = g_utf8_validate (string, -1, NULL);
}
else
{
libgimp: minor nitpick fixes. - Use GLib types even if it's the same thing here. - Remove one redundant test (`*sp` is already tested by the for() loop).
2022-05-25 05:52:15 +08:00
const gchar **strings = g_value_get_boxed (arg);
app, libgimp: also UTF-8-validate all elements of PDB string arrays
2019-08-20 07:46:56 +08:00
libgimp: minor nitpick fixes. - Use GLib types even if it's the same thing here. - Remove one redundant test (`*sp` is already tested by the for() loop).
2022-05-25 05:52:15 +08:00
for (const gchar **sp = strings; sp && *sp && valid; sp++)
valid = g_utf8_validate (*sp, -1, NULL);
app, libgimp: also UTF-8-validate all elements of PDB string arrays
2019-08-20 07:46:56 +08:00
}
if (! valid)
app, libgimp: UTF-8 validate all string arguments and return values The only way for a plug-in to prevent this is now using GIMP_PARAM_NO_VALIDATE.
2019-08-19 19:11:02 +08:00
{
if (return_vals)
{
g_set_error (error,
GIMP_PDB_ERROR,
GIMP_PDB_ERROR_INVALID_RETURN_VALUE,
_("Procedure '%s' returned an "
"invalid UTF-8 string for argument '%s'."),
gimp_procedure_get_name (procedure),
g_param_spec_get_name (pspec));
}
else
{
g_set_error (error,
GIMP_PDB_ERROR,
GIMP_PDB_ERROR_INVALID_ARGUMENT,
_("Procedure '%s' has been called with an "
"invalid UTF-8 string for argument '%s'."),
gimp_procedure_get_name (procedure),
g_param_spec_get_name (pspec));
}
g_value_unset (&string_value);
return FALSE;
}
}
libgimp: add a GimpProcedure class Mostly the same code as GimpProcedure in app/pdb/. Move the "run" function to GimpProcedure. Add API to GimpPlugIn to list and create procedures, and always keep a list of the plug-ins procedures around. Still only using the old params and return_vals.
2019-07-26 08:05:11 +08:00
g_value_unset (&string_value);
}
}
return TRUE;
}
libimp*, app: get rid of inline pixbufs in the API and in pluginrc because they are deprecated. Change GIMP_ICON_TYPE_INLINE_PIXBUF to GIMP_ICON_TYPE_PIXBUF and the libgimp API to (icon-name, GdkPixbuf, GFile). Use the file's uri and a PNG blob of the pixbuf to pass around on the wire and for storage in pluginrc.
2019-08-09 06:05:49 +08:00
static void
gimp_procedure_set_icon (GimpProcedure *procedure,
GimpIconType icon_type,
gconstpointer icon_data)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
libimp*, app: get rid of inline pixbufs in the API and in pluginrc because they are deprecated. Change GIMP_ICON_TYPE_INLINE_PIXBUF to GIMP_ICON_TYPE_PIXBUF and the libgimp API to (icon-name, GdkPixbuf, GFile). Use the file's uri and a PNG blob of the pixbuf to pass around on the wire and for storage in pluginrc.
2019-08-09 06:05:49 +08:00
g_return_if_fail (GIMP_IS_PROCEDURE (procedure));
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
if (icon_data == priv->icon_data)
libimp*, app: get rid of inline pixbufs in the API and in pluginrc because they are deprecated. Change GIMP_ICON_TYPE_INLINE_PIXBUF to GIMP_ICON_TYPE_PIXBUF and the libgimp API to (icon-name, GdkPixbuf, GFile). Use the file's uri and a PNG blob of the pixbuf to pass around on the wire and for storage in pluginrc.
2019-08-09 06:05:49 +08:00
return;
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
switch (priv->icon_type)
libimp*, app: get rid of inline pixbufs in the API and in pluginrc because they are deprecated. Change GIMP_ICON_TYPE_INLINE_PIXBUF to GIMP_ICON_TYPE_PIXBUF and the libgimp API to (icon-name, GdkPixbuf, GFile). Use the file's uri and a PNG blob of the pixbuf to pass around on the wire and for storage in pluginrc.
2019-08-09 06:05:49 +08:00
{
case GIMP_ICON_TYPE_ICON_NAME:
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_clear_pointer (&priv->icon_data, g_free);
libimp*, app: get rid of inline pixbufs in the API and in pluginrc because they are deprecated. Change GIMP_ICON_TYPE_INLINE_PIXBUF to GIMP_ICON_TYPE_PIXBUF and the libgimp API to (icon-name, GdkPixbuf, GFile). Use the file's uri and a PNG blob of the pixbuf to pass around on the wire and for storage in pluginrc.
2019-08-09 06:05:49 +08:00
break;
case GIMP_ICON_TYPE_PIXBUF:
case GIMP_ICON_TYPE_IMAGE_FILE:
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_clear_object (&priv->icon_data);
libimp*, app: get rid of inline pixbufs in the API and in pluginrc because they are deprecated. Change GIMP_ICON_TYPE_INLINE_PIXBUF to GIMP_ICON_TYPE_PIXBUF and the libgimp API to (icon-name, GdkPixbuf, GFile). Use the file's uri and a PNG blob of the pixbuf to pass around on the wire and for storage in pluginrc.
2019-08-09 06:05:49 +08:00
break;
}
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->icon_type = icon_type;
libimp*, app: get rid of inline pixbufs in the API and in pluginrc because they are deprecated. Change GIMP_ICON_TYPE_INLINE_PIXBUF to GIMP_ICON_TYPE_PIXBUF and the libgimp API to (icon-name, GdkPixbuf, GFile). Use the file's uri and a PNG blob of the pixbuf to pass around on the wire and for storage in pluginrc.
2019-08-09 06:05:49 +08:00
switch (icon_type)
{
case GIMP_ICON_TYPE_ICON_NAME:
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv->icon_data = g_strdup (icon_data);
libimp*, app: get rid of inline pixbufs in the API and in pluginrc because they are deprecated. Change GIMP_ICON_TYPE_INLINE_PIXBUF to GIMP_ICON_TYPE_PIXBUF and the libgimp API to (icon-name, GdkPixbuf, GFile). Use the file's uri and a PNG blob of the pixbuf to pass around on the wire and for storage in pluginrc.
2019-08-09 06:05:49 +08:00
break;
case GIMP_ICON_TYPE_PIXBUF:
case GIMP_ICON_TYPE_IMAGE_FILE:
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_set_object (&priv->icon_data, (GObject *) icon_data);
libimp*, app: get rid of inline pixbufs in the API and in pluginrc because they are deprecated. Change GIMP_ICON_TYPE_INLINE_PIXBUF to GIMP_ICON_TYPE_PIXBUF and the libgimp API to (icon-name, GdkPixbuf, GFile). Use the file's uri and a PNG blob of the pixbuf to pass around on the wire and for storage in pluginrc.
2019-08-09 06:05:49 +08:00
break;
default:
g_return_if_reached ();
}
pdb: move gimp_plugin_icon_register_invoker() from "plugin" to "pdb" and call it gimp_pdb_set_proc_icon(). Change icon registration code in libgimp/ and app/ so it's now possible to register icons for temporary procedures.
2019-09-08 22:22:32 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
if (priv->installed)
pdb: move gimp_plugin_icon_register_invoker() from "plugin" to "pdb" and call it gimp_pdb_set_proc_icon(). Change icon registration code in libgimp/ and app/ so it's now possible to register icons for temporary procedures.
2019-09-08 22:22:32 +08:00
gimp_procedure_install_icon (procedure);
libimp*, app: get rid of inline pixbufs in the API and in pluginrc because they are deprecated. Change GIMP_ICON_TYPE_INLINE_PIXBUF to GIMP_ICON_TYPE_PIXBUF and the libgimp API to (icon-name, GdkPixbuf, GFile). Use the file's uri and a PNG blob of the pixbuf to pass around on the wire and for storage in pluginrc.
2019-08-09 06:05:49 +08:00
}
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
/* internal functions */
GimpDisplay *
_gimp_procedure_get_display (GimpProcedure *procedure,
gint32 display_id)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
GimpDisplay *display = NULL;
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
app, libgimp: get rid of all ID GTypes and ID param specs Turn all ID param specs into object param specs (e.g. GimpParamImageID becomes GimpParamImage) and convert between IDs and objects in gimpgpparams.c directly above the the wire protocol, so all of app/, libgimp/ and plug-ins/ can deal directly with objects down to the lowest level and not care about IDs. Use the actual object param specs for procedure arguments and return values again instead of a plain g_param_spec_object() and bring back the none_ok parameter. This implies changing the PDB type checking functions to work on pure integers instead of IDs (one can't check whether object creation is possible if performing that check requires the object to already exist). For example gimp_foo_is_valid() becomes gimp_foo_id_is_valid() and is not involved in automatic object creation magic at the protocol level. Added wrappers which still say gimp_foo_is_valid() and take the respective objects. Adapted all code, and it all becomes nicer and less convoluted, even the generated PDB wrappers in app/ and libgimp/.
2019-08-29 17:25:35 +08:00
g_return_val_if_fail (gimp_display_id_is_valid (display_id), NULL);
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
if (G_UNLIKELY (! priv->displays))
priv->displays =
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
g_hash_table_new_full (g_direct_hash,
g_direct_equal,
NULL,
(GDestroyNotify) g_object_unref);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
display = g_hash_table_lookup (priv->displays,
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
GINT_TO_POINTER (display_id));
if (! display)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
display = _gimp_plug_in_get_display (priv->plug_in,
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
display_id);
if (display)
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_hash_table_insert (priv->displays,
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
GINT_TO_POINTER (display_id),
g_object_ref (display));
}
return display;
}
GimpImage *
_gimp_procedure_get_image (GimpProcedure *procedure,
gint32 image_id)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
GimpImage *image = NULL;
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
app, libgimp: get rid of all ID GTypes and ID param specs Turn all ID param specs into object param specs (e.g. GimpParamImageID becomes GimpParamImage) and convert between IDs and objects in gimpgpparams.c directly above the the wire protocol, so all of app/, libgimp/ and plug-ins/ can deal directly with objects down to the lowest level and not care about IDs. Use the actual object param specs for procedure arguments and return values again instead of a plain g_param_spec_object() and bring back the none_ok parameter. This implies changing the PDB type checking functions to work on pure integers instead of IDs (one can't check whether object creation is possible if performing that check requires the object to already exist). For example gimp_foo_is_valid() becomes gimp_foo_id_is_valid() and is not involved in automatic object creation magic at the protocol level. Added wrappers which still say gimp_foo_is_valid() and take the respective objects. Adapted all code, and it all becomes nicer and less convoluted, even the generated PDB wrappers in app/ and libgimp/.
2019-08-29 17:25:35 +08:00
g_return_val_if_fail (gimp_image_id_is_valid (image_id), NULL);
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
if (G_UNLIKELY (! priv->images))
priv->images =
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
g_hash_table_new_full (g_direct_hash,
g_direct_equal,
NULL,
(GDestroyNotify) g_object_unref);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
image = g_hash_table_lookup (priv->images,
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
GINT_TO_POINTER (image_id));
if (! image)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
image = _gimp_plug_in_get_image (priv->plug_in,
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
image_id);
if (image)
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_hash_table_insert (priv->images,
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
GINT_TO_POINTER (image_id),
g_object_ref (image));
}
return image;
}
GimpItem *
_gimp_procedure_get_item (GimpProcedure *procedure,
gint32 item_id)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
GimpItem *item = NULL;
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
app, libgimp: get rid of all ID GTypes and ID param specs Turn all ID param specs into object param specs (e.g. GimpParamImageID becomes GimpParamImage) and convert between IDs and objects in gimpgpparams.c directly above the the wire protocol, so all of app/, libgimp/ and plug-ins/ can deal directly with objects down to the lowest level and not care about IDs. Use the actual object param specs for procedure arguments and return values again instead of a plain g_param_spec_object() and bring back the none_ok parameter. This implies changing the PDB type checking functions to work on pure integers instead of IDs (one can't check whether object creation is possible if performing that check requires the object to already exist). For example gimp_foo_is_valid() becomes gimp_foo_id_is_valid() and is not involved in automatic object creation magic at the protocol level. Added wrappers which still say gimp_foo_is_valid() and take the respective objects. Adapted all code, and it all becomes nicer and less convoluted, even the generated PDB wrappers in app/ and libgimp/.
2019-08-29 17:25:35 +08:00
g_return_val_if_fail (gimp_item_id_is_valid (item_id), NULL);
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
if (G_UNLIKELY (! priv->items))
priv->items =
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
g_hash_table_new_full (g_direct_hash,
g_direct_equal,
NULL,
(GDestroyNotify) g_object_unref);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
item = g_hash_table_lookup (priv->items,
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
GINT_TO_POINTER (item_id));
if (! item)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
item = _gimp_plug_in_get_item (priv->plug_in,
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
item_id);
if (item)
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_hash_table_insert (priv->items,
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
GINT_TO_POINTER (item_id),
g_object_ref (item));
}
return item;
}
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
GimpResource *
_gimp_procedure_get_resource (GimpProcedure *procedure,
gint32 resource_id)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
GimpResource *resource = NULL;
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
g_return_val_if_fail (GIMP_IS_PROCEDURE (procedure), NULL);
g_return_val_if_fail (gimp_resource_id_is_valid (resource_id), NULL);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
if (G_UNLIKELY (! priv->resources))
priv->resources =
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
g_hash_table_new_full (g_direct_hash,
g_direct_equal,
NULL,
(GDestroyNotify) g_object_unref);
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
resource = g_hash_table_lookup (priv->resources,
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
GINT_TO_POINTER (resource_id));
if (! resource)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
resource = _gimp_plug_in_get_resource (priv->plug_in,
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
resource_id);
if (resource)
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
g_hash_table_insert (priv->resources,
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 22:12:04 +08:00
GINT_TO_POINTER (resource_id),
g_object_ref (resource));
}
return resource;
}
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
void
_gimp_procedure_destroy_proxies (GimpProcedure *procedure)
{
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
GimpProcedurePrivate *priv;
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
g_return_if_fail (GIMP_IS_PROCEDURE (procedure));
libgimp: use G_DECLARE_(DERIVABLE|FINAL)_TYPE macros for all Gimp*Procedure. Though I am not fond of these macros for our core code (it makes the code more cumbersome especially for using private data in derivable types), this definitely makes sense for public API, since it would allow easier modifications with less chances of messing API/ABI stability.
2024-07-10 21:03:15 +08:00
priv = gimp_procedure_get_instance_private (procedure);
g_clear_pointer (&priv->displays, g_hash_table_unref);
g_clear_pointer (&priv->images, g_hash_table_unref);
g_clear_pointer (&priv->items, g_hash_table_unref);
g_clear_pointer (&priv->resources, g_hash_table_unref);
libgimp: memory/lifecycle manage the new libgmp proxy objects Turn GimpPlugIn into the main factory for all proxies and keep the main hash tables there. The hash tables keep the initial reference. For each GimpProcedure::run(), have s "sub-factory" which hands out proxies to the actual procedure code. Each run() has hash tables of its own which hold additional references. When run() is done, get rid of its hash tables and their references, *and* drop the main plug-in reference counts from the global hashes if the proxies' refcount has dropped to one.
2019-08-23 23:18:17 +08:00
}