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

111 lines
8.1 KiB
C
Raw Normal View History

pdb: rename the "procedural_db" PDB group to just "pdb"
2019-08-06 18:50:08 +08:00
/* LIBGIMP - The GIMP Library
* Copyright (C) 1995-2003 Peter Mattis and Spencer Kimball
*
* gimppdb_pdb.h
*
* This library is free software: you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 3 of the License, or (at your option) any later version.
*
* This library 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
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see
* <https://www.gnu.org/licenses/>.
*/
/* NOTE: This file is auto-generated by pdbgen.pl */
#if !defined (__GIMP_H_INSIDE__) && !defined (GIMP_COMPILATION)
#error "Only <libgimp/gimp.h> can be included directly."
#endif
#ifndef __GIMP_PDB_PDB_H__
#define __GIMP_PDB_PDB_H__
G_BEGIN_DECLS
/* For information look into the C source or the html documentation */
pdb: move the file procedure register API from "fileops" to "pdb" because it has nothing to do with the other procedures in fileops and only sets properties on procedures.
2019-09-11 03:24:09 +08:00
G_GNUC_INTERNAL gchar* _gimp_pdb_temp_name (void);
pdb, libgimp: change "filename" to "file" in gimp_pdb_dump()
2019-09-12 04:37:40 +08:00
G_GNUC_INTERNAL gboolean _gimp_pdb_dump (GFile *file);
pdb: move the file procedure register API from "fileops" to "pdb" because it has nothing to do with the other procedures in fileops and only sets properties on procedures.
2019-09-11 03:24:09 +08:00
G_GNUC_INTERNAL gboolean _gimp_pdb_query (const gchar *name,
const gchar *blurb,
const gchar *help,
const gchar *authors,
const gchar *copyright,
const gchar *date,
const gchar *proc_type,
gchar ***procedure_names);
G_GNUC_INTERNAL gboolean _gimp_pdb_proc_exists (const gchar *procedure_name);
G_GNUC_INTERNAL gboolean _gimp_pdb_get_proc_info (const gchar *procedure_name,
GimpPDBProcType *proc_type,
gint *num_args,
gint *num_values);
G_GNUC_INTERNAL GParamSpec* _gimp_pdb_get_proc_argument (const gchar *procedure_name,
gint arg_num);
G_GNUC_INTERNAL GParamSpec* _gimp_pdb_get_proc_return_value (const gchar *procedure_name,
gint val_num);
G_GNUC_INTERNAL gboolean _gimp_pdb_set_proc_image_types (const gchar *procedure_name,
const gchar *image_types);
G_GNUC_INTERNAL gchar* _gimp_pdb_get_proc_image_types (const gchar *procedure_name);
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_GNUC_INTERNAL gboolean _gimp_pdb_set_proc_sensitivity_mask (const gchar *procedure_name,
gint mask);
pdb: move the file procedure register API from "fileops" to "pdb" because it has nothing to do with the other procedures in fileops and only sets properties on procedures.
2019-09-11 03:24:09 +08:00
G_GNUC_INTERNAL gboolean _gimp_pdb_set_proc_menu_label (const gchar *procedure_name,
const gchar *menu_label);
G_GNUC_INTERNAL gchar* _gimp_pdb_get_proc_menu_label (const gchar *procedure_name);
G_GNUC_INTERNAL gboolean _gimp_pdb_add_proc_menu_path (const gchar *procedure_name,
const gchar *menu_path);
app, libgimp: pdbgen for previous commit.
2021-12-02 05:35:25 +08:00
G_GNUC_INTERNAL gchar** _gimp_pdb_get_proc_menu_paths (const gchar *procedure_name);
pdb: move the file procedure register API from "fileops" to "pdb" because it has nothing to do with the other procedures in fileops and only sets properties on procedures.
2019-09-11 03:24:09 +08:00
G_GNUC_INTERNAL gboolean _gimp_pdb_set_proc_icon (const gchar *procedure_name,
GimpIconType icon_type,
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_data);
pdb: move the file procedure register API from "fileops" to "pdb" because it has nothing to do with the other procedures in fileops and only sets properties on procedures.
2019-09-11 03:24:09 +08:00
G_GNUC_INTERNAL gboolean _gimp_pdb_set_proc_documentation (const gchar *procedure_name,
const gchar *blurb,
const gchar *help,
const gchar *help_id);
G_GNUC_INTERNAL gboolean _gimp_pdb_get_proc_documentation (const gchar *procedure_name,
gchar **blurb,
gchar **help,
gchar **help_id);
G_GNUC_INTERNAL gboolean _gimp_pdb_set_proc_attribution (const gchar *procedure_name,
const gchar *authors,
const gchar *copyright,
const gchar *date);
G_GNUC_INTERNAL gboolean _gimp_pdb_get_proc_attribution (const gchar *procedure_name,
gchar **authors,
gchar **copyright,
gchar **date);
G_GNUC_INTERNAL gboolean _gimp_pdb_set_file_proc_load_handler (const gchar *procedure_name,
const gchar *extensions,
const gchar *prefixes,
const gchar *magics);
G_GNUC_INTERNAL gboolean _gimp_pdb_set_file_proc_save_handler (const gchar *procedure_name,
const gchar *extensions,
const gchar *prefixes);
G_GNUC_INTERNAL gboolean _gimp_pdb_set_file_proc_priority (const gchar *procedure_name,
gint priority);
G_GNUC_INTERNAL gboolean _gimp_pdb_set_file_proc_mime_types (const gchar *procedure_name,
const gchar *mime_types);
G_GNUC_INTERNAL gboolean _gimp_pdb_set_file_proc_handles_remote (const gchar *procedure_name);
G_GNUC_INTERNAL gboolean _gimp_pdb_set_file_proc_handles_raw (const gchar *procedure_name);
app, libgimp, pdb: new GimpVectorLoadProcedure class. It's still basic but will help to share code for support of various vector-able formats, such as the logic for dimensioning them, but also the generated GUI. Not only this, but we are paving the way for the link layers (though it'll be after GIMP 3, we want plug-in procedures' API to stay stable) by giving a way for a plug-in procedure to advertize a vector format support. This way, the core will know when a source file is vector and can be directly reloaded at any target size (right now, in my MR for link layers, the list of "vector" formats is hardcoded, which is not reliable).
2024-04-23 05:11:37 +08:00
G_GNUC_INTERNAL gboolean _gimp_pdb_set_file_proc_handles_vector (const gchar *procedure_name);
pdb: move the file procedure register API from "fileops" to "pdb" because it has nothing to do with the other procedures in fileops and only sets properties on procedures.
2019-09-11 03:24:09 +08:00
G_GNUC_INTERNAL gboolean _gimp_pdb_set_file_proc_thumbnail_loader (const gchar *load_proc,
const gchar *thumb_proc);
app, libgimp, pdb, plug-ins: batch CLI options now interpreter aware. The CLI options now know which procedures are batch procedures or not. First it means that it won't just randomly try any procedure name one may pass and will properly output an error if you pass a non-existing interpreter procedure. Secondly, there is no default interpreter anymore (unless only one interpreter exists). If you don't set an interpreter procedure with --batch-interpreter or if you pass a wrong one, it will output the list of available batch procedure, thus helping you understanding how to use the --batch option.
2022-04-17 05:13:50 +08:00
G_GNUC_INTERNAL gboolean _gimp_pdb_set_batch_interpreter (const gchar *procedure_name,
const gchar *interpreter_name);
pdb: move the file procedure register API from "fileops" to "pdb" because it has nothing to do with the other procedures in fileops and only sets properties on procedures.
2019-09-11 03:24:09 +08:00
G_GNUC_INTERNAL gboolean _gimp_pdb_get_data (const gchar *identifier,
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 **data);
pdb: move the file procedure register API from "fileops" to "pdb" because it has nothing to do with the other procedures in fileops and only sets properties on procedures.
2019-09-11 03:24:09 +08:00
G_GNUC_INTERNAL gboolean _gimp_pdb_set_data (const gchar *identifier,
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 *data);
pdb: rename the "procedural_db" PDB group to just "pdb"
2019-08-06 18:50:08 +08:00
G_END_DECLS
#endif /* __GIMP_PDB_PDB_H__ */