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

1032 lines
37 KiB
C
Raw Normal View History

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
/* GIMP - The GNU Image Manipulation Program
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* gimpexportprocedure.c
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
* Copyright (C) 2019 Michael Natterer <mitch@gimp.org>
*
* 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 "gimp.h"
pdb, libgimp: move the old file proc registering API to gimplegacy.[ch] Also, #define GIMP_DISABLE_COMPAT_CRUFT in all GimpPlugIn related files to prevent accidential use of the old API.
2019-08-11 19:21:55 +08:00
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 "libgimpbase/gimpwire.h" /* FIXME kill this include */
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
#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: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
#include "gimpexportprocedure.h"
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
#include "gimpprocedureconfig-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
plug-ins: Mark JPEG export dialog related strings translatable These strings are related to JPEG export dialog which some strings seem not marked as translatable.
2023-08-14 10:34:03 +08:00
#include "libgimp-intl.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
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
/**
* GimpExportProcedure:
*
* Export procedures implement image export.
*
* Registered export procedures will be automatically available in the export
* interfaces and functions of GIMP. The detection (to decide which file is
* redirected to which plug-in procedure) depends on the various methods set
* with [class@FileProcedure] API.
**/
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
enum
{
PROP_0,
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
PROP_CAPABILITIES,
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
PROP_SUPPORTS_EXIF,
PROP_SUPPORTS_IPTC,
PROP_SUPPORTS_XMP,
PROP_SUPPORTS_PROFILE,
PROP_SUPPORTS_THUMBNAIL,
PROP_SUPPORTS_COMMENT,
N_PROPS
};
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
struct _GimpExportProcedure
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
{
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
GimpFileProcedure parent_instance;
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
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
GimpRunExportFunc run_func;
gpointer run_data;
GDestroyNotify run_data_destroy;
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
GimpExportCapabilities capabilities;
app, libgimp*, pdb, plug-ins: review and enhance MR !1549. - Fix annotations for gimp_export_options_get_image() to make it actually introspectable with the GimpImage being both input and output. Even though the logic doesn't change much (the input image may be overriden or not), it doesn't matter for introspection because images are handled centrally by libgimp and therefore must not be freed. Actually deleting the image from the central list of images though remains a manual action depending on code logic, not some automatic action to be handled by binding engines. - Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image() because ignoring the returned value is rarely a good idea (as you usually want to delete the image). - Remove gimp_export_options_new(): we don't need this constructor because at this point, the best is to tell plug-in developers to just pass NULL everywhere. This leaves us free to create a more useful default constructor if needed, in the future. Main description for GimpExportOptions has also been updated to say this. - Add a data_destroy callback for the user data passed in gimp_export_procedure_set_capabilities(). - Fixing annotations of 'export_options' object from pdb/pdb.pl: input args would actually be (nullable) and would not transfer ownership (calling code must still free the object). Return value's ownership on the other hand is fully transfered. - Add C and Python unit testing for GimpExportOptions and gimp_export_options_get_image() in particular. - Fix or improve various details. Note that I have also considered for a long time changing the signature of gimp_export_options_get_image() to return a boolean indicating whether `image` had been replaced (hence needed deletion) or not. This also meant getting rid of the GimpExportReturn enum. Right now it would work because there are no third case, but I was considering the future possibility that for instance we got some impossible conversion for some future capability. I'm not sure it would ever happen; and for sure, this is not desirable because it implies an export failure a bit late in the workflow. But just in case, let's keep the enum return value. It does not even make the using code that much more complicated (well just a value comparison instead of a simple boolean test).
2024-08-17 21:06:27 +08:00
GimpExportOptionsEditFunc edit_func;
gpointer edit_data;
GDestroyNotify edit_data_destroy;
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
gboolean supports_exif;
gboolean supports_iptc;
gboolean supports_xmp;
gboolean supports_profile;
gboolean supports_thumbnail;
gboolean supports_comment;
gboolean export_metadata;
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
};
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
static void gimp_export_procedure_constructed (GObject *object);
static void gimp_export_procedure_finalize (GObject *object);
static void gimp_export_procedure_set_property (GObject *object,
guint property_id,
const GValue *value,
GParamSpec *pspec);
static void gimp_export_procedure_get_property (GObject *object,
guint property_id,
GValue *value,
GParamSpec *pspec);
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
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
static void gimp_export_procedure_install (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
static GimpValueArray *
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
gimp_export_procedure_run (GimpProcedure *procedure,
const GimpValueArray *args);
libgimp: implement GimpProcedure::create_config() in all subclasses
2019-09-24 06:59:50 +08:00
static GimpProcedureConfig *
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
gimp_export_procedure_create_config (GimpProcedure *procedure,
GParamSpec **args,
gint n_args);
static void gimp_export_procedure_add_metadata (GimpExportProcedure *export_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
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
static void gimp_export_procedure_update_options (GimpProcedureConfig *config,
GParamSpec *param,
gpointer data);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
libgimp: 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_DEFINE_TYPE (GimpExportProcedure, gimp_export_procedure, GIMP_TYPE_FILE_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
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
#define parent_class gimp_export_procedure_parent_class
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: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
static GParamSpec *props[N_PROPS] = { 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
static void
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_class_init (GimpExportProcedureClass *klass)
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
{
GObjectClass *object_class = G_OBJECT_CLASS (klass);
GimpProcedureClass *procedure_class = GIMP_PROCEDURE_CLASS (klass);
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
object_class->constructed = gimp_export_procedure_constructed;
object_class->finalize = gimp_export_procedure_finalize;
object_class->get_property = gimp_export_procedure_get_property;
object_class->set_property = gimp_export_procedure_set_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
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
procedure_class->install = gimp_export_procedure_install;
procedure_class->run = gimp_export_procedure_run;
procedure_class->create_config = gimp_export_procedure_create_config;
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
/**
* GimpExportProcedure:capabilities:
*
* What #GimpExportCapabilities are supported
*
* Since: 3.0.0
*/
props[PROP_CAPABILITIES] = g_param_spec_int ("capabilities",
"Supported image capabilities",
NULL,
0, G_MAXINT, 0,
G_PARAM_CONSTRUCT |
GIMP_PARAM_READWRITE);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* GimpExportProcedure:supports-exif:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Whether the export procedure supports EXIF.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Since: 3.0.0
*/
props[PROP_SUPPORTS_EXIF] = g_param_spec_boolean ("supports-exif",
"Supports EXIF metadata storage",
NULL,
FALSE,
G_PARAM_CONSTRUCT |
GIMP_PARAM_READWRITE);
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* GimpExportProcedure:supports-iptc:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Whether the export procedure supports IPTC.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Since: 3.0.0
*/
props[PROP_SUPPORTS_IPTC] = g_param_spec_boolean ("supports-iptc",
"Supports IPTC metadata storage",
NULL,
FALSE,
G_PARAM_CONSTRUCT |
GIMP_PARAM_READWRITE);
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* GimpExportProcedure:supports-xmp:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Whether the export procedure supports XMP.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Since: 3.0.0
*/
props[PROP_SUPPORTS_XMP] = g_param_spec_boolean ("supports-xmp",
"Supports XMP metadata storage",
NULL,
FALSE,
G_PARAM_CONSTRUCT |
GIMP_PARAM_READWRITE);
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* GimpExportProcedure:supports-profile:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Whether the export procedure supports ICC color profiles.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Since: 3.0.0
*/
props[PROP_SUPPORTS_PROFILE] = g_param_spec_boolean ("supports-profile",
"Supports color profile storage",
NULL,
FALSE,
G_PARAM_CONSTRUCT |
GIMP_PARAM_READWRITE);
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* GimpExportProcedure:supports-thumbnail:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Whether the export procedure supports storing a thumbnail.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Since: 3.0.0
*/
props[PROP_SUPPORTS_THUMBNAIL] = g_param_spec_boolean ("supports-thumbnail",
"Supports thumbnail storage",
NULL,
FALSE,
G_PARAM_CONSTRUCT |
GIMP_PARAM_READWRITE);
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* GimpExportProcedure:supports-comment:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Whether the export procedure supports storing a comment.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Since: 3.0.0
*/
props[PROP_SUPPORTS_COMMENT] = g_param_spec_boolean ("supports-comment",
"Supports comment storage",
NULL,
FALSE,
G_PARAM_CONSTRUCT |
GIMP_PARAM_READWRITE);
g_object_class_install_properties (object_class, N_PROPS, props);
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
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_init (GimpExportProcedure *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
{
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
procedure->export_metadata = FALSE;
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
procedure->capabilities = 0;
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
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_constructed (GObject *object)
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
{
GimpProcedure *procedure = GIMP_PROCEDURE (object);
G_OBJECT_CLASS (parent_class)->constructed (object);
plug-ins: Port argument macros to functions With the new API introduced int d1c4457f, we next need to port all plug-ins using the argument macros to functions. This will allow us to remove the macros as part of the 3.0 API clean-up.
2024-06-13 00:53:12 +08:00
gimp_procedure_add_image_argument (procedure, "image",
"Image",
"The image to export",
FALSE,
G_PARAM_READWRITE);
gimp_procedure_add_file_argument (procedure, "file",
"File",
"The file to export to",
GIMP_PARAM_READWRITE);
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
_gimp_procedure_add_argument (procedure,
gimp_param_spec_export_options ("options", "Options",
"Export options", 0,
G_PARAM_READWRITE));
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
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_finalize (GObject *object)
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: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
GimpExportProcedure *procedure = GIMP_EXPORT_PROCEDURE (object);
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
if (procedure->run_data_destroy)
procedure->run_data_destroy (procedure->run_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
G_OBJECT_CLASS (parent_class)->finalize (object);
}
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
static void
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_set_property (GObject *object,
guint property_id,
const GValue *value,
GParamSpec *pspec)
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
{
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
GimpExportProcedure *procedure = GIMP_EXPORT_PROCEDURE (object);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
switch (property_id)
{
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
case PROP_CAPABILITIES:
procedure->capabilities = g_value_get_int (value);
break;
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
case PROP_SUPPORTS_EXIF:
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
procedure->supports_exif = g_value_get_boolean (value);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
break;
case PROP_SUPPORTS_IPTC:
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
procedure->supports_iptc = g_value_get_boolean (value);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
break;
case PROP_SUPPORTS_XMP:
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
procedure->supports_xmp = g_value_get_boolean (value);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
break;
case PROP_SUPPORTS_PROFILE:
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
procedure->supports_profile = g_value_get_boolean (value);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
break;
case PROP_SUPPORTS_THUMBNAIL:
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
procedure->supports_thumbnail = g_value_get_boolean (value);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
break;
case PROP_SUPPORTS_COMMENT:
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
procedure->supports_comment = g_value_get_boolean (value);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, property_id, pspec);
break;
}
}
static void
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_get_property (GObject *object,
guint property_id,
GValue *value,
GParamSpec *pspec)
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
{
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
GimpExportProcedure *procedure = GIMP_EXPORT_PROCEDURE (object);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
switch (property_id)
{
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
case PROP_CAPABILITIES:
g_value_set_int (value, procedure->capabilities);
break;
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
case PROP_SUPPORTS_EXIF:
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_boolean (value, procedure->supports_exif);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
break;
case PROP_SUPPORTS_IPTC:
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_boolean (value, procedure->supports_iptc);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
break;
case PROP_SUPPORTS_XMP:
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_boolean (value, procedure->supports_xmp);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
break;
case PROP_SUPPORTS_PROFILE:
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_boolean (value, procedure->supports_profile);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
break;
case PROP_SUPPORTS_THUMBNAIL:
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_boolean (value, procedure->supports_thumbnail);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
break;
case PROP_SUPPORTS_COMMENT:
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_boolean (value, procedure->supports_comment);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
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
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_install (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
{
GimpFileProcedure *file_proc = GIMP_FILE_PROCEDURE (procedure);
const gchar *mime_types;
gint priority;
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_add_metadata (GIMP_EXPORT_PROCEDURE (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
GIMP_PROCEDURE_CLASS (parent_class)->install (procedure);
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
_gimp_pdb_set_file_proc_save_handler (gimp_procedure_get_name (procedure),
gimp_file_procedure_get_extensions (file_proc),
gimp_file_procedure_get_prefixes (file_proc));
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
Change the "handles uri" flag of file procedures to "handle remote" And always pass URIs to all file procedures, the ones what didn't register as "handles remove" will only ever get local file:// URIs. Change all file plug-ins (also legacy ones) to expect URIs instead of filenames, and convert to local paths in the plug-in. The wire protocol should now be almost 100% clean of non-UTF-8 strings.
2019-08-19 18:05:12 +08:00
if (gimp_file_procedure_get_handles_remote (file_proc))
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
_gimp_pdb_set_file_proc_handles_remote (gimp_procedure_get_name (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
mime_types = gimp_file_procedure_get_mime_types (file_proc);
if (mime_types)
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
_gimp_pdb_set_file_proc_mime_types (gimp_procedure_get_name (procedure),
mime_types);
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
priority = gimp_file_procedure_get_priority (file_proc);
if (priority != 0)
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
_gimp_pdb_set_file_proc_priority (gimp_procedure_get_name (procedure),
priority);
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
}
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
#define ARG_OFFSET 4
libgimp: implement GimpProcedure::create_config() in all subclasses
2019-09-24 06:59:50 +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
static GimpValueArray *
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_run (GimpProcedure *procedure,
const GimpValueArray *args)
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
{
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
GimpPlugIn *plug_in;
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
GimpExportProcedure *export_proc = GIMP_EXPORT_PROCEDURE (procedure);
libgimp, plug-ins: rename to gimp_save_procedure_new(). Also the mimetype is already set by gimp_file_procedure_set_mime_types() so transform the mimetype argument into an export_metadata argument.
2023-07-23 05:49:47 +08:00
GimpValueArray *remaining;
GimpValueArray *return_values;
GimpProcedureConfig *config;
GimpRunMode run_mode;
GimpImage *image;
GFile *file;
GimpMetadata *metadata;
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
GimpExportOptions *options = NULL;
gchar *mimetype = NULL;
GimpPDBStatusType status = GIMP_PDB_EXECUTION_ERROR;
gboolean free_options = 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
plug-ins: Remove n_drawables parameter Port all plug-ins to retrieve the layers directly from the image rather than having them passed in. This resolves some issues with introspection and sets the foundation for future API work.
2024-04-30 21:50:24 +08:00
run_mode = GIMP_VALUES_GET_ENUM (args, 0);
image = GIMP_VALUES_GET_IMAGE (args, 1);
file = GIMP_VALUES_GET_FILE (args, 2);
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
options = g_value_get_object (gimp_value_array_index (args, 3));
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: implement GimpProcedure::create_config() in all subclasses
2019-09-24 06:59:50 +08:00
remaining = gimp_value_array_new (gimp_value_array_length (args) - ARG_OFFSET);
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, plug-ins: rename to gimp_save_procedure_new(). Also the mimetype is already set by gimp_file_procedure_set_mime_types() so transform the mimetype argument into an export_metadata argument.
2023-07-23 05:49:47 +08:00
for (gint i = ARG_OFFSET; i < gimp_value_array_length (args); i++)
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
{
GValue *value = gimp_value_array_index (args, i);
gimp_value_array_append (remaining, value);
}
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: 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 (export_proc->export_metadata)
libgimp: new gimp_save_procedure_new2() meant to replace gimp_save_procedure_new(). Metadata handling is also integrated in this API: * while giving a possibility to disable metadata saving if you want to do it yourself (e.g. in file-heif), by setting a NULL MimeType; * and the GimpMetadata object is added as run() argument, allowing one to edit the metadata during the run, while still letting the infrastucture handle the save (e.g. in file-jpeg); * or to save intermediate metadata with gimp_procedure_config_save_metadata() (e.g. in file-tiff).
2023-07-21 04:47:46 +08:00
{
libgimp, plug-ins: rename to gimp_save_procedure_new(). Also the mimetype is already set by gimp_file_procedure_set_mime_types() so transform the mimetype argument into an export_metadata argument.
2023-07-23 05:49:47 +08:00
mimetype = (gchar *) gimp_file_procedure_get_mime_types (GIMP_FILE_PROCEDURE (procedure));
if (mimetype == NULL)
{
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
g_printerr ("%s: ERROR: the GimpExportProcedureConfig object was created "
libgimp, plug-ins: rename to gimp_save_procedure_new(). Also the mimetype is already set by gimp_file_procedure_set_mime_types() so transform the mimetype argument into an export_metadata argument.
2023-07-23 05:49:47 +08:00
"with export_metadata but you didn't set any MimeType with gimp_file_procedure_set_mime_types()!\n",
G_STRFUNC);
}
else
{
char *delim;
mimetype = g_strdup (mimetype);
mimetype = g_strstrip (mimetype);
delim = strstr (mimetype, ",");
if (delim)
*delim = '\0';
/* Though docs only writes about the list being comma-separated, our
* code apparently also split by spaces.
*/
delim = strstr (mimetype, " ");
if (delim)
*delim = '\0';
delim = strstr (mimetype, "\t");
if (delim)
*delim = '\0';
}
libgimp: new gimp_save_procedure_new2() meant to replace gimp_save_procedure_new(). Metadata handling is also integrated in this API: * while giving a possibility to disable metadata saving if you want to do it yourself (e.g. in file-heif), by setting a NULL MimeType; * and the GimpMetadata object is added as run() argument, allowing one to edit the metadata during the run, while still letting the infrastucture handle the save (e.g. in file-jpeg); * or to save intermediate metadata with gimp_procedure_config_save_metadata() (e.g. in file-tiff).
2023-07-21 04:47:46 +08:00
}
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
metadata = _gimp_procedure_config_begin_export (config, image, run_mode, remaining, mimetype);
libgimp, plug-ins: rename to gimp_save_procedure_new(). Also the mimetype is already set by gimp_file_procedure_set_mime_types() so transform the mimetype argument into an export_metadata argument.
2023-07-23 05:49:47 +08:00
g_free (mimetype);
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
/* GimpExportOptions may be null if called non-interactively from a script,
* so we'll make sure it's initialized */
if (options == NULL)
{
app, libgimp*, pdb, plug-ins: review and enhance MR !1549. - Fix annotations for gimp_export_options_get_image() to make it actually introspectable with the GimpImage being both input and output. Even though the logic doesn't change much (the input image may be overriden or not), it doesn't matter for introspection because images are handled centrally by libgimp and therefore must not be freed. Actually deleting the image from the central list of images though remains a manual action depending on code logic, not some automatic action to be handled by binding engines. - Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image() because ignoring the returned value is rarely a good idea (as you usually want to delete the image). - Remove gimp_export_options_new(): we don't need this constructor because at this point, the best is to tell plug-in developers to just pass NULL everywhere. This leaves us free to create a more useful default constructor if needed, in the future. Main description for GimpExportOptions has also been updated to say this. - Add a data_destroy callback for the user data passed in gimp_export_procedure_set_capabilities(). - Fixing annotations of 'export_options' object from pdb/pdb.pl: input args would actually be (nullable) and would not transfer ownership (calling code must still free the object). Return value's ownership on the other hand is fully transfered. - Add C and Python unit testing for GimpExportOptions and gimp_export_options_get_image() in particular. - Fix or improve various details. Note that I have also considered for a long time changing the signature of gimp_export_options_get_image() to return a boolean indicating whether `image` had been replaced (hence needed deletion) or not. This also meant getting rid of the GimpExportReturn enum. Right now it would work because there are no third case, but I was considering the future possibility that for instance we got some impossible conversion for some future capability. I'm not sure it would ever happen; and for sure, this is not desirable because it implies an export failure a bit late in the workflow. But just in case, let's keep the enum return value. It does not even make the using code that much more complicated (well just a value comparison instead of a simple boolean test).
2024-08-17 21:06:27 +08:00
options = g_object_new (GIMP_TYPE_EXPORT_OPTIONS, NULL);
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
free_options = TRUE;
}
app, libgimp*, pdb, plug-ins: review and enhance MR !1549. - Fix annotations for gimp_export_options_get_image() to make it actually introspectable with the GimpImage being both input and output. Even though the logic doesn't change much (the input image may be overriden or not), it doesn't matter for introspection because images are handled centrally by libgimp and therefore must not be freed. Actually deleting the image from the central list of images though remains a manual action depending on code logic, not some automatic action to be handled by binding engines. - Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image() because ignoring the returned value is rarely a good idea (as you usually want to delete the image). - Remove gimp_export_options_new(): we don't need this constructor because at this point, the best is to tell plug-in developers to just pass NULL everywhere. This leaves us free to create a more useful default constructor if needed, in the future. Main description for GimpExportOptions has also been updated to say this. - Add a data_destroy callback for the user data passed in gimp_export_procedure_set_capabilities(). - Fixing annotations of 'export_options' object from pdb/pdb.pl: input args would actually be (nullable) and would not transfer ownership (calling code must still free the object). Return value's ownership on the other hand is fully transfered. - Add C and Python unit testing for GimpExportOptions and gimp_export_options_get_image() in particular. - Fix or improve various details. Note that I have also considered for a long time changing the signature of gimp_export_options_get_image() to return a boolean indicating whether `image` had been replaced (hence needed deletion) or not. This also meant getting rid of the GimpExportReturn enum. Right now it would work because there are no third case, but I was considering the future possibility that for instance we got some impossible conversion for some future capability. I'm not sure it would ever happen; and for sure, this is not desirable because it implies an export failure a bit late in the workflow. But just in case, let's keep the enum return value. It does not even make the using code that much more complicated (well just a value comparison instead of a simple boolean test).
2024-08-17 21:06:27 +08:00
if (export_proc->edit_func != NULL)
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
{
app, libgimp*, pdb, plug-ins: review and enhance MR !1549. - Fix annotations for gimp_export_options_get_image() to make it actually introspectable with the GimpImage being both input and output. Even though the logic doesn't change much (the input image may be overriden or not), it doesn't matter for introspection because images are handled centrally by libgimp and therefore must not be freed. Actually deleting the image from the central list of images though remains a manual action depending on code logic, not some automatic action to be handled by binding engines. - Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image() because ignoring the returned value is rarely a good idea (as you usually want to delete the image). - Remove gimp_export_options_new(): we don't need this constructor because at this point, the best is to tell plug-in developers to just pass NULL everywhere. This leaves us free to create a more useful default constructor if needed, in the future. Main description for GimpExportOptions has also been updated to say this. - Add a data_destroy callback for the user data passed in gimp_export_procedure_set_capabilities(). - Fixing annotations of 'export_options' object from pdb/pdb.pl: input args would actually be (nullable) and would not transfer ownership (calling code must still free the object). Return value's ownership on the other hand is fully transfered. - Add C and Python unit testing for GimpExportOptions and gimp_export_options_get_image() in particular. - Fix or improve various details. Note that I have also considered for a long time changing the signature of gimp_export_options_get_image() to return a boolean indicating whether `image` had been replaced (hence needed deletion) or not. This also meant getting rid of the GimpExportReturn enum. Right now it would work because there are no third case, but I was considering the future possibility that for instance we got some impossible conversion for some future capability. I'm not sure it would ever happen; and for sure, this is not desirable because it implies an export failure a bit late in the workflow. But just in case, let's keep the enum return value. It does not even make the using code that much more complicated (well just a value comparison instead of a simple boolean test).
2024-08-17 21:06:27 +08:00
export_proc->edit_func (procedure, config, options,
export_proc->edit_data);
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
g_signal_connect_object (config, "notify",
G_CALLBACK (gimp_export_procedure_update_options),
options, 0);
}
else
{
g_object_set (options,
"capabilities", export_proc->capabilities,
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
return_values = export_proc->run_func (procedure, run_mode, image,
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
file, options, metadata,
config, export_proc->run_data);
libgimp, plug-ins: rename to gimp_save_procedure_new(). Also the mimetype is already set by gimp_file_procedure_set_mime_types() so transform the mimetype argument into an export_metadata argument.
2023-07-23 05:49:47 +08:00
if (return_values != NULL &&
gimp_value_array_length (return_values) > 0 &&
G_VALUE_HOLDS_ENUM (gimp_value_array_index (return_values, 0)))
status = GIMP_VALUES_GET_ENUM (return_values, 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_export (config, image, file, status);
libgimp, plug-ins: rename to gimp_save_procedure_new(). Also the mimetype is already set by gimp_file_procedure_set_mime_types() so transform the mimetype argument into an export_metadata argument.
2023-07-23 05:49:47 +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: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
g_printerr ("%s: ERROR: the GimpExportProcedureConfig object was refed "
libgimp, plug-ins: rename to gimp_save_procedure_new(). Also the mimetype is already set by gimp_file_procedure_set_mime_types() so transform the mimetype argument into an export_metadata argument.
2023-07-23 05:49:47 +08:00
"by plug-in, it MUST NOT do that!\n", G_STRFUNC);
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
if (free_options)
g_object_unref (options);
libgimp, plug-ins: rename to gimp_save_procedure_new(). Also the mimetype is already set by gimp_file_procedure_set_mime_types() so transform the mimetype argument into an export_metadata argument.
2023-07-23 05:49:47 +08:00
g_object_unref (config);
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
gimp_value_array_unref (remaining);
app, libgimp*, pdb, plug-ins: review and enhance MR !1549. - Fix annotations for gimp_export_options_get_image() to make it actually introspectable with the GimpImage being both input and output. Even though the logic doesn't change much (the input image may be overriden or not), it doesn't matter for introspection because images are handled centrally by libgimp and therefore must not be freed. Actually deleting the image from the central list of images though remains a manual action depending on code logic, not some automatic action to be handled by binding engines. - Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image() because ignoring the returned value is rarely a good idea (as you usually want to delete the image). - Remove gimp_export_options_new(): we don't need this constructor because at this point, the best is to tell plug-in developers to just pass NULL everywhere. This leaves us free to create a more useful default constructor if needed, in the future. Main description for GimpExportOptions has also been updated to say this. - Add a data_destroy callback for the user data passed in gimp_export_procedure_set_capabilities(). - Fixing annotations of 'export_options' object from pdb/pdb.pl: input args would actually be (nullable) and would not transfer ownership (calling code must still free the object). Return value's ownership on the other hand is fully transfered. - Add C and Python unit testing for GimpExportOptions and gimp_export_options_get_image() in particular. - Fix or improve various details. Note that I have also considered for a long time changing the signature of gimp_export_options_get_image() to return a boolean indicating whether `image` had been replaced (hence needed deletion) or not. This also meant getting rid of the GimpExportReturn enum. Right now it would work because there are no third case, but I was considering the future possibility that for instance we got some impossible conversion for some future capability. I'm not sure it would ever happen; and for sure, this is not desirable because it implies an export failure a bit late in the workflow. But just in case, let's keep the enum return value. It does not even make the using code that much more complicated (well just a value comparison instead of a simple boolean test).
2024-08-17 21:06:27 +08:00
if (export_proc->edit_data_destroy && export_proc->edit_data)
export_proc->edit_data_destroy (export_proc->edit_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
return return_values;
}
libgimp: implement GimpProcedure::create_config() in all subclasses
2019-09-24 06:59:50 +08:00
static GimpProcedureConfig *
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_create_config (GimpProcedure *procedure,
GParamSpec **args,
gint n_args)
libgimp: implement GimpProcedure::create_config() in all subclasses
2019-09-24 06:59:50 +08:00
{
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_add_metadata (GIMP_EXPORT_PROCEDURE (procedure));
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
libgimp: implement GimpProcedure::create_config() in all subclasses
2019-09-24 06:59:50 +08:00
if (n_args > ARG_OFFSET)
{
args += ARG_OFFSET;
n_args -= ARG_OFFSET;
}
else
{
args = NULL;
n_args = 0;
}
return GIMP_PROCEDURE_CLASS (parent_class)->create_config (procedure,
args,
n_args);
}
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
static void
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_add_metadata (GimpExportProcedure *export_procedure)
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
{
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
GimpProcedure *procedure = GIMP_PROCEDURE (export_procedure);
libgimp: only add the generic metadata aux arguments once. There was at least a case when gimp_procedure_create_config() was called twice, hence so was gimp_save_procedure_add_metadata() when a plug-in was run. It was happening when calling a procedure with less arguments than the procedure had. In such case, gimp_procedure_run() would create a config to fill it with defaults. Fixes warnings such as: > LibGimp-WARNING **: 01:29:57.044: Auxiliary argument with name 'save-exif' already exists on procedure 'file-png-save'
2021-04-04 07:23:48 +08:00
static gboolean ran_once = FALSE;
if (ran_once)
return;
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
libgimp: 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 (export_procedure->supports_exif)
plug-ins: Port argument macros to functions With the new API introduced int d1c4457f, we next need to port all plug-ins using the argument macros to functions. This will allow us to remove the macros as part of the 3.0 API clean-up.
2024-06-13 00:53:12 +08:00
gimp_procedure_add_boolean_aux_argument (procedure, "save-exif",
_("Save _Exif"),
_("Save Exif (Exchangeable image file format) metadata"),
gimp_export_exif (),
G_PARAM_READWRITE);
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 (export_procedure->supports_iptc)
plug-ins: Port argument macros to functions With the new API introduced int d1c4457f, we next need to port all plug-ins using the argument macros to functions. This will allow us to remove the macros as part of the 3.0 API clean-up.
2024-06-13 00:53:12 +08:00
gimp_procedure_add_boolean_aux_argument (procedure, "save-iptc",
_("Save _IPTC"),
_("Save IPTC (International Press Telecommunications Council) metadata"),
gimp_export_iptc (),
G_PARAM_READWRITE);
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 (export_procedure->supports_xmp)
plug-ins: Port argument macros to functions With the new API introduced int d1c4457f, we next need to port all plug-ins using the argument macros to functions. This will allow us to remove the macros as part of the 3.0 API clean-up.
2024-06-13 00:53:12 +08:00
gimp_procedure_add_boolean_aux_argument (procedure, "save-xmp",
_("Save _XMP"),
_("Save XMP (Extensible Metadata Platform) metadata"),
gimp_export_xmp (),
G_PARAM_READWRITE);
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 (export_procedure->supports_profile)
plug-ins: Port argument macros to functions With the new API introduced int d1c4457f, we next need to port all plug-ins using the argument macros to functions. This will allow us to remove the macros as part of the 3.0 API clean-up.
2024-06-13 00:53:12 +08:00
gimp_procedure_add_boolean_aux_argument (procedure, "save-color-profile",
_("Save color _profile"),
_("Save the ICC color profile as metadata"),
gimp_export_color_profile (),
G_PARAM_READWRITE);
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 (export_procedure->supports_thumbnail)
plug-ins: Port argument macros to functions With the new API introduced int d1c4457f, we next need to port all plug-ins using the argument macros to functions. This will allow us to remove the macros as part of the 3.0 API clean-up.
2024-06-13 00:53:12 +08:00
gimp_procedure_add_boolean_aux_argument (procedure, "save-thumbnail",
_("Save _thumbnail"),
_("Save a smaller representation of the image as metadata"),
gimp_export_thumbnail (),
G_PARAM_READWRITE);
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 (export_procedure->supports_comment)
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
{
plug-ins: Port argument macros to functions With the new API introduced int d1c4457f, we next need to port all plug-ins using the argument macros to functions. This will allow us to remove the macros as part of the 3.0 API clean-up.
2024-06-13 00:53:12 +08:00
gimp_procedure_add_boolean_aux_argument (procedure, "save-comment",
_("Save c_omment"),
_("Save a comment as metadata"),
gimp_export_comment (),
G_PARAM_READWRITE);
gimp_procedure_add_string_aux_argument (procedure, "gimp-comment",
_("Comment"),
_("Image comment"),
gimp_get_default_comment (),
G_PARAM_READWRITE);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
gimp_procedure_set_argument_sync (procedure, "gimp-comment",
GIMP_ARGUMENT_SYNC_PARASITE);
}
libgimp: only add the generic metadata aux arguments once. There was at least a case when gimp_procedure_create_config() was called twice, hence so was gimp_save_procedure_add_metadata() when a plug-in was run. It was happening when calling a procedure with less arguments than the procedure had. In such case, gimp_procedure_run() would create a config to fill it with defaults. Fixes warnings such as: > LibGimp-WARNING **: 01:29:57.044: Auxiliary argument with name 'save-exif' already exists on procedure 'file-png-save'
2021-04-04 07:23:48 +08:00
ran_once = TRUE;
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
}
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
static void
gimp_export_procedure_update_options (GimpProcedureConfig *config,
GParamSpec *param,
gpointer data)
{
GimpProcedure *procedure;
GimpExportProcedure *export_proc;
GimpExportOptions *options = GIMP_EXPORT_OPTIONS (data);
procedure = gimp_procedure_config_get_procedure (config);
export_proc = GIMP_EXPORT_PROCEDURE (procedure);
app, libgimp*, pdb, plug-ins: review and enhance MR !1549. - Fix annotations for gimp_export_options_get_image() to make it actually introspectable with the GimpImage being both input and output. Even though the logic doesn't change much (the input image may be overriden or not), it doesn't matter for introspection because images are handled centrally by libgimp and therefore must not be freed. Actually deleting the image from the central list of images though remains a manual action depending on code logic, not some automatic action to be handled by binding engines. - Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image() because ignoring the returned value is rarely a good idea (as you usually want to delete the image). - Remove gimp_export_options_new(): we don't need this constructor because at this point, the best is to tell plug-in developers to just pass NULL everywhere. This leaves us free to create a more useful default constructor if needed, in the future. Main description for GimpExportOptions has also been updated to say this. - Add a data_destroy callback for the user data passed in gimp_export_procedure_set_capabilities(). - Fixing annotations of 'export_options' object from pdb/pdb.pl: input args would actually be (nullable) and would not transfer ownership (calling code must still free the object). Return value's ownership on the other hand is fully transfered. - Add C and Python unit testing for GimpExportOptions and gimp_export_options_get_image() in particular. - Fix or improve various details. Note that I have also considered for a long time changing the signature of gimp_export_options_get_image() to return a boolean indicating whether `image` had been replaced (hence needed deletion) or not. This also meant getting rid of the GimpExportReturn enum. Right now it would work because there are no third case, but I was considering the future possibility that for instance we got some impossible conversion for some future capability. I'm not sure it would ever happen; and for sure, this is not desirable because it implies an export failure a bit late in the workflow. But just in case, let's keep the enum return value. It does not even make the using code that much more complicated (well just a value comparison instead of a simple boolean test).
2024-08-17 21:06:27 +08:00
export_proc->edit_func (procedure, config, options,
export_proc->edit_data);
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +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
/* public functions */
libgimp: rename GimpLoad,SaveFunc to GimpRunLoad,SaveFunc and document gimp_load,save_procedure_new().
2019-08-11 20:58:55 +08:00
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* gimp_export_procedure_new:
libgimp: rename GimpLoad,SaveFunc to GimpRunLoad,SaveFunc and document gimp_load,save_procedure_new().
2019-08-11 20:58:55 +08:00
* @plug_in: a #GimpPlugIn.
* @name: the new procedure's name.
* @proc_type: the new procedure's #GimpPDBProcType.
libgimp, plug-ins: rename to gimp_save_procedure_new(). Also the mimetype is already set by gimp_file_procedure_set_mime_types() so transform the mimetype argument into an export_metadata argument.
2023-07-23 05:49:47 +08:00
* @export_metadata: whether GIMP should handle metadata exporting.
libgimp: rename GimpLoad,SaveFunc to GimpRunLoad,SaveFunc and document gimp_load,save_procedure_new().
2019-08-11 20:58:55 +08:00
* @run_func: the run function for the new procedure.
* @run_data: user data passed to @run_func.
* @run_data_destroy: (nullable): free function for @run_data, or %NULL.
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Creates a new export procedure named @name which will call @run_func
libgimp: rename GimpLoad,SaveFunc to GimpRunLoad,SaveFunc and document gimp_load,save_procedure_new().
2019-08-11 20:58:55 +08:00
* when invoked.
*
* See gimp_procedure_new() for information about @proc_type.
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* #GimpExportProcedure is a #GimpProcedure subclass that makes it easier
* to write file export procedures.
libgimp: rename GimpLoad,SaveFunc to GimpRunLoad,SaveFunc and document gimp_load,save_procedure_new().
2019-08-11 20:58:55 +08:00
*
* It automatically adds the standard
*
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
* (#GimpRunMode, #GimpImage, #GFile, #GimpExportOptions)
libgimp: rename GimpLoad,SaveFunc to GimpRunLoad,SaveFunc and document gimp_load,save_procedure_new().
2019-08-11 20:58:55 +08:00
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* arguments of an export procedure. It is possible to add additional
libgimp: rename GimpLoad,SaveFunc to GimpRunLoad,SaveFunc and document gimp_load,save_procedure_new().
2019-08-11 20:58:55 +08:00
* arguments.
*
* When invoked via gimp_procedure_run(), it unpacks these standard
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* arguments and calls @run_func which is a #GimpRunExportFunc. The
* #GimpProcedureConfig of #GimpRunExportFunc only contains additionally added
libgimp, plug-ins: rename to gimp_save_procedure_new(). Also the mimetype is already set by gimp_file_procedure_set_mime_types() so transform the mimetype argument into an export_metadata argument.
2023-07-23 05:49:47 +08:00
* arguments.
*
* If @export_metadata is TRUE, then the class will also handle the metadata
* export if the format is supported by our backend. This requires you to also
* set appropriate MimeType with gimp_file_procedure_set_mime_types().
libgimp: rename GimpLoad,SaveFunc to GimpRunLoad,SaveFunc and document gimp_load,save_procedure_new().
2019-08-11 20:58:55 +08:00
*
* Returns: a new #GimpProcedure.
*
* Since: 3.0
**/
libgimp, plug-ins: rename to gimp_save_procedure_new(). Also the mimetype is already set by gimp_file_procedure_set_mime_types() so transform the mimetype argument into an export_metadata argument.
2023-07-23 05:49:47 +08:00
GimpProcedure *
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_new (GimpPlugIn *plug_in,
const gchar *name,
GimpPDBProcType proc_type,
gboolean export_metadata,
GimpRunExportFunc run_func,
gpointer run_data,
GDestroyNotify run_data_destroy)
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: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
GimpExportProcedure *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
g_return_val_if_fail (GIMP_IS_PLUG_IN (plug_in), NULL);
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);
g_return_val_if_fail (proc_type != GIMP_PDB_PROC_TYPE_EXTENSION, 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
g_return_val_if_fail (run_func != NULL, NULL);
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
procedure = g_object_new (GIMP_TYPE_EXPORT_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
"plug-in", plug_in,
"name", name,
"procedure-type", proc_type,
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
procedure->run_func = run_func;
procedure->export_metadata = export_metadata;
procedure->run_data = run_data;
procedure->run_data_destroy = run_data_destroy;
libgimp: new gimp_save_procedure_new2() meant to replace gimp_save_procedure_new(). Metadata handling is also integrated in this API: * while giving a possibility to disable metadata saving if you want to do it yourself (e.g. in file-heif), by setting a NULL MimeType; * and the GimpMetadata object is added as run() argument, allowing one to edit the metadata during the run, while still letting the infrastucture handle the save (e.g. in file-jpeg); * or to save intermediate metadata with gimp_procedure_config_save_metadata() (e.g. in file-tiff).
2023-07-21 04:47:46 +08:00
return GIMP_PROCEDURE (procedure);
}
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
/**
* gimp_export_procedure_set_capabilities:
* @procedure: a #GimpProcedure.
* @capabilities: a #GimpExportCapabilities enum
app, libgimp*, pdb, plug-ins: review and enhance MR !1549. - Fix annotations for gimp_export_options_get_image() to make it actually introspectable with the GimpImage being both input and output. Even though the logic doesn't change much (the input image may be overriden or not), it doesn't matter for introspection because images are handled centrally by libgimp and therefore must not be freed. Actually deleting the image from the central list of images though remains a manual action depending on code logic, not some automatic action to be handled by binding engines. - Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image() because ignoring the returned value is rarely a good idea (as you usually want to delete the image). - Remove gimp_export_options_new(): we don't need this constructor because at this point, the best is to tell plug-in developers to just pass NULL everywhere. This leaves us free to create a more useful default constructor if needed, in the future. Main description for GimpExportOptions has also been updated to say this. - Add a data_destroy callback for the user data passed in gimp_export_procedure_set_capabilities(). - Fixing annotations of 'export_options' object from pdb/pdb.pl: input args would actually be (nullable) and would not transfer ownership (calling code must still free the object). Return value's ownership on the other hand is fully transfered. - Add C and Python unit testing for GimpExportOptions and gimp_export_options_get_image() in particular. - Fix or improve various details. Note that I have also considered for a long time changing the signature of gimp_export_options_get_image() to return a boolean indicating whether `image` had been replaced (hence needed deletion) or not. This also meant getting rid of the GimpExportReturn enum. Right now it would work because there are no third case, but I was considering the future possibility that for instance we got some impossible conversion for some future capability. I'm not sure it would ever happen; and for sure, this is not desirable because it implies an export failure a bit late in the workflow. But just in case, let's keep the enum return value. It does not even make the using code that much more complicated (well just a value comparison instead of a simple boolean test).
2024-08-17 21:06:27 +08:00
* @edit_func: (nullable): callback function to update export options
* @edit_data: (nullable): data for @edit_func
* @edit_data_destroy: (nullable): free function for @edit_data, or %NULL
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
*
* Sets default #GimpExportCapabilities for image export.
*
* Since: 3.0
**/
void
gimp_export_procedure_set_capabilities (GimpExportProcedure *procedure,
GimpExportCapabilities capabilities,
app, libgimp*, pdb, plug-ins: review and enhance MR !1549. - Fix annotations for gimp_export_options_get_image() to make it actually introspectable with the GimpImage being both input and output. Even though the logic doesn't change much (the input image may be overriden or not), it doesn't matter for introspection because images are handled centrally by libgimp and therefore must not be freed. Actually deleting the image from the central list of images though remains a manual action depending on code logic, not some automatic action to be handled by binding engines. - Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image() because ignoring the returned value is rarely a good idea (as you usually want to delete the image). - Remove gimp_export_options_new(): we don't need this constructor because at this point, the best is to tell plug-in developers to just pass NULL everywhere. This leaves us free to create a more useful default constructor if needed, in the future. Main description for GimpExportOptions has also been updated to say this. - Add a data_destroy callback for the user data passed in gimp_export_procedure_set_capabilities(). - Fixing annotations of 'export_options' object from pdb/pdb.pl: input args would actually be (nullable) and would not transfer ownership (calling code must still free the object). Return value's ownership on the other hand is fully transfered. - Add C and Python unit testing for GimpExportOptions and gimp_export_options_get_image() in particular. - Fix or improve various details. Note that I have also considered for a long time changing the signature of gimp_export_options_get_image() to return a boolean indicating whether `image` had been replaced (hence needed deletion) or not. This also meant getting rid of the GimpExportReturn enum. Right now it would work because there are no third case, but I was considering the future possibility that for instance we got some impossible conversion for some future capability. I'm not sure it would ever happen; and for sure, this is not desirable because it implies an export failure a bit late in the workflow. But just in case, let's keep the enum return value. It does not even make the using code that much more complicated (well just a value comparison instead of a simple boolean test).
2024-08-17 21:06:27 +08:00
GimpExportOptionsEditFunc edit_func,
gpointer edit_data,
GDestroyNotify edit_data_destroy)
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
{
g_return_if_fail (GIMP_IS_EXPORT_PROCEDURE (procedure));
/* Assign default image capabilities */
g_object_set (procedure,
"capabilities", capabilities,
NULL);
/* TODO: Do more with this when we have user-specified callbacks for
* image capabilities */
app, libgimp*, pdb, plug-ins: review and enhance MR !1549. - Fix annotations for gimp_export_options_get_image() to make it actually introspectable with the GimpImage being both input and output. Even though the logic doesn't change much (the input image may be overriden or not), it doesn't matter for introspection because images are handled centrally by libgimp and therefore must not be freed. Actually deleting the image from the central list of images though remains a manual action depending on code logic, not some automatic action to be handled by binding engines. - Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image() because ignoring the returned value is rarely a good idea (as you usually want to delete the image). - Remove gimp_export_options_new(): we don't need this constructor because at this point, the best is to tell plug-in developers to just pass NULL everywhere. This leaves us free to create a more useful default constructor if needed, in the future. Main description for GimpExportOptions has also been updated to say this. - Add a data_destroy callback for the user data passed in gimp_export_procedure_set_capabilities(). - Fixing annotations of 'export_options' object from pdb/pdb.pl: input args would actually be (nullable) and would not transfer ownership (calling code must still free the object). Return value's ownership on the other hand is fully transfered. - Add C and Python unit testing for GimpExportOptions and gimp_export_options_get_image() in particular. - Fix or improve various details. Note that I have also considered for a long time changing the signature of gimp_export_options_get_image() to return a boolean indicating whether `image` had been replaced (hence needed deletion) or not. This also meant getting rid of the GimpExportReturn enum. Right now it would work because there are no third case, but I was considering the future possibility that for instance we got some impossible conversion for some future capability. I'm not sure it would ever happen; and for sure, this is not desirable because it implies an export failure a bit late in the workflow. But just in case, let's keep the enum return value. It does not even make the using code that much more complicated (well just a value comparison instead of a simple boolean test).
2024-08-17 21:06:27 +08:00
if (edit_func != NULL)
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
{
app, libgimp*, pdb, plug-ins: review and enhance MR !1549. - Fix annotations for gimp_export_options_get_image() to make it actually introspectable with the GimpImage being both input and output. Even though the logic doesn't change much (the input image may be overriden or not), it doesn't matter for introspection because images are handled centrally by libgimp and therefore must not be freed. Actually deleting the image from the central list of images though remains a manual action depending on code logic, not some automatic action to be handled by binding engines. - Add G_GNUC_WARN_UNUSED_RESULT to gimp_export_options_get_image() because ignoring the returned value is rarely a good idea (as you usually want to delete the image). - Remove gimp_export_options_new(): we don't need this constructor because at this point, the best is to tell plug-in developers to just pass NULL everywhere. This leaves us free to create a more useful default constructor if needed, in the future. Main description for GimpExportOptions has also been updated to say this. - Add a data_destroy callback for the user data passed in gimp_export_procedure_set_capabilities(). - Fixing annotations of 'export_options' object from pdb/pdb.pl: input args would actually be (nullable) and would not transfer ownership (calling code must still free the object). Return value's ownership on the other hand is fully transfered. - Add C and Python unit testing for GimpExportOptions and gimp_export_options_get_image() in particular. - Fix or improve various details. Note that I have also considered for a long time changing the signature of gimp_export_options_get_image() to return a boolean indicating whether `image` had been replaced (hence needed deletion) or not. This also meant getting rid of the GimpExportReturn enum. Right now it would work because there are no third case, but I was considering the future possibility that for instance we got some impossible conversion for some future capability. I'm not sure it would ever happen; and for sure, this is not desirable because it implies an export failure a bit late in the workflow. But just in case, let's keep the enum return value. It does not even make the using code that much more complicated (well just a value comparison instead of a simple boolean test).
2024-08-17 21:06:27 +08:00
procedure->edit_func = edit_func;
procedure->edit_data = edit_data;
procedure->edit_data_destroy = edit_data_destroy;
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-07 02:38:12 +08:00
}
}
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* gimp_export_procedure_set_support_exif:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* @procedure: a #GimpProcedure.
* @supports: whether Exif metadata are supported.
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Determine whether @procedure supports exporting Exif data. By default,
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* it won't (so there is usually no reason to run this function with
* %FALSE).
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
*
* This will have several consequences:
*
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* - Automatically adds a standard auxiliary argument "save-exif" in the
* end of the argument list of @procedure, with relevant blurb and
* description.
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* - If used with other gimp_export_procedure_set_support_*() functions,
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* they will always be ordered the same (the order of the calls don't
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* matter), keeping all export procedures consistent.
* - Generated GimpExportProcedureDialog will contain the metadata
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* options, once again always in the same order and with consistent
* GUI style across plug-ins.
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
* - API from [class@ProcedureConfig] will automatically process these
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* properties to decide whether to export a given metadata or not.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Note that since this is an auxiliary argument, it won't be part of
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
* the PDB arguments. By default, the value will be [func@export_exif].
*
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* Since: 3.0
**/
void
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_set_support_exif (GimpExportProcedure *procedure,
gboolean supports)
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
{
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
g_return_if_fail (GIMP_IS_EXPORT_PROCEDURE (procedure));
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
g_object_set (procedure,
"supports-exif", supports,
NULL);
}
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* gimp_export_procedure_set_support_iptc:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* @procedure: a #GimpProcedure.
* @supports: whether IPTC metadata are supported.
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Determine whether @procedure supports exporting IPTC data. By default,
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* it won't (so there is usually no reason to run this function with
* %FALSE).
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
*
* This will have several consequences:
*
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* - Automatically adds a standard auxiliary argument "save-iptc" in the
* end of the argument list of @procedure, with relevant blurb and
* description.
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* - If used with other gimp_export_procedure_set_support_*() functions,
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* they will always be ordered the same (the order of the calls don't
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* matter), keeping all export procedures consistent.
* - Generated GimpExportProcedureDialog will contain the metadata
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* options, once again always in the same order and with consistent
* GUI style across plug-ins.
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
* - API from [class@ProcedureConfig] will automatically process these
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* properties to decide whether to export a given metadata or not.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Note that since this is an auxiliary argument, it won't be part of
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
* the PDB arguments. By default, the value will be [func@export_iptc].
*
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* Since: 3.0
**/
void
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_set_support_iptc (GimpExportProcedure *procedure,
gboolean supports)
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
{
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
g_return_if_fail (GIMP_IS_EXPORT_PROCEDURE (procedure));
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
g_object_set (procedure,
"supports-iptc", supports,
NULL);
}
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* gimp_export_procedure_set_support_xmp:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* @procedure: a #GimpProcedure.
* @supports: whether XMP metadata are supported.
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Determine whether @procedure supports exporting XMP data. By default,
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* it won't (so there is usually no reason to run this function with
* %FALSE).
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
*
* This will have several consequences:
*
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* - Automatically adds a standard auxiliary argument "save-xmp" in the
* end of the argument list of @procedure, with relevant blurb and
* description.
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* - If used with other gimp_export_procedure_set_support_*() functions,
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* they will always be ordered the same (the order of the calls don't
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* matter), keeping all export procedures consistent.
* - Generated GimpExportProcedureDialog will contain the metadata
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* options, once again always in the same order and with consistent
* GUI style across plug-ins.
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
* - API from [class@ProcedureConfig] will automatically process these
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* properties to decide whether to export a given metadata or not.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Note that since this is an auxiliary argument, it won't be part of
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
* the PDB arguments. By default, the value will be [func@export_xmp].
*
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* Since: 3.0
**/
void
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_set_support_xmp (GimpExportProcedure *procedure,
gboolean supports)
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
{
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
g_return_if_fail (GIMP_IS_EXPORT_PROCEDURE (procedure));
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
g_object_set (procedure,
"supports-xmp", supports,
NULL);
}
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* gimp_export_procedure_set_support_profile:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* @procedure: a #GimpProcedure.
* @supports: whether color profiles can be stored.
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Determine whether @procedure supports exporting ICC color profiles. By
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* default, it won't (so there is usually no reason to run this function
* with %FALSE).
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
*
* This will have several consequences:
*
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* - Automatically adds a standard auxiliary argument
* "save-color-profile" in the end of the argument list of @procedure,
* with relevant blurb and description.
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* - If used with other gimp_export_procedure_set_support_*() functions,
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* they will always be ordered the same (the order of the calls don't
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* matter), keeping all export procedures consistent.
* - Generated GimpExportProcedureDialog will contain the metadata
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* options, once again always in the same order and with consistent
* GUI style across plug-ins.
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
* - API from [class@ProcedureConfig] will automatically process these
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* properties to decide whether to export a given metadata or not.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Note that since this is an auxiliary argument, it won't be part of
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
* the PDB arguments. By default, the value will be [func@export_color_profile].
*
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* Since: 3.0
**/
void
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_set_support_profile (GimpExportProcedure *procedure,
gboolean supports)
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
{
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
g_return_if_fail (GIMP_IS_EXPORT_PROCEDURE (procedure));
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
g_object_set (procedure,
"supports-profile", supports,
NULL);
}
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* gimp_export_procedure_set_support_thumbnail:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* @procedure: a #GimpProcedure.
* @supports: whether a thumbnail can be stored.
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Determine whether @procedure supports exporting a thumbnail. By default,
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* it won't (so there is usually no reason to run this function with
* %FALSE).
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
*
* This will have several consequences:
*
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* - Automatically adds a standard auxiliary argument "save-thumbnail"
* in the end of the argument list of @procedure, with relevant blurb
* and description.
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* - If used with other gimp_export_procedure_set_support_*() functions,
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* they will always be ordered the same (the order of the calls don't
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* matter), keeping all export procedures consistent.
* - Generated GimpExportProcedureDialog will contain the metadata
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* options, once again always in the same order and with consistent
* GUI style across plug-ins.
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
* - API from [class@ProcedureConfig] will automatically process these
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* properties to decide whether to export a given metadata or not.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Note that since this is an auxiliary argument, it won't be part of
app, libgimp: Add metadata preference for saving thumbnail by default Saving a thumbnail is closely related to the other metadata preferences, but so far this was the only one that didn't have a preference for a default user value. This commit adds a preference in the metadata section where a user can select whether thumbnail saving is enabled by default or not.
2021-08-26 03:00:45 +08:00
* the PDB arguments. By default, the value will be
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
* [func@export_thumbnail].
*
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* Since: 3.0
**/
void
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_set_support_thumbnail (GimpExportProcedure *procedure,
gboolean supports)
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
{
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
g_return_if_fail (GIMP_IS_EXPORT_PROCEDURE (procedure));
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
g_object_set (procedure,
"supports-thumbnail", supports,
NULL);
}
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* gimp_export_procedure_set_support_comment:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* @procedure: a #GimpProcedure.
* @supports: whether a comment can be stored.
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Determine whether @procedure supports exporting a comment. By default,
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* it won't (so there is usually no reason to run this function with
* %FALSE).
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
*
* This will have several consequences:
*
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* - Automatically adds a standard auxiliary argument "save-comment"
* in the end of the argument list of @procedure, with relevant blurb
* and description.
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* - If used with other gimp_export_procedure_set_support_*() functions,
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* they will always be ordered the same (the order of the calls don't
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* matter), keeping all export procedures consistent.
* - Generated GimpExportProcedureDialog will contain the metadata
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* options, once again always in the same order and with consistent
* GUI style across plug-ins.
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
* - API from [class@ProcedureConfig] will automatically process these
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* properties to decide whether to export a given metadata or not.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Note that since this is an auxiliary argument, it won't be part of
* the PDB arguments. By default, the value will be
docs: Migrate some gtk-doc comments to gi-docgen
2021-12-29 18:21:19 +08:00
* [func@export_comment].
*
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* Since: 3.0
**/
void
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_set_support_comment (GimpExportProcedure *procedure,
gboolean supports)
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
{
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
g_return_if_fail (GIMP_IS_EXPORT_PROCEDURE (procedure));
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
g_object_set (procedure,
"supports-comment", supports,
NULL);
}
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* gimp_export_procedure_get_support_exif:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* @procedure: a #GimpProcedure.
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Returns: %TRUE if @procedure supports Exif exporting.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Since: 3.0
**/
gboolean
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_get_support_exif (GimpExportProcedure *procedure)
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
{
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
g_return_val_if_fail (GIMP_IS_EXPORT_PROCEDURE (procedure), FALSE);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
libgimp: 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 procedure->supports_exif;
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
}
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* gimp_export_procedure_get_support_iptc:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* @procedure: a #GimpProcedure.
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Returns: %TRUE if @procedure supports IPTC exporting.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Since: 3.0
**/
gboolean
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_get_support_iptc (GimpExportProcedure *procedure)
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
{
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
g_return_val_if_fail (GIMP_IS_EXPORT_PROCEDURE (procedure), FALSE);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
libgimp: 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 procedure->supports_iptc;
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
}
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* gimp_export_procedure_get_support_xmp:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* @procedure: a #GimpProcedure.
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Returns: %TRUE if @procedure supports XMP exporting.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Since: 3.0
**/
gboolean
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_get_support_xmp (GimpExportProcedure *procedure)
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
{
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
g_return_val_if_fail (GIMP_IS_EXPORT_PROCEDURE (procedure), FALSE);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
libgimp: 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 procedure->supports_xmp;
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
}
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* gimp_export_procedure_get_support_profile:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* @procedure: a #GimpProcedure.
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Returns: %TRUE if @procedure supports ICC color profile exporting.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Since: 3.0
**/
gboolean
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_get_support_profile (GimpExportProcedure *procedure)
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
{
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
g_return_val_if_fail (GIMP_IS_EXPORT_PROCEDURE (procedure), FALSE);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
libgimp: 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 procedure->supports_profile;
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
}
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* gimp_export_procedure_get_support_thumbnail:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* @procedure: a #GimpProcedure.
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Returns: %TRUE if @procedure supports thumbnail exporting.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Since: 3.0
**/
gboolean
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_get_support_thumbnail (GimpExportProcedure *procedure)
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
{
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
g_return_val_if_fail (GIMP_IS_EXPORT_PROCEDURE (procedure), FALSE);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
libgimp: 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 procedure->supports_thumbnail;
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
}
/**
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* gimp_export_procedure_get_support_comment:
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
* @procedure: a #GimpProcedure.
*
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
* Returns: %TRUE if @procedure supports comment exporting.
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
*
* Since: 3.0
**/
gboolean
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
gimp_export_procedure_get_support_comment (GimpExportProcedure *procedure)
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
{
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 11:08:57 +08:00
g_return_val_if_fail (GIMP_IS_EXPORT_PROCEDURE (procedure), FALSE);
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
libgimp: 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 procedure->supports_comment;
libgimp: new metadata support concept in GimpSaveProcedure and new… … class GimpSaveProcedureDialog. The idea is that we have basically the same code in most file format plug-ins to handle various generic metadata, yet usually with slight differences here and there. Even behavior is sometimes a bit different even though there is no reason for the logics to be different from one format to another. So I move the metadata support logics into GimpSaveProcedure (and GimpProcedureConfig still keeps the main export logics). The GUI logics is now in a new GimpSaveProcedureDialog. So export plug-ins will now get the creation of generic metadata nearly for free. All they have to do is to tell what kind of metadata the GimpSaveProcedure supports with the gimp_save_procedure_set_support_*() functions. Then consistency will apply: - If a format supports a given metadata, they will always have an auxiliary argument with the same name across plug-ins. - The label and tooltips will also be always the same in the GUI. - Order of metadata widgets will also stay consistent. - The widgets will work the same (no more "Comment" text view missing in one plug-in but present in another, or with an entry here, and a text view there, and so on). Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins to "declare" one of their options as a metadata option, and therefore have it packed within the "Metadata" block which is now created (for instance for PNG/TIFF/JPEG specific metadata). This allows a nicer organization of dialogs.
2020-11-21 08:15:15 +08:00
}