2001-05-21 17:17:20 +00:00
|
|
|
EXPORTS
|
2005-01-22 23:38:36 +00:00
|
|
|
gimp_add_mask_type_get_type
|
2003-10-16 16:58:57 +00:00
|
|
|
gimp_any_to_utf8
|
2019-07-26 15:54:33 +02:00
|
|
|
gimp_array_copy
|
|
|
|
|
gimp_array_free
|
|
|
|
|
gimp_array_get_type
|
|
|
|
|
gimp_array_new
|
2017-10-29 18:37:18 +01:00
|
|
|
gimp_base_compat_enums_init
|
Issue #8900 and #9923: reimplementing GimpUnit as a proper class.
This fixes all our GObject Introspection issues with GimpUnit which was
both an enum and an int-derived type of user-defined units *completing*
the enum values. GIR clearly didn't like this!
Now GimpUnit is a proper class and units are unique objects, allowing to
compare them with an identity test (i.e. `unit == gimp_unit_pixel ()`
tells us if unit is the pixel unit or not), which makes it easy to use,
just like with int, yet adding also methods, making for nicer
introspected API.
As an aside, this also fixes #10738, by having all the built-in units
retrievable even if libgimpbase had not been properly initialized with
gimp_base_init().
I haven't checked in details how GIR works to introspect, but it looks
like it loads the library to inspect and runs functions, hence
triggering some CRITICALS because virtual methods (supposed to be
initialized with gimp_base_init() run by libgimp) are not set. This new
code won't trigger any critical because the vtable method are now not
necessary, at least for all built-in units.
Note that GimpUnit is still in libgimpbase. It could have been moved to
libgimp in order to avoid any virtual method table (since we need to
keep core and libgimp side's units in sync, PDB is required), but too
many libgimpwidgets widgets were already using GimpUnit. And technically
most of GimpUnit logic doesn't require PDB (only the creation/sync
part). This is one of the reasons why user-created GimpUnit list is
handled and stored differently from other types of objects.
Globally this simplifies the code a lot too and we don't need separate
implementations of various utils for core and libgimp, which means less
prone to errors.
2024-07-25 20:55:21 +02:00
|
|
|
gimp_base_exit
|
2003-11-15 22:56:11 +00:00
|
|
|
gimp_base_init
|
2023-01-11 15:21:32 +01:00
|
|
|
gimp_bind_text_domain
|
2014-05-13 00:27:29 +02:00
|
|
|
gimp_brush_generated_shape_get_type
|
2018-11-18 18:10:34 +01:00
|
|
|
gimp_cache_directory
|
2005-08-02 22:52:23 +00:00
|
|
|
gimp_canonicalize_identifier
|
2015-11-09 02:16:03 +01:00
|
|
|
gimp_cap_style_get_type
|
2005-01-22 23:38:36 +00:00
|
|
|
gimp_channel_ops_get_type
|
|
|
|
|
gimp_channel_type_get_type
|
2004-09-02 19:54:11 +00:00
|
|
|
gimp_check_size_get_type
|
|
|
|
|
gimp_check_type_get_type
|
2022-05-13 12:09:17 +02:00
|
|
|
gimp_checks_get_colors
|
2023-08-03 00:20:10 +02:00
|
|
|
gimp_choice_add
|
|
|
|
|
gimp_choice_get_documentation
|
|
|
|
|
gimp_choice_get_help
|
|
|
|
|
gimp_choice_get_id
|
|
|
|
|
gimp_choice_get_label
|
|
|
|
|
gimp_choice_get_type
|
|
|
|
|
gimp_choice_is_valid
|
|
|
|
|
gimp_choice_list_nicks
|
|
|
|
|
gimp_choice_new
|
|
|
|
|
gimp_choice_new_with_values
|
2023-08-04 01:16:16 +02:00
|
|
|
gimp_choice_set_sensitive
|
2005-01-23 00:00:20 +00:00
|
|
|
gimp_clone_type_get_type
|
2023-12-27 01:07:19 +09:00
|
|
|
gimp_color_array_copy
|
|
|
|
|
gimp_color_array_free
|
|
|
|
|
gimp_color_array_get_length
|
|
|
|
|
gimp_color_array_get_type
|
2016-10-29 16:50:13 +02:00
|
|
|
gimp_color_tag_get_type
|
2014-05-13 00:27:29 +02:00
|
|
|
gimp_component_type_get_type
|
2014-05-14 00:06:01 +02:00
|
|
|
gimp_convert_palette_type_get_type
|
2014-04-29 22:44:58 +02:00
|
|
|
gimp_convolve_type_get_type
|
2024-10-21 23:57:10 +02:00
|
|
|
gimp_core_object_array_get_length
|
2024-10-21 21:59:26 +02:00
|
|
|
gimp_core_object_array_get_type
|
2006-06-02 10:00:19 +00:00
|
|
|
gimp_cpu_accel_get_support
|
|
|
|
|
gimp_cpu_accel_set_use
|
2001-05-21 17:17:20 +00:00
|
|
|
gimp_data_directory
|
2014-07-28 02:04:01 +02:00
|
|
|
gimp_data_directory_file
|
2005-04-16 20:20:54 +00:00
|
|
|
gimp_desaturate_mode_get_type
|
2001-05-21 17:17:20 +00:00
|
|
|
gimp_directory
|
2014-07-28 02:04:01 +02:00
|
|
|
gimp_directory_file
|
2005-01-23 00:00:20 +00:00
|
|
|
gimp_dodge_burn_type_get_type
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 14:03:37 +01:00
|
|
|
gimp_double_array_get_type
|
|
|
|
|
gimp_double_array_get_values
|
|
|
|
|
gimp_double_array_set_values
|
2004-10-25 22:50:27 +00:00
|
|
|
gimp_enum_get_desc
|
2004-07-29 13:40:56 +00:00
|
|
|
gimp_enum_get_value
|
2004-10-25 22:50:27 +00:00
|
|
|
gimp_enum_get_value_descriptions
|
|
|
|
|
gimp_enum_set_value_descriptions
|
2017-12-01 05:25:50 -05:00
|
|
|
gimp_enum_value_get_abbrev
|
2004-10-25 22:50:27 +00:00
|
|
|
gimp_enum_value_get_desc
|
|
|
|
|
gimp_enum_value_get_help
|
2005-11-06 01:06:41 +00:00
|
|
|
gimp_env_init
|
2004-05-10 23:17:29 +00:00
|
|
|
gimp_escape_uline
|
2024-11-01 19:13:02 +01:00
|
|
|
gimp_export_capabilities_get_type
|
2024-05-06 18:38:12 +00:00
|
|
|
gimp_export_options_get_type
|
2025-01-22 17:15:28 +01:00
|
|
|
gimp_file_chooser_action_get_type
|
2014-07-01 13:18:14 +02:00
|
|
|
gimp_file_get_utf8_name
|
2014-08-03 20:46:28 +02:00
|
|
|
gimp_file_has_extension
|
2015-02-16 18:40:26 +01:00
|
|
|
gimp_file_show_in_file_manager
|
2004-01-19 01:08:43 +00:00
|
|
|
gimp_filename_to_utf8
|
2014-05-13 00:27:29 +02:00
|
|
|
gimp_fill_type_get_type
|
2004-10-25 22:50:27 +00:00
|
|
|
gimp_flags_get_first_desc
|
2004-11-10 12:44:13 +00:00
|
|
|
gimp_flags_get_first_value
|
2004-10-25 22:50:27 +00:00
|
|
|
gimp_flags_get_value_descriptions
|
|
|
|
|
gimp_flags_set_value_descriptions
|
2017-12-01 05:25:50 -05:00
|
|
|
gimp_flags_value_get_abbrev
|
2004-10-25 22:50:27 +00:00
|
|
|
gimp_flags_value_get_desc
|
|
|
|
|
gimp_flags_value_get_help
|
2005-07-30 15:24:15 +00:00
|
|
|
gimp_foreground_extract_mode_get_type
|
2018-04-13 22:33:16 +02:00
|
|
|
gimp_gradient_blend_color_space_get_type
|
2014-05-13 00:27:29 +02:00
|
|
|
gimp_gradient_segment_color_get_type
|
|
|
|
|
gimp_gradient_segment_type_get_type
|
2005-01-22 23:38:36 +00:00
|
|
|
gimp_gradient_type_get_type
|
2005-09-30 16:35:04 +00:00
|
|
|
gimp_grid_style_get_type
|
2014-05-14 00:06:01 +02:00
|
|
|
gimp_hue_range_get_type
|
2005-01-22 23:38:36 +00:00
|
|
|
gimp_icon_type_get_type
|
2004-07-29 13:40:56 +00:00
|
|
|
gimp_image_base_type_get_type
|
|
|
|
|
gimp_image_type_get_type
|
2014-05-01 10:39:23 +02:00
|
|
|
gimp_ink_blob_type_get_type
|
2012-05-23 11:49:07 +02:00
|
|
|
gimp_installation_directory
|
2019-02-03 14:50:48 +01:00
|
|
|
gimp_installation_directory_file
|
2019-07-26 15:54:33 +02:00
|
|
|
gimp_int32_array_get_type
|
2024-10-24 17:43:09 +02:00
|
|
|
gimp_int32_array_get_values
|
|
|
|
|
gimp_int32_array_set_values
|
2005-01-22 23:06:37 +00:00
|
|
|
gimp_interpolation_type_get_type
|
2019-08-05 23:22:06 +02:00
|
|
|
gimp_is_canonical_identifier
|
2015-11-09 02:16:03 +01:00
|
|
|
gimp_join_style_get_type
|
2003-02-19 22:30:01 +00:00
|
|
|
gimp_locale_directory
|
2014-07-28 02:04:01 +02:00
|
|
|
gimp_locale_directory_file
|
2006-11-30 08:26:47 +00:00
|
|
|
gimp_major_version
|
2014-05-13 00:27:29 +02:00
|
|
|
gimp_mask_apply_mode_get_type
|
2004-07-27 16:39:00 +00:00
|
|
|
gimp_memsize_deserialize
|
|
|
|
|
gimp_memsize_get_type
|
|
|
|
|
gimp_memsize_serialize
|
2014-05-13 00:27:29 +02:00
|
|
|
gimp_merge_type_get_type
|
2004-10-25 22:50:27 +00:00
|
|
|
gimp_message_handler_type_get_type
|
2017-07-08 00:10:50 +02:00
|
|
|
gimp_metadata_add_xmp_history
|
2013-10-19 18:38:01 +02:00
|
|
|
gimp_metadata_deserialize
|
|
|
|
|
gimp_metadata_duplicate
|
2015-09-30 20:47:52 +02:00
|
|
|
gimp_metadata_get_colorspace
|
2017-07-08 00:10:50 +02:00
|
|
|
gimp_metadata_get_guid
|
2013-10-19 18:38:01 +02:00
|
|
|
gimp_metadata_get_resolution
|
2017-01-30 18:53:20 +01:00
|
|
|
gimp_metadata_get_type
|
2013-10-19 18:38:01 +02:00
|
|
|
gimp_metadata_is_tag_supported
|
|
|
|
|
gimp_metadata_load_from_file
|
|
|
|
|
gimp_metadata_new
|
2017-01-03 19:36:22 +01:00
|
|
|
gimp_metadata_save_to_file
|
2013-10-19 18:38:01 +02:00
|
|
|
gimp_metadata_serialize
|
|
|
|
|
gimp_metadata_set_bits_per_sample
|
2015-09-30 20:47:52 +02:00
|
|
|
gimp_metadata_set_colorspace
|
2025-01-13 16:15:27 -05:00
|
|
|
gimp_metadata_set_creation_date
|
2013-10-19 18:38:01 +02:00
|
|
|
gimp_metadata_set_from_exif
|
2017-07-08 00:10:50 +02:00
|
|
|
gimp_metadata_set_from_iptc
|
2013-10-19 18:38:01 +02:00
|
|
|
gimp_metadata_set_from_xmp
|
|
|
|
|
gimp_metadata_set_pixel_size
|
|
|
|
|
gimp_metadata_set_resolution
|
2006-11-30 08:26:47 +00:00
|
|
|
gimp_micro_version
|
|
|
|
|
gimp_minor_version
|
2014-05-13 00:27:29 +02:00
|
|
|
gimp_offset_type_get_type
|
|
|
|
|
gimp_orientation_type_get_type
|
2005-01-23 00:00:20 +00:00
|
|
|
gimp_paint_application_mode_get_type
|
2019-07-26 15:54:33 +02:00
|
|
|
gimp_param_array_get_type
|
2023-08-02 23:55:33 +02:00
|
|
|
gimp_param_choice_get_type
|
2024-10-21 21:59:26 +02:00
|
|
|
gimp_param_core_object_array_get_type
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 14:03:37 +01:00
|
|
|
gimp_param_double_array_get_type
|
2024-05-06 18:38:12 +00:00
|
|
|
gimp_param_export_options_get_type
|
2025-01-22 17:15:28 +01:00
|
|
|
gimp_param_file_get_type
|
2019-07-26 15:54:33 +02:00
|
|
|
gimp_param_int32_array_get_type
|
2005-01-22 01:14:31 +00:00
|
|
|
gimp_param_memsize_get_type
|
app, libgimp*, pdb: new GimpParamSpecObject abstract spec type.
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
2024-09-02 23:38:13 +02:00
|
|
|
gimp_param_object_get_type
|
2006-04-02 09:39:46 +00:00
|
|
|
gimp_param_parasite_get_type
|
2019-07-26 15:54:33 +02:00
|
|
|
gimp_param_spec_array
|
2023-08-02 23:55:33 +02:00
|
|
|
gimp_param_spec_choice
|
2024-10-21 21:59:26 +02:00
|
|
|
gimp_param_spec_core_object_array
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 14:03:37 +01:00
|
|
|
gimp_param_spec_double_array
|
2024-05-06 18:38:12 +00:00
|
|
|
gimp_param_spec_export_options
|
2025-01-22 17:15:28 +01:00
|
|
|
gimp_param_spec_file
|
2025-01-24 23:42:20 +01:00
|
|
|
gimp_param_spec_file_get_action
|
|
|
|
|
gimp_param_spec_file_none_allowed
|
2019-07-26 15:54:33 +02:00
|
|
|
gimp_param_spec_int32_array
|
2005-01-22 23:06:37 +00:00
|
|
|
gimp_param_spec_memsize
|
app, libgimp*, pdb: new GimpParamSpecObject abstract spec type.
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
2024-09-02 23:38:13 +02:00
|
|
|
gimp_param_spec_object_duplicate
|
|
|
|
|
gimp_param_spec_object_get_default
|
|
|
|
|
gimp_param_spec_object_has_default
|
|
|
|
|
gimp_param_spec_object_set_default
|
2006-04-02 09:39:46 +00:00
|
|
|
gimp_param_spec_parasite
|
2005-01-22 01:14:31 +00:00
|
|
|
gimp_param_spec_unit
|
2025-01-24 23:42:20 +01:00
|
|
|
gimp_param_spec_unit_percent_allowed
|
|
|
|
|
gimp_param_spec_unit_pixel_allowed
|
2012-05-04 00:26:26 +02:00
|
|
|
gimp_param_spec_value_array
|
2005-01-22 23:06:37 +00:00
|
|
|
gimp_param_unit_get_type
|
2012-05-04 00:26:26 +02:00
|
|
|
gimp_param_value_array_get_type
|
2001-05-25 22:04:21 +00:00
|
|
|
gimp_parasite_compare
|
|
|
|
|
gimp_parasite_copy
|
|
|
|
|
gimp_parasite_free
|
2021-01-07 23:14:26 +01:00
|
|
|
gimp_parasite_get_data
|
2021-04-05 18:36:44 +02:00
|
|
|
gimp_parasite_get_flags
|
|
|
|
|
gimp_parasite_get_name
|
2006-04-02 09:39:46 +00:00
|
|
|
gimp_parasite_get_type
|
2001-05-25 22:04:21 +00:00
|
|
|
gimp_parasite_has_flag
|
|
|
|
|
gimp_parasite_is_persistent
|
|
|
|
|
gimp_parasite_is_type
|
|
|
|
|
gimp_parasite_is_undoable
|
|
|
|
|
gimp_parasite_new
|
2001-05-21 17:17:20 +00:00
|
|
|
gimp_path_free
|
2001-05-25 22:04:21 +00:00
|
|
|
gimp_path_get_user_writable_dir
|
2005-01-29 19:11:17 +00:00
|
|
|
gimp_path_parse
|
2024-07-19 15:07:43 +00:00
|
|
|
gimp_path_stroke_type_get_type
|
2001-05-25 22:04:21 +00:00
|
|
|
gimp_path_to_str
|
2008-08-19 06:33:48 +00:00
|
|
|
gimp_pdb_error_handler_get_type
|
2004-10-25 22:50:27 +00:00
|
|
|
gimp_pdb_proc_type_get_type
|
|
|
|
|
gimp_pdb_status_type_get_type
|
2010-02-21 16:45:01 +01:00
|
|
|
gimp_pixels_to_units
|
2001-05-25 22:04:21 +00:00
|
|
|
gimp_pixpipe_params_build
|
2018-06-28 01:36:40 +02:00
|
|
|
gimp_pixpipe_params_free
|
2001-05-25 22:04:21 +00:00
|
|
|
gimp_pixpipe_params_init
|
|
|
|
|
gimp_pixpipe_params_parse
|
2002-02-17 15:55:54 +00:00
|
|
|
gimp_plug_in_directory
|
2014-07-28 02:04:01 +02:00
|
|
|
gimp_plug_in_directory_file
|
2014-05-13 00:27:29 +02:00
|
|
|
gimp_precision_get_type
|
2021-04-04 02:50:48 +02:00
|
|
|
gimp_procedure_sensitivity_mask_get_type
|
2004-10-25 22:50:27 +00:00
|
|
|
gimp_progress_command_get_type
|
2020-11-25 01:16:34 +01:00
|
|
|
gimp_range_estimate_settings
|
2006-08-29 14:46:32 +00:00
|
|
|
gimp_rectangle_intersect
|
2009-08-23 22:58:36 +02:00
|
|
|
gimp_rectangle_union
|
2005-01-22 23:38:36 +00:00
|
|
|
gimp_repeat_mode_get_type
|
2014-05-13 00:27:29 +02:00
|
|
|
gimp_rotation_type_get_type
|
2006-04-06 10:16:39 +00:00
|
|
|
gimp_run_mode_get_type
|
2014-05-13 00:27:29 +02:00
|
|
|
gimp_select_criterion_get_type
|
2002-03-29 23:10:18 +00:00
|
|
|
gimp_signal_private
|
2005-01-23 00:58:22 +00:00
|
|
|
gimp_size_type_get_type
|
2018-02-22 12:35:43 +01:00
|
|
|
gimp_stack_trace_available
|
2004-10-25 22:50:27 +00:00
|
|
|
gimp_stack_trace_mode_get_type
|
2018-02-22 12:35:43 +01:00
|
|
|
gimp_stack_trace_print
|
|
|
|
|
gimp_stack_trace_query
|
2003-08-13 01:36:11 +00:00
|
|
|
gimp_strip_uline
|
2015-11-09 02:16:03 +01:00
|
|
|
gimp_stroke_method_get_type
|
2001-05-25 22:04:21 +00:00
|
|
|
gimp_sysconf_directory
|
2014-07-28 02:04:01 +02:00
|
|
|
gimp_sysconf_directory_file
|
2018-11-18 18:10:34 +01:00
|
|
|
gimp_temp_directory
|
2008-03-31 21:48:07 +00:00
|
|
|
gimp_text_direction_get_type
|
2008-10-29 22:31:25 +00:00
|
|
|
gimp_text_hint_style_get_type
|
2013-10-19 18:38:01 +02:00
|
|
|
gimp_text_justification_get_type
|
2005-01-22 23:06:37 +00:00
|
|
|
gimp_transfer_mode_get_type
|
2005-01-22 23:38:36 +00:00
|
|
|
gimp_transform_direction_get_type
|
2006-12-24 16:48:08 +00:00
|
|
|
gimp_transform_resize_get_type
|
2008-11-06 08:28:28 +00:00
|
|
|
gimp_type_get_translation_context
|
2004-07-29 13:40:56 +00:00
|
|
|
gimp_type_get_translation_domain
|
2008-11-12 14:52:25 +00:00
|
|
|
gimp_type_set_translation_context
|
2004-07-29 13:40:56 +00:00
|
|
|
gimp_type_set_translation_domain
|
2010-10-31 22:10:31 +01:00
|
|
|
gimp_unit_format_string
|
2003-11-15 22:56:11 +00:00
|
|
|
gimp_unit_get_abbreviation
|
Issue #8900 and #9923: reimplementing GimpUnit as a proper class.
This fixes all our GObject Introspection issues with GimpUnit which was
both an enum and an int-derived type of user-defined units *completing*
the enum values. GIR clearly didn't like this!
Now GimpUnit is a proper class and units are unique objects, allowing to
compare them with an identity test (i.e. `unit == gimp_unit_pixel ()`
tells us if unit is the pixel unit or not), which makes it easy to use,
just like with int, yet adding also methods, making for nicer
introspected API.
As an aside, this also fixes #10738, by having all the built-in units
retrievable even if libgimpbase had not been properly initialized with
gimp_base_init().
I haven't checked in details how GIR works to introspect, but it looks
like it loads the library to inspect and runs functions, hence
triggering some CRITICALS because virtual methods (supposed to be
initialized with gimp_base_init() run by libgimp) are not set. This new
code won't trigger any critical because the vtable method are now not
necessary, at least for all built-in units.
Note that GimpUnit is still in libgimpbase. It could have been moved to
libgimp in order to avoid any virtual method table (since we need to
keep core and libgimp side's units in sync, PDB is required), but too
many libgimpwidgets widgets were already using GimpUnit. And technically
most of GimpUnit logic doesn't require PDB (only the creation/sync
part). This is one of the reasons why user-created GimpUnit list is
handled and stored differently from other types of objects.
Globally this simplifies the code a lot too and we don't need separate
implementations of various utils for core and libgimp, which means less
prone to errors.
2024-07-25 20:55:21 +02:00
|
|
|
gimp_unit_get_by_id
|
2003-11-15 22:56:11 +00:00
|
|
|
gimp_unit_get_deletion_flag
|
|
|
|
|
gimp_unit_get_digits
|
|
|
|
|
gimp_unit_get_factor
|
Issue #8900 and #9923: reimplementing GimpUnit as a proper class.
This fixes all our GObject Introspection issues with GimpUnit which was
both an enum and an int-derived type of user-defined units *completing*
the enum values. GIR clearly didn't like this!
Now GimpUnit is a proper class and units are unique objects, allowing to
compare them with an identity test (i.e. `unit == gimp_unit_pixel ()`
tells us if unit is the pixel unit or not), which makes it easy to use,
just like with int, yet adding also methods, making for nicer
introspected API.
As an aside, this also fixes #10738, by having all the built-in units
retrievable even if libgimpbase had not been properly initialized with
gimp_base_init().
I haven't checked in details how GIR works to introspect, but it looks
like it loads the library to inspect and runs functions, hence
triggering some CRITICALS because virtual methods (supposed to be
initialized with gimp_base_init() run by libgimp) are not set. This new
code won't trigger any critical because the vtable method are now not
necessary, at least for all built-in units.
Note that GimpUnit is still in libgimpbase. It could have been moved to
libgimp in order to avoid any virtual method table (since we need to
keep core and libgimp side's units in sync, PDB is required), but too
many libgimpwidgets widgets were already using GimpUnit. And technically
most of GimpUnit logic doesn't require PDB (only the creation/sync
part). This is one of the reasons why user-created GimpUnit list is
handled and stored differently from other types of objects.
Globally this simplifies the code a lot too and we don't need separate
implementations of various utils for core and libgimp, which means less
prone to errors.
2024-07-25 20:55:21 +02:00
|
|
|
gimp_unit_get_id
|
Issue #434: remove broken plural support for GimpUnit.
Rather than trying to implement full i18n plural support, we just remove
this failed attempt from the past. The fact is that to get proper
support, we'd basically need to reimplement a Gettext-like plural
definition syntax within our API, then ask people to write down this
plural definition for their language, then to write every plural form…
all this for custom units which only them will ever see!
Moreover code investigation shows that the singular form was simply
never used, and the plural form was always used (whatever the actual
unit value displayed).
As for the "identifier", this was a text which was never shown anywhere
(except in the unit editor) and for all built-in units, as well as
default unitrc units, it was equivalent to the English plural value.
So we now just have a unique name which is the "long label" to be used
everywhere in the GUI, and abbreviation will be basically the "short
label". That's it. No useless (or worse, not actually usable because it
was not generic internationalization) values anymore!
2024-08-05 16:02:47 +02:00
|
|
|
gimp_unit_get_name
|
2017-01-20 01:10:06 +01:00
|
|
|
gimp_unit_get_scaled_digits
|
2003-11-15 22:56:11 +00:00
|
|
|
gimp_unit_get_symbol
|
2004-07-27 16:39:00 +00:00
|
|
|
gimp_unit_get_type
|
Issue #8900 and #9923: reimplementing GimpUnit as a proper class.
This fixes all our GObject Introspection issues with GimpUnit which was
both an enum and an int-derived type of user-defined units *completing*
the enum values. GIR clearly didn't like this!
Now GimpUnit is a proper class and units are unique objects, allowing to
compare them with an identity test (i.e. `unit == gimp_unit_pixel ()`
tells us if unit is the pixel unit or not), which makes it easy to use,
just like with int, yet adding also methods, making for nicer
introspected API.
As an aside, this also fixes #10738, by having all the built-in units
retrievable even if libgimpbase had not been properly initialized with
gimp_base_init().
I haven't checked in details how GIR works to introspect, but it looks
like it loads the library to inspect and runs functions, hence
triggering some CRITICALS because virtual methods (supposed to be
initialized with gimp_base_init() run by libgimp) are not set. This new
code won't trigger any critical because the vtable method are now not
necessary, at least for all built-in units.
Note that GimpUnit is still in libgimpbase. It could have been moved to
libgimp in order to avoid any virtual method table (since we need to
keep core and libgimp side's units in sync, PDB is required), but too
many libgimpwidgets widgets were already using GimpUnit. And technically
most of GimpUnit logic doesn't require PDB (only the creation/sync
part). This is one of the reasons why user-created GimpUnit list is
handled and stored differently from other types of objects.
Globally this simplifies the code a lot too and we don't need separate
implementations of various utils for core and libgimp, which means less
prone to errors.
2024-07-25 20:55:21 +02:00
|
|
|
gimp_unit_inch
|
|
|
|
|
gimp_unit_is_built_in
|
2013-10-12 18:54:34 +02:00
|
|
|
gimp_unit_is_metric
|
Issue #8900 and #9923: reimplementing GimpUnit as a proper class.
This fixes all our GObject Introspection issues with GimpUnit which was
both an enum and an int-derived type of user-defined units *completing*
the enum values. GIR clearly didn't like this!
Now GimpUnit is a proper class and units are unique objects, allowing to
compare them with an identity test (i.e. `unit == gimp_unit_pixel ()`
tells us if unit is the pixel unit or not), which makes it easy to use,
just like with int, yet adding also methods, making for nicer
introspected API.
As an aside, this also fixes #10738, by having all the built-in units
retrievable even if libgimpbase had not been properly initialized with
gimp_base_init().
I haven't checked in details how GIR works to introspect, but it looks
like it loads the library to inspect and runs functions, hence
triggering some CRITICALS because virtual methods (supposed to be
initialized with gimp_base_init() run by libgimp) are not set. This new
code won't trigger any critical because the vtable method are now not
necessary, at least for all built-in units.
Note that GimpUnit is still in libgimpbase. It could have been moved to
libgimp in order to avoid any virtual method table (since we need to
keep core and libgimp side's units in sync, PDB is required), but too
many libgimpwidgets widgets were already using GimpUnit. And technically
most of GimpUnit logic doesn't require PDB (only the creation/sync
part). This is one of the reasons why user-created GimpUnit list is
handled and stored differently from other types of objects.
Globally this simplifies the code a lot too and we don't need separate
implementations of various utils for core and libgimp, which means less
prone to errors.
2024-07-25 20:55:21 +02:00
|
|
|
gimp_unit_mm
|
|
|
|
|
gimp_unit_percent
|
|
|
|
|
gimp_unit_pica
|
|
|
|
|
gimp_unit_pixel
|
|
|
|
|
gimp_unit_point
|
2003-11-15 22:56:11 +00:00
|
|
|
gimp_unit_set_deletion_flag
|
2010-02-21 16:45:01 +01:00
|
|
|
gimp_units_to_pixels
|
2011-03-18 21:34:27 +01:00
|
|
|
gimp_units_to_points
|
2003-02-19 22:30:01 +00:00
|
|
|
gimp_utf8_strtrim
|
2012-05-03 23:24:09 +02:00
|
|
|
gimp_value_array_append
|
2023-05-21 01:09:57 +02:00
|
|
|
gimp_value_array_copy
|
2024-02-28 22:13:57 +01:00
|
|
|
gimp_value_array_get_color_array
|
libgimp, libgimpbase: create special functions to get/set boxed array properties.
While the work on NULL-terminated array types make it much easier in C,
bindings don't have enough information to create native array/list types
in some generic functions such as g_object_get|set(), or else we just
don't know the right annotations to use for this to be possible. This is
report gobject-introspection#492.
So for the time being, we are creating dedicated functions for GeglColor
arrays and for other core object arrays (arrays of images, items, etc.).
E.g. in Python, while you can set a single GimpImage like this:
> config.set_property('image', image)
… you need to set a list of images like this:
> config.set_core_object_array('images', [image1, image2])
2024-10-28 19:18:22 +01:00
|
|
|
gimp_value_array_get_core_object_array
|
2012-05-03 23:24:09 +02:00
|
|
|
gimp_value_array_get_type
|
|
|
|
|
gimp_value_array_index
|
|
|
|
|
gimp_value_array_insert
|
|
|
|
|
gimp_value_array_length
|
|
|
|
|
gimp_value_array_new
|
2019-07-30 10:12:28 +02:00
|
|
|
gimp_value_array_new_from_types
|
|
|
|
|
gimp_value_array_new_from_types_valist
|
gimppdb: Allow more easy bindable API
Plug-ins that work from different bindings probably want to use their
own list-type to specify arguments, rather than working with a more
cumbersome `GimpValueArray`.
This new API should make it less verbose. For example:
```
args = Gimp.ValueArray.new(5)
args.insert(0, GObject.Value(Gimp.RunMode, Gimp.RunMode.NONINTERACTIVE))
args.insert(1, GObject.Value(Gimp.Image, image))
args.insert(2, GObject.Value(Gimp.Drawable, mask))
args.insert(3, GObject.Value(GObject.TYPE_INT, int(time.time())))
args.insert(4, GObject.Value(GObject.TYPE_DOUBLE, turbulence))
Gimp.get_pdb().run_procedure('plug-in-plasma', args)
```
becomes
```
Gimp.get_pdb().run_procedure('plug-in-plasma', [
GObject.Value(Gimp.RunMode, Gimp.RunMode.NONINTERACTIVE),
GObject.Value(Gimp.Image, image),
GObject.Value(Gimp.Drawable, mask),
GObject.Value(GObject.TYPE_INT, int(time.time())),
GObject.Value(GObject.TYPE_DOUBLE, turbulence),
])
```
2020-05-19 18:43:43 +02:00
|
|
|
gimp_value_array_new_from_values
|
2012-05-03 23:24:09 +02:00
|
|
|
gimp_value_array_prepend
|
|
|
|
|
gimp_value_array_ref
|
|
|
|
|
gimp_value_array_remove
|
|
|
|
|
gimp_value_array_truncate
|
|
|
|
|
gimp_value_array_unref
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 14:03:37 +01:00
|
|
|
gimp_value_dup_double_array
|
2019-07-26 15:54:33 +02:00
|
|
|
gimp_value_dup_int32_array
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 14:03:37 +01:00
|
|
|
gimp_value_get_double_array
|
2019-07-26 15:54:33 +02:00
|
|
|
gimp_value_get_int32_array
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 14:03:37 +01:00
|
|
|
gimp_value_set_double_array
|
2019-07-26 15:54:33 +02:00
|
|
|
gimp_value_set_int32_array
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 14:03:37 +01:00
|
|
|
gimp_value_set_static_double_array
|
2019-07-26 15:54:33 +02:00
|
|
|
gimp_value_set_static_int32_array
|
app, libgimp*, pdb, plug-ins: rename various public API name s/float/double/.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
2024-11-02 14:03:37 +01:00
|
|
|
gimp_value_take_double_array
|
2019-07-26 15:54:33 +02:00
|
|
|
gimp_value_take_int32_array
|
2005-12-13 14:11:56 +00:00
|
|
|
gimp_wire_clear_error
|
|
|
|
|
gimp_wire_destroy
|
|
|
|
|
gimp_wire_error
|
|
|
|
|
gimp_wire_flush
|
|
|
|
|
gimp_wire_read
|
|
|
|
|
gimp_wire_read_msg
|
|
|
|
|
gimp_wire_register
|
|
|
|
|
gimp_wire_set_flusher
|
|
|
|
|
gimp_wire_set_reader
|
|
|
|
|
gimp_wire_set_writer
|
|
|
|
|
gimp_wire_write
|
|
|
|
|
gimp_wire_write_msg
|
2001-05-21 17:17:20 +00:00
|
|
|
gp_config_write
|
|
|
|
|
gp_extension_ack_write
|
2002-02-17 15:55:54 +00:00
|
|
|
gp_has_init_write
|
2001-05-21 17:17:20 +00:00
|
|
|
gp_init
|
|
|
|
|
gp_proc_install_write
|
|
|
|
|
gp_proc_return_write
|
|
|
|
|
gp_proc_run_write
|
|
|
|
|
gp_proc_uninstall_write
|
|
|
|
|
gp_quit_write
|
|
|
|
|
gp_temp_proc_return_write
|
|
|
|
|
gp_temp_proc_run_write
|
|
|
|
|
gp_tile_ack_write
|
|
|
|
|
gp_tile_data_write
|
|
|
|
|
gp_tile_req_write
|