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

930 lines
33 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,
PROP_SUPPORTS_EXIF,
PROP_SUPPORTS_IPTC,
PROP_SUPPORTS_XMP,
PROP_SUPPORTS_PROFILE,
PROP_SUPPORTS_THUMBNAIL,
PROP_SUPPORTS_COMMENT,
N_PROPS
};
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
struct _GimpExportProcedurePrivate
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
GimpRunExportFunc run_func;
gpointer run_data;
GDestroyNotify run_data_destroy;
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
};
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
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
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
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 *
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: 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: 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
static void 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: 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
G_DEFINE_TYPE_WITH_PRIVATE (GimpExportProcedure, gimp_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
GIMP_TYPE_FILE_PROCEDURE)
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
/**
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: 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->priv = gimp_export_procedure_get_instance_private (procedure);
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
procedure->priv->export_metadata = 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
}
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);
libgimp, plug-ins: use the new macros everwhere Except for gimp_param_spec_string() which is on its way back to the core.
2019-08-19 16:02:07 +08:00
GIMP_PROC_ARG_IMAGE (procedure, "image",
"Image",
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
"The image to export",
app, libgimp: get rid of all ID GTypes and ID param specs Turn all ID param specs into object param specs (e.g. GimpParamImageID becomes GimpParamImage) and convert between IDs and objects in gimpgpparams.c directly above the the wire protocol, so all of app/, libgimp/ and plug-ins/ can deal directly with objects down to the lowest level and not care about IDs. Use the actual object param specs for procedure arguments and return values again instead of a plain g_param_spec_object() and bring back the none_ok parameter. This implies changing the PDB type checking functions to work on pure integers instead of IDs (one can't check whether object creation is possible if performing that check requires the object to already exist). For example gimp_foo_is_valid() becomes gimp_foo_id_is_valid() and is not involved in automatic object creation magic at the protocol level. Added wrappers which still say gimp_foo_is_valid() and take the respective objects. Adapted all code, and it all becomes nicer and less convoluted, even the generated PDB wrappers in app/ and libgimp/.
2019-08-29 17:25:35 +08:00
FALSE,
libgimp, plug-ins: use the new macros everwhere Except for gimp_param_spec_string() which is on its way back to the core.
2019-08-19 16:02:07 +08:00
G_PARAM_READWRITE);
app: support saving/exporting with multi-selection. This commit just changes our saving API (i.e. the GimpSaveProcedure class) to take an array of drawables as argument instead of a single drawable. It actually doesn't matter much for exporting as the whole API seems more or less bogus there and all formats plug-ins mostly care only whether they will merge/flatten all visible layers (the selected ones don't really matter) or if the format supports layers of some sort. It may be worth later strengthening a bit this whole logics, and maybe allow partial exports for instance. As for saving, it was not even looking at the passed GimpDrawable either and was simply re-querying the active layer anyway. Note that I don't implement the multi-selection saving in XCF yet in this commit. I only updated the API. The reason is that the current commit won't be backportable to gimp-2-10 because it is an API break. On the other hand, the code to save multi-selection can still be backported even though the save() API will only pass a single drawable (as I said anyway, this argument was mostly bogus until now, hence it doesn't matter much for 2.10 logics).
2020-04-14 17:46:17 +08:00
GIMP_PROC_ARG_INT (procedure, "num-drawables",
"Number of drawables",
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
"Number of drawables to be exported",
app: support saving/exporting with multi-selection. This commit just changes our saving API (i.e. the GimpSaveProcedure class) to take an array of drawables as argument instead of a single drawable. It actually doesn't matter much for exporting as the whole API seems more or less bogus there and all formats plug-ins mostly care only whether they will merge/flatten all visible layers (the selected ones don't really matter) or if the format supports layers of some sort. It may be worth later strengthening a bit this whole logics, and maybe allow partial exports for instance. As for saving, it was not even looking at the passed GimpDrawable either and was simply re-querying the active layer anyway. Note that I don't implement the multi-selection saving in XCF yet in this commit. I only updated the API. The reason is that the current commit won't be backportable to gimp-2-10 because it is an API break. On the other hand, the code to save multi-selection can still be backported even though the save() API will only pass a single drawable (as I said anyway, this argument was mostly bogus until now, hence it doesn't matter much for 2.10 logics).
2020-04-14 17:46:17 +08:00
0, G_MAXINT, 1,
G_PARAM_READWRITE);
GIMP_PROC_ARG_OBJECT_ARRAY (procedure, "drawables",
"Drawables",
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
"The drawables to export",
app: support saving/exporting with multi-selection. This commit just changes our saving API (i.e. the GimpSaveProcedure class) to take an array of drawables as argument instead of a single drawable. It actually doesn't matter much for exporting as the whole API seems more or less bogus there and all formats plug-ins mostly care only whether they will merge/flatten all visible layers (the selected ones don't really matter) or if the format supports layers of some sort. It may be worth later strengthening a bit this whole logics, and maybe allow partial exports for instance. As for saving, it was not even looking at the passed GimpDrawable either and was simply re-querying the active layer anyway. Note that I don't implement the multi-selection saving in XCF yet in this commit. I only updated the API. The reason is that the current commit won't be backportable to gimp-2-10 because it is an API break. On the other hand, the code to save multi-selection can still be backported even though the save() API will only pass a single drawable (as I said anyway, this argument was mostly bogus until now, hence it doesn't matter much for 2.10 logics).
2020-04-14 17:46:17 +08:00
GIMP_TYPE_DRAWABLE,
G_PARAM_READWRITE | GIMP_PARAM_NO_VALIDATE);
libgimp, plug-ins: use the new macros everwhere Except for gimp_param_spec_string() which is on its way back to the core.
2019-08-19 16:02:07 +08:00
pdb, app, libgimp, plug-ins: replace most PDB filenames/URIs by GFile and in an attack of madness, changes almost all file plug-in code to use GFile instead of filenames, which means passing the GFile down to the bottom and get its filename at the very end where it's actually needed.
2019-09-12 03:48:34 +08:00
GIMP_PROC_ARG_FILE (procedure, "file",
"File",
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
"The file to export to",
pdb, app, libgimp, plug-ins: replace most PDB filenames/URIs by GFile and in an attack of madness, changes almost all file plug-in code to use GFile instead of filenames, which means passing the GFile down to the bottom and get its filename at the very end where it's actually needed.
2019-09-12 03:48:34 +08:00
GIMP_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
if (procedure->priv->run_data_destroy)
procedure->priv->run_data_destroy (procedure->priv->run_data);
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)
{
case PROP_SUPPORTS_EXIF:
procedure->priv->supports_exif = g_value_get_boolean (value);
break;
case PROP_SUPPORTS_IPTC:
procedure->priv->supports_iptc = g_value_get_boolean (value);
break;
case PROP_SUPPORTS_XMP:
procedure->priv->supports_xmp = g_value_get_boolean (value);
break;
case PROP_SUPPORTS_PROFILE:
procedure->priv->supports_profile = g_value_get_boolean (value);
break;
case PROP_SUPPORTS_THUMBNAIL:
procedure->priv->supports_thumbnail = g_value_get_boolean (value);
break;
case PROP_SUPPORTS_COMMENT:
procedure->priv->supports_comment = g_value_get_boolean (value);
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)
{
case PROP_SUPPORTS_EXIF:
g_value_set_boolean (value, procedure->priv->supports_exif);
break;
case PROP_SUPPORTS_IPTC:
g_value_set_boolean (value, procedure->priv->supports_iptc);
break;
case PROP_SUPPORTS_XMP:
g_value_set_boolean (value, procedure->priv->supports_xmp);
break;
case PROP_SUPPORTS_PROFILE:
g_value_set_boolean (value, procedure->priv->supports_profile);
break;
case PROP_SUPPORTS_THUMBNAIL:
g_value_set_boolean (value, procedure->priv->supports_thumbnail);
break;
case PROP_SUPPORTS_COMMENT:
g_value_set_boolean (value, procedure->priv->supports_comment);
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
}
libgimp: change ARG_OFFSET define in GimpSaveProcedure from 4 to 5 the procedure's signature changed which broke marshalling of additional arguments and creation of GimpProcedureConfig object.
2020-05-29 04:34:41 +08:00
#define ARG_OFFSET 5
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;
GimpDrawable **drawables;
GFile *file;
gint n_drawables;
GimpMetadata *metadata;
gchar *mimetype = NULL;
GimpPDBStatusType status = GIMP_PDB_EXECUTION_ERROR;
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
app: support saving/exporting with multi-selection. This commit just changes our saving API (i.e. the GimpSaveProcedure class) to take an array of drawables as argument instead of a single drawable. It actually doesn't matter much for exporting as the whole API seems more or less bogus there and all formats plug-ins mostly care only whether they will merge/flatten all visible layers (the selected ones don't really matter) or if the format supports layers of some sort. It may be worth later strengthening a bit this whole logics, and maybe allow partial exports for instance. As for saving, it was not even looking at the passed GimpDrawable either and was simply re-querying the active layer anyway. Note that I don't implement the multi-selection saving in XCF yet in this commit. I only updated the API. The reason is that the current commit won't be backportable to gimp-2-10 because it is an API break. On the other hand, the code to save multi-selection can still be backported even though the save() API will only pass a single drawable (as I said anyway, this argument was mostly bogus until now, hence it doesn't matter much for 2.10 logics).
2020-04-14 17:46:17 +08:00
run_mode = GIMP_VALUES_GET_ENUM (args, 0);
image = GIMP_VALUES_GET_IMAGE (args, 1);
n_drawables = GIMP_VALUES_GET_INT (args, 2);
drawables = GIMP_VALUES_GET_OBJECT_ARRAY (args, 3);
file = GIMP_VALUES_GET_FILE (args, 4);
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, 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
config = gimp_procedure_create_config (procedure);
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 (export_proc->priv->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);
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
return_values = export_proc->priv->run_func (procedure, run_mode,
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
image, n_drawables, drawables,
file, metadata, config,
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
export_proc->priv->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);
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);
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: 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 (export_procedure->priv->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
GIMP_PROC_AUX_ARG_BOOLEAN (procedure, "save-exif",
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
_("Save _Exif"),
_("Save Exif (Exchangeable image file format) 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
gimp_export_exif (),
G_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
if (export_procedure->priv->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
GIMP_PROC_AUX_ARG_BOOLEAN (procedure, "save-iptc",
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
_("Save _IPTC"),
_("Save IPTC (International Press Telecommunications Council) 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
gimp_export_iptc (),
G_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
if (export_procedure->priv->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
GIMP_PROC_AUX_ARG_BOOLEAN (procedure, "save-xmp",
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
_("Save _XMP"),
_("Save XMP (Extensible Metadata Platform) 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
gimp_export_xmp (),
G_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
if (export_procedure->priv->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
GIMP_PROC_AUX_ARG_BOOLEAN (procedure, "save-color-profile",
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
_("Save color _profile"),
_("Save the ICC color profile as 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
gimp_export_color_profile (),
G_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
if (export_procedure->priv->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
GIMP_PROC_AUX_ARG_BOOLEAN (procedure, "save-thumbnail",
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
_("Save _thumbnail"),
_("Save a smaller representation of the image as metadata"),
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
gimp_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
G_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
if (export_procedure->priv->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
{
GIMP_PROC_AUX_ARG_BOOLEAN (procedure, "save-comment",
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
_("Save c_omment"),
_("Save a comment as 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
gimp_export_comment (),
G_PARAM_READWRITE);
GIMP_PROC_AUX_ARG_STRING (procedure, "gimp-comment",
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
_("Comment"),
_("Image 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
gimp_get_default_comment (),
G_PARAM_READWRITE);
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
}
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
*
libgimp: doc fixes and improvements in procedure subclasses
2019-10-30 05:15:58 +08:00
* (#GimpRunMode, #GimpImage, #GimpDrawable, #GFile)
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);
procedure->priv->run_func = run_func;
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
procedure->priv->export_metadata = 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
procedure->priv->run_data = run_data;
procedure->priv->run_data_destroy = run_data_destroy;
return GIMP_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: 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
return procedure->priv->supports_exif;
}
/**
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
return procedure->priv->supports_iptc;
}
/**
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
return procedure->priv->supports_xmp;
}
/**
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
return procedure->priv->supports_profile;
}
/**
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
return procedure->priv->supports_thumbnail;
}
/**
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
return procedure->priv->supports_comment;
}