procyberian/gimp
2
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/gimp.git synced 2025-07-03 09:23:24 +00:00
Code Issues 1 Projects 1 Releases Packages Wiki Activity Actions
gimp/libgimp/meson.build

620 lines
15 KiB
Meson
Raw Normal View History

Issue #8145: meson: generation of '*-enums.c' files. Our meson build system was not properly building the enums.c file, because they are versionned. I did a similar trick as what I did for the pdbgen, which is that I used a wrapper script around the existing perl script, which sets proper options and generate a stamp file in the end (which is considered by meson as the actual custom target, not the C file since it is generated in the source dir). The most important part is that the stamp file is a generated header source (not just a random text file) which is **included** by the generated C file. This is what will force meson to regenerate the C file if the header is updated, **then** build using this new version, not use an outdated versionned version (which would make for hard to diagnose bugs), through the indirection of the intermediate stamp header. See #4201. See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
2022-08-01 19:08:35 +02:00
# Similarly to libgimpthumb/gimpthumb-enums.c, libgimp/gimpenums.c is
Fix spelling errors found with codespell
2024-12-27 17:57:33 +01:00
# not versioned so we don't use the mkenums_wrap.
Issue #8145: meson: generation of '*-enums.c' files. Our meson build system was not properly building the enums.c file, because they are versionned. I did a similar trick as what I did for the pdbgen, which is that I used a wrapper script around the existing perl script, which sets proper options and generate a stamp file in the end (which is considered by meson as the actual custom target, not the C file since it is generated in the source dir). The most important part is that the stamp file is a generated header source (not just a random text file) which is **included** by the generated C file. This is what will force meson to regenerate the C file if the header is updated, **then** build using this new version, not use an outdated versionned version (which would make for hard to diagnose bugs), through the indirection of the intermediate stamp header. See #4201. See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
2022-08-01 19:08:35 +02:00
# Moreover it is generated in 2 steps, first with common mkenums
# arguments, then concatenating with a "tail" file.
Meson port.
2017-11-01 14:27:13 +01:00
gimpenums_notail = custom_target('gimpenums.c.notail',
libgimp, pdb: (meson) fix building of libgimp/gimpenums.h inside the source tree. This was not working properly and needed some external build script as well as the stamp/bogus header trick like for other similar in-source generated code. In the same time, I get rid of old meson code which was meant for when using meson < 0.57.0 (since our requirement is now meson >= 0.59.0).
2023-08-30 15:52:47 +02:00
input : [ 'gimpenums.h', stamp_enumcode],
Meson port.
2017-11-01 14:27:13 +01:00
output: [ 'gimpenums.c.notail', ],
command: [
gimp_mkenums,
'--fhead','#include "config.h"\n'
+ '#include <gio/gio.h>\n'
+ '#include <gegl.h>\n'
+ '#include "libgimpbase/gimpbase.h"\n'
+ '#include "libgimpbase/gimpbase-private.h"\n'
+ '#include "libgimpconfig/gimpconfigenums.h"\n'
libgimp, pdb: (meson) fix building of libgimp/gimpenums.h inside the source tree. This was not working properly and needed some external build script as well as the stamp/bogus header trick like for other similar in-source generated code. In the same time, I get rid of old meson code which was meant for when using meson < 0.57.0 (since our requirement is now meson >= 0.59.0).
2023-08-30 15:52:47 +02:00
+ '#include "pdb/stamp-enumcode.h"\n'
Meson port.
2017-11-01 14:27:13 +01:00
+ '#include "gimpenums.h"\n',
Issue #8145: meson: generation of '*-enums.c' files. Our meson build system was not properly building the enums.c file, because they are versionned. I did a similar trick as what I did for the pdbgen, which is that I used a wrapper script around the existing perl script, which sets proper options and generate a stamp file in the end (which is considered by meson as the actual custom target, not the C file since it is generated in the source dir). The most important part is that the stamp file is a generated header source (not just a random text file) which is **included** by the generated C file. This is what will force meson to regenerate the C file if the header is updated, **then** build using this new version, not use an outdated versionned version (which would make for hard to diagnose bugs), through the indirection of the intermediate stamp header. See #4201. See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
2022-08-01 19:08:35 +02:00
'--fprod',
'/* enumerations from "@basename@" */',
'--vhead',
'GType\n'+
'@enum_name@_get_type (void)\n'+
'{\n'+
' static const G@Type@Value values[] =\n'+
' {',
'--vprod',
' { @VALUENAME@, "@VALUENAME@", "@valuenick@" },',
'--vtail',
' { 0, NULL, NULL }\n'+
' };\n',
'--dhead',
' static const Gimp@Type@Desc descs[] =\n'+
' {',
'--dprod',
' { @VALUENAME@, @valuedesc@, @valuehelp@ },'+
'@if (\'@valueabbrev@\' ne \'NULL\')@\n'+
' /* Translators: this is an abbreviated version of @valueudesc@.\n'+
' Keep it short. */\n'+
' { @VALUENAME@, @valueabbrev@, NULL },'+
'@endif@',
'--dtail',
libgimp_mkenums_dtails,
libgimp, pdb: (meson) fix building of libgimp/gimpenums.h inside the source tree. This was not working properly and needed some external build script as well as the stamp/bogus header trick like for other similar in-source generated code. In the same time, I get rid of old meson code which was meant for when using meson < 0.57.0 (since our requirement is now meson >= 0.59.0).
2023-08-30 15:52:47 +02:00
'@INPUT0@',
Meson port.
2017-11-01 14:27:13 +01:00
],
capture: true,
)
gimpenums = custom_target('gimpenums.c',
input : [ gimpenums_notail, 'gimpenums.c.tail', ],
output: [ 'gimpenums.c', ],
libgimp: Port from cat to Python
2025-04-17 15:22:26 -03:00
command: [python, '-c', 'import sys; [sys.stdout.write(open(f).read()) for f in sys.argv[1:]]','@INPUT@'],
Meson port.
2017-11-01 14:27:13 +01:00
capture: true,
)
gimpuimarshal = gnome.genmarshal('gimpuimarshal',
prefix: '_gimpui_marshal',
sources: 'gimpuimarshal.list',
install_header: false,
)
pdb_wrappers_sources = [
'gimp_pdb.c',
'gimpbrush_pdb.c',
'gimpbrushes_pdb.c',
'gimpbrushselect_pdb.c',
'gimpbuffer_pdb.c',
'gimpchannel_pdb.c',
'gimpcontext_pdb.c',
'gimpdebug_pdb.c',
'gimpdisplay_pdb.c',
'gimpdrawable_pdb.c',
'gimpdrawablecolor_pdb.c',
'gimpdrawableedit_pdb.c',
app, libgimp, pdb: passing GimpDrawableFilter across the wire. A few functions were added, but the main one is gimp_drawable_get_filters() to request the list of filters applied non-destructively on a drawable. We can't do much with these for the time being, but this will come. WIP.
2024-11-25 04:38:39 +09:00
'gimpdrawablefilter_pdb.c',
app, libgimp, pdb: new PDB group gimpdrawableselect. Similarly to the various GimpResource select PDB calls, this allows to call a core dialog in order to choose a drawable which will be returned back to the calling plug-in. This new GimpPickableSelect dialog is a subclass of GimpPdbDialog and uses the same GimpPickableChooser widget as GimpPickablePopup, except that since it's inter-process window management, it is harder to make a popup positioned accurately relatively to a parent (especially on Wayland). This is why it's a separate widget as a simpler dialog (which we will still try to make transient as much as possible across platforms).
2023-08-27 01:02:37 +02:00
'gimpdrawableselect_pdb.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpdynamics_pdb.c',
'gimpedit_pdb.c',
Fix Meson some changes not pulled from Autotools
2019-09-11 17:10:47 +02:00
'gimpfile_pdb.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpfloatingsel_pdb.c',
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-05 19:28:35 -04:00
'gimpfont_pdb.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpfonts_pdb.c',
'gimpfontselect_pdb.c',
'gimpgimprc_pdb.c',
'gimpgradient_pdb.c',
'gimpgradients_pdb.c',
'gimpgradientselect_pdb.c',
app, libgimp, pdb, plug-ins: new GimpGroupLayer class in libgimp. Also: - renaming gimp_layer_group_new() to gimp_group_layer_new() in order to keep the same name as in core code (i.e. GimpGroupLayer, not GimpLayerGroup). - renaming gimp_image_merge_layer_group() to gimp_group_layer_merge() - new functions: gimp_procedure_add_group_layer_argument(), gimp_procedure_add_group_layer_aux_argument() and gimp_procedure_add_group_layer_return_value(). This can be tested, e.g. in Python with these calls: ```py i = Gimp.get_images()[0] g = Gimp.GroupLayer.new(i, "hello") i.insert_layer(g, None, 1) g2 = Gimp.GroupLayer.new(i, "world") i.insert_layer(g2, g, 1) g.merge() ``` This was work started long ago, stored in an old stash which I finally finish now! :-)
2024-07-06 17:24:11 +02:00
'gimpgrouplayer_pdb.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimphelp_pdb.c',
'gimpimage_pdb.c',
API: fix #12860 autocrop is internal, not a compatibility plugin Rename plug_in_compat.pdb to image_autocrop.pdb so we retain commit history. All procedures defined there are related to autocrop. - made internal, not plugins - renamed from plug-in- to gimp-image- - exposed in libgimp If we need plugin compatibility PDB group in the future, a starting template can be recovered from plug_in_compat.pdb 2.10 or late 2.99. Fixed plugins that call. The C plugin now calls libgimp instead of a PDB procedure.
2025-02-06 14:55:27 -05:00
'gimpimageautocrop_pdb.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpimagecolorprofile_pdb.c',
'gimpimageconvert_pdb.c',
'gimpimagegrid_pdb.c',
'gimpimageguides_pdb.c',
'gimpimagesamplepoints_pdb.c',
'gimpimageselect_pdb.c',
'gimpimagetransform_pdb.c',
'gimpimageundo_pdb.c',
'gimpitem_pdb.c',
'gimpitemtransform_pdb.c',
'gimplayer_pdb.c',
'gimpmessage_pdb.c',
'gimppainttools_pdb.c',
'gimppalette_pdb.c',
'gimppalettes_pdb.c',
'gimppaletteselect_pdb.c',
pdb, libgimp: Rename libgimp GimpVectors vectors API... ...to paths Follow-up to d0bdbdfd. Changes all gimp_vectors_* () PDB to gimp_path_* () and renames relevant PDB files from vectors to path. The next step will be to rename GimpVectors in libgimp to GimpPath, removing the last (public) trace of it.
2024-07-08 23:39:51 +00:00
'gimppath_pdb.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimppattern_pdb.c',
'gimppatterns_pdb.c',
'gimppatternselect_pdb.c',
'gimpprogress_pdb.c',
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 16:12:04 +02:00
'gimpresource_pdb.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpselection_pdb.c',
'gimptextlayer_pdb.c',
'gimptexttool_pdb.c',
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
'gimpunit_pdb.c',
Meson port.
2017-11-01 14:27:13 +01:00
]
pdb_wrappers_headers = [
'gimp_pdb_headers.h',
'gimp_pdb.h',
'gimpbrush_pdb.h',
'gimpbrushes_pdb.h',
'gimpbrushselect_pdb.h',
'gimpbuffer_pdb.h',
'gimpchannel_pdb.h',
'gimpcontext_pdb.h',
'gimpdebug_pdb.h',
'gimpdisplay_pdb.h',
'gimpdrawable_pdb.h',
'gimpdrawablecolor_pdb.h',
'gimpdrawableedit_pdb.h',
app, libgimp, pdb: passing GimpDrawableFilter across the wire. A few functions were added, but the main one is gimp_drawable_get_filters() to request the list of filters applied non-destructively on a drawable. We can't do much with these for the time being, but this will come. WIP.
2024-11-25 04:38:39 +09:00
'gimpdrawablefilter_pdb.h',
app, libgimp, pdb: new PDB group gimpdrawableselect. Similarly to the various GimpResource select PDB calls, this allows to call a core dialog in order to choose a drawable which will be returned back to the calling plug-in. This new GimpPickableSelect dialog is a subclass of GimpPdbDialog and uses the same GimpPickableChooser widget as GimpPickablePopup, except that since it's inter-process window management, it is harder to make a popup positioned accurately relatively to a parent (especially on Wayland). This is why it's a separate widget as a simpler dialog (which we will still try to make transient as much as possible across platforms).
2023-08-27 01:02:37 +02:00
'gimpdrawableselect_pdb.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpdynamics_pdb.h',
'gimpedit_pdb.h',
Fix Meson some changes not pulled from Autotools
2019-09-11 17:10:47 +02:00
'gimpfile_pdb.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpfloatingsel_pdb.h',
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-05 19:28:35 -04:00
'gimpfont_pdb.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpfonts_pdb.h',
'gimpfontselect_pdb.h',
'gimpgimprc_pdb.h',
'gimpgradient_pdb.h',
'gimpgradients_pdb.h',
'gimpgradientselect_pdb.h',
app, libgimp, pdb, plug-ins: new GimpGroupLayer class in libgimp. Also: - renaming gimp_layer_group_new() to gimp_group_layer_new() in order to keep the same name as in core code (i.e. GimpGroupLayer, not GimpLayerGroup). - renaming gimp_image_merge_layer_group() to gimp_group_layer_merge() - new functions: gimp_procedure_add_group_layer_argument(), gimp_procedure_add_group_layer_aux_argument() and gimp_procedure_add_group_layer_return_value(). This can be tested, e.g. in Python with these calls: ```py i = Gimp.get_images()[0] g = Gimp.GroupLayer.new(i, "hello") i.insert_layer(g, None, 1) g2 = Gimp.GroupLayer.new(i, "world") i.insert_layer(g2, g, 1) g.merge() ``` This was work started long ago, stored in an old stash which I finally finish now! :-)
2024-07-06 17:24:11 +02:00
'gimpgrouplayer_pdb.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimphelp_pdb.h',
'gimpimage_pdb.h',
API: fix #12860 autocrop is internal, not a compatibility plugin Rename plug_in_compat.pdb to image_autocrop.pdb so we retain commit history. All procedures defined there are related to autocrop. - made internal, not plugins - renamed from plug-in- to gimp-image- - exposed in libgimp If we need plugin compatibility PDB group in the future, a starting template can be recovered from plug_in_compat.pdb 2.10 or late 2.99. Fixed plugins that call. The C plugin now calls libgimp instead of a PDB procedure.
2025-02-06 14:55:27 -05:00
'gimpimageautocrop_pdb.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpimagecolorprofile_pdb.h',
'gimpimageconvert_pdb.h',
'gimpimagegrid_pdb.h',
'gimpimageguides_pdb.h',
'gimpimagesamplepoints_pdb.h',
'gimpimageselect_pdb.h',
'gimpimagetransform_pdb.h',
'gimpimageundo_pdb.h',
'gimpitem_pdb.h',
'gimpitemtransform_pdb.h',
'gimplayer_pdb.h',
'gimpmessage_pdb.h',
'gimppainttools_pdb.h',
'gimppalette_pdb.h',
'gimppalettes_pdb.h',
'gimppaletteselect_pdb.h',
pdb, libgimp: Rename libgimp GimpVectors vectors API... ...to paths Follow-up to d0bdbdfd. Changes all gimp_vectors_* () PDB to gimp_path_* () and renames relevant PDB files from vectors to path. The next step will be to rename GimpVectors in libgimp to GimpPath, removing the last (public) trace of it.
2024-07-08 23:39:51 +00:00
'gimppath_pdb.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimppattern_pdb.h',
'gimppatterns_pdb.h',
'gimppatternselect_pdb.h',
'gimpprogress_pdb.h',
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 16:12:04 +02:00
'gimpresource_pdb.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpselection_pdb.h',
'gimptextlayer_pdb.h',
'gimptexttool_pdb.h',
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
'gimpunit_pdb.h',
Meson port.
2017-11-01 14:27:13 +01:00
]
libgimp_sources_introspectable = [
'gimp.c',
app, pdb, libgimp: new GimpBatchProcedure class. This new class will be used to register procedures usable for batch processing.
2022-04-16 17:09:21 +02:00
'gimpbatchprocedure.c',
libgimp, pdb: replacing gimp_brush_get_pixels() by gimp_brush_get_buffer()… … and gimp_brush_get_mask(). gimp_brush_get_pixels() was a bit crappy, returning raw data with only dimensions and bpp to go with (no color model/space, no bit depth…). So the assumption is that we work with 8-bit per channel data, possibly with alpha depending of number of channels as deduced from bpp, and very likely in sRGB color space. It might be globally ok with many of the brush formats (and historical brushes) but won't fare well as we improve brush capabilities. - gimp_brush_get_pixels() is in fact made private. - The 2 new functions are using this old PDB call _gimp_brush_get_pixels() to construct buffers. This has some limitations, in particular that it returns only 8-bit per channel sRGB data, but at least the signature won't change when we will improve things in the future (so if some day, we pass fancy brushes in high-bit depth, the method will stay the same). - This new implementation also allows scaling down the brush (keeping aspect ratio) which is useful when you need to fit a brush preview into a drawing widget. - Current implementation stores the buffers at native size in the libgimp's GimpBrush object, hence save re-querying the core every time you need an update. This can be improved as current implementation also means that you don't get updates if the brush changed. This should handle most common use cases for now, though. - Also with this change, I move GimpBrush class implementation into its own dedicated file.
2023-08-18 16:39:11 +02:00
'gimpbrush.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpchannel.c',
'gimpdisplay.c',
'gimpdrawable.c',
app, libgimp, pdb: passing GimpDrawableFilter across the wire. A few functions were added, but the main one is gimp_drawable_get_filters() to request the list of filters applied non-destructively on a drawable. We can't do much with these for the time being, but this will come. WIP.
2024-11-25 04:38:39 +09:00
'gimpdrawablefilter.c',
app, libgimp, pdb: new GimpDrawableFilterConfig class. This is mostly an empty shell whose goal is to serve as base class for specific dynamically generated per-operation subclasses, which will have properties mimicking the arguments of the GEGL operation. Most of the fundamental type args will just use the base GLib param spec types instead of GEGL ones. As a special case, the GeglParamEnum arguments are transformed into GimpChoice param specs on libgimp side. The reason is that most of the time, enum types are created within the scope of an operation code only and cannot be properly reconstructed over the wire. I could just transform these into an int type (which is mostly what is done in GEGL right now when running an op with such arg), but GimpChoice allow much nicer string-type args, which make much more semantic code. This class was initially created for plug-ins, but it would work very well to run GEGL ops on drawables. So let's do it. Finally add a gimp_drawable_filter_get_config() to request the current config of a filter. Note that right now, we can't do much with this config object other than observing an operation args and default values. Being able to update a filter's settings will come up in further commits.
2024-11-28 01:07:23 +09:00
'gimpdrawablefilterconfig.c',
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-06 18:38:12 +00:00
'gimpexportoptions.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpfileprocedure.c',
libgimp: move GimpFont, GimpGradient and GimpPalette to their own file. Even though we don't have specific additional functions right now, it's just much more cleaner this way.
2023-08-19 00:44:51 +02:00
'gimpfont.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpgimprc.c',
libgimp: move GimpFont, GimpGradient and GimpPalette to their own file. Even though we don't have specific additional functions right now, it's just much more cleaner this way.
2023-08-19 00:44:51 +02:00
'gimpgradient.c',
app, libgimp, pdb, plug-ins: new GimpGroupLayer class in libgimp. Also: - renaming gimp_layer_group_new() to gimp_group_layer_new() in order to keep the same name as in core code (i.e. GimpGroupLayer, not GimpLayerGroup). - renaming gimp_image_merge_layer_group() to gimp_group_layer_merge() - new functions: gimp_procedure_add_group_layer_argument(), gimp_procedure_add_group_layer_aux_argument() and gimp_procedure_add_group_layer_return_value(). This can be tested, e.g. in Python with these calls: ```py i = Gimp.get_images()[0] g = Gimp.GroupLayer.new(i, "hello") i.insert_layer(g, None, 1) g2 = Gimp.GroupLayer.new(i, "world") i.insert_layer(g2, g, 1) g.merge() ``` This was work started long ago, stored in an old stash which I finally finish now! :-)
2024-07-06 17:24:11 +02:00
'gimpgrouplayer.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpimage.c',
'gimpimagecolorprofile.c',
libgimp: better organization of gimp_image_metadata_*() API. gimpimagemetadata.[ch] was built into libgimpui because GTK+ was used for dialog query for rotation metadata. gimpimagemetadata-save.c only was built into libgimp, which made no sense as the declaration for its public function was inside gimpimagemetadata.h! That was a weird situation and somehow only made visible in the build system because GIR build was complaining about missing annotations to gimp_image_metadata_save_prepare() (the annotation was actually present but in the implementation which was not in the same library as the header, how weird!): > Warning: GimpUi: gimp_image_metadata_save_prepare: return value: Missing (transfer) annotation Moreover it means that only plug-ins linking libgimpui had access to the gimp_image_metadata*() API, which is obviously not cool (that should be a core API). Instead I moved everything into libgimp and replaced gimp_image_metadata_load_finish() with gimp_image_metadata_load_finish_batch(), which is essentially the same function except that it's not interactive (it will proceed to rotate the image without user confirmation, provided the right flag is present). Then I add gimpimagemetadata-interactive.[ch] which contains only gimp_image_metadata_load_finish() and is the alternative interactive version of gimp_image_metadata_load_finish_batch(). Most plug-ins won't even have to be changed (at least none in core GIMP) and would still work as before, whereas now a non-interactive version exists, which doesn't mandate to link GTK+.
2020-09-13 13:09:59 +02:00
'gimpimagemetadata.c',
libgimp: start integrating image export with GimpProcedureConfig Add gimp_procedure_config_begin_export() and end_export() which are wrappers around begin_run() and end_run() and additionally pretty much completely manage GimpMetadata handling. A GimpProcedureConfig can provide boolean properties "save-exif", "save-xmp" etc. in order to have them automatically managed by begin_export() and end_export(). This also restores the feature of overriding the procedure's saved default values with export preferences, but not the values from the last export, like it used to be in 2.10. Move gimp_image_metadata_save_prepare() and save_finish() (which are now completely handled by GimpProcedureConfig) from libgimpui to libgimp, but keep their declarations in the libgimpui header. Not perfect, but not finished either. Also fix gimp_image_metadata_save_prepare() to set the affected GimpMetadataSaveFlags to 0 when the image has no metadata at all.
2019-10-09 22:32:07 +02:00
'gimpimagemetadata-save.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpimageprocedure.c',
'gimpitem.c',
'gimplayer.c',
'gimplayermask.c',
'gimploadprocedure.c',
libgimp: move GimpFont, GimpGradient and GimpPalette to their own file. Even though we don't have specific additional functions right now, it's just much more cleaner this way.
2023-08-19 00:44:51 +02:00
'gimppalette.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpparamspecs.c',
libgimp, app, pdb: Rename GimpVectors to GimpPath This commit renames the GimpVectors object to GimpPath in both app/core and in libgimp. It also renames the files to gimppath.[ch] and updates the relevant build and translation files. There are still outstanding gimp_vectors_* () functions on the app side that need to be renamed in a subsequent commit.
2024-07-12 06:16:25 +00:00
'gimppath.c',
app, libgimp, pdb: new gimp_pattern_get_buffer() and improved GimpPatternSelectButton. Similar to the latest commits for GimpBrush: - gimp_pattern_get_buffer() returns a GeglBuffer and allow getting a scaled version of the pattern. - Old gimp_pattern_get_pixels() is made private. - Moved GimpPattern into its own file and store the buffer to avoid re-querying it through PDB continuously. No as for the widget to select a pattern: - Preview frame ensured to be square. - Default size increased. - Drawing code using the new gimp_pattern_get_buffer(). - Cleaned up code.
2023-08-19 00:13:36 +02:00
'gimppattern.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimppdb.c',
'gimpplugin.c',
'gimpprocedure.c',
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
'gimpprocedure-params.c',
libgimp: add GimpProcedureConfig which implements the GimpConfig interface It's the base for bringing proper management of saved settings (including the last used values) and generated GUI using prop_widgets to plug-ins.
2019-09-20 12:31:11 +02:00
'gimpprocedureconfig.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpprogress.c',
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-05 19:28:35 -04:00
'gimpresource.c',
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 03:08:57 +00:00
'gimpexportprocedure.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpselection.c',
app, libgimp, pdb, plug-ins: new GimpTextLayer class in libgimp. Now text layers are proper types, which means that the binding API will also be nicer (e.g. `txt_layer.set_text('hello world')` in Python). This commit also adds the param specs allowing to create plug-in procedures with text layer parameters. Finally it fixes the few calls in file-pdf-save (apparently the only plug-in using specific text layer API right now) with explicit type conversion.
2022-09-30 16:21:47 +02:00
'gimptextlayer.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpthumbnailprocedure.c',
app, libgimp, pdb: new GimpVectorLoadProcedure class. It's still basic but will help to share code for support of various vector-able formats, such as the logic for dimensioning them, but also the generated GUI. Not only this, but we are paving the way for the link layers (though it'll be after GIMP 3, we want plug-in procedures' API to stay stable) by giving a way for a plug-in procedure to advertize a vector format support. This way, the core will know when a source file is vector and can be directly reloaded at any target size (right now, in my MR for link layers, the list of "vector" formats is hardcoded, which is not reliable).
2024-04-22 23:11:37 +02:00
'gimpvectorloadprocedure.c',
Meson port.
2017-11-01 14:27:13 +01:00
gimpenums,
pdb_wrappers_sources,
]
libgimp_sources = [
libgimp_sources_introspectable,
'gimp-debug.c',
'gimp-shm.c',
'gimpgpparams.c',
libgimp: revive parameter range descriptions in the procedure browser Copy gimp_param_specs_get_desc() to libgimp and make it also mention default values. Don't install its header for now, because it's pretty much a utility function of GimpProcView. It also doesn't handle most GParamSpec types yet. As a side effect, this fixed issue #3947.
2020-04-28 19:06:44 +02:00
'gimpparamspecs-desc.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimppdb_pdb.c',
'gimppdbprocedure.c',
'gimppixbuf.c',
'gimpplugin_pdb.c',
libgimp: make gimp_resource_select_*() API private.
2024-09-29 02:14:30 +02:00
'gimpresourceselect.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimptilebackendplugin.c',
]
libgimp_headers_introspectable = [
libgimp: reduce GObject Introspection warnings. Thanks to Massimo for helping: > To reduce the number of warnings down to 2, it is necessary to list > gimptypes.h and gimpenums.h right after gimp.h and gimpui.h > gimpuitypes.h at the start of libgimpui_headers_introspectable like > they are in the corresponding list in Makefile.gi. > > Their order evidently matters See #4018. Some stuff are still wrong, but this is a first step in the right direction.
2019-10-10 12:26:26 +02:00
# Order matters. Leave these headers at the top.
Meson port.
2017-11-01 14:27:13 +01:00
'gimp.h',
libgimp: reduce GObject Introspection warnings. Thanks to Massimo for helping: > To reduce the number of warnings down to 2, it is necessary to list > gimptypes.h and gimpenums.h right after gimp.h and gimpui.h > gimpuitypes.h at the start of libgimpui_headers_introspectable like > they are in the corresponding list in Makefile.gi. > > Their order evidently matters See #4018. Some stuff are still wrong, but this is a first step in the right direction.
2019-10-10 12:26:26 +02:00
'gimptypes.h',
'gimpenums.h',
# Other headers
app, pdb, libgimp: new GimpBatchProcedure class. This new class will be used to register procedures usable for batch processing.
2022-04-16 17:09:21 +02:00
'gimpbatchprocedure.h',
libgimp, pdb: replacing gimp_brush_get_pixels() by gimp_brush_get_buffer()… … and gimp_brush_get_mask(). gimp_brush_get_pixels() was a bit crappy, returning raw data with only dimensions and bpp to go with (no color model/space, no bit depth…). So the assumption is that we work with 8-bit per channel data, possibly with alpha depending of number of channels as deduced from bpp, and very likely in sRGB color space. It might be globally ok with many of the brush formats (and historical brushes) but won't fare well as we improve brush capabilities. - gimp_brush_get_pixels() is in fact made private. - The 2 new functions are using this old PDB call _gimp_brush_get_pixels() to construct buffers. This has some limitations, in particular that it returns only 8-bit per channel sRGB data, but at least the signature won't change when we will improve things in the future (so if some day, we pass fancy brushes in high-bit depth, the method will stay the same). - This new implementation also allows scaling down the brush (keeping aspect ratio) which is useful when you need to fit a brush preview into a drawing widget. - Current implementation stores the buffers at native size in the libgimp's GimpBrush object, hence save re-querying the core every time you need an update. This can be improved as current implementation also means that you don't get updates if the brush changed. This should handle most common use cases for now, though. - Also with this change, I move GimpBrush class implementation into its own dedicated file.
2023-08-18 16:39:11 +02:00
'gimpbrush.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpchannel.h',
'gimpdisplay.h',
'gimpdrawable.h',
app, libgimp, pdb: passing GimpDrawableFilter across the wire. A few functions were added, but the main one is gimp_drawable_get_filters() to request the list of filters applied non-destructively on a drawable. We can't do much with these for the time being, but this will come. WIP.
2024-11-25 04:38:39 +09:00
'gimpdrawablefilter.h',
app, libgimp, pdb: new GimpDrawableFilterConfig class. This is mostly an empty shell whose goal is to serve as base class for specific dynamically generated per-operation subclasses, which will have properties mimicking the arguments of the GEGL operation. Most of the fundamental type args will just use the base GLib param spec types instead of GEGL ones. As a special case, the GeglParamEnum arguments are transformed into GimpChoice param specs on libgimp side. The reason is that most of the time, enum types are created within the scope of an operation code only and cannot be properly reconstructed over the wire. I could just transform these into an int type (which is mostly what is done in GEGL right now when running an op with such arg), but GimpChoice allow much nicer string-type args, which make much more semantic code. This class was initially created for plug-ins, but it would work very well to run GEGL ops on drawables. So let's do it. Finally add a gimp_drawable_filter_get_config() to request the current config of a filter. Note that right now, we can't do much with this config object other than observing an operation args and default values. Being able to update a filter's settings will come up in further commits.
2024-11-28 01:07:23 +09:00
'gimpdrawablefilterconfig.h',
core, pdb, plug-ins: Create GimpExportOptions class This patch creates a GimpExportOptions class in both libgimpbase and in libgimp. Currently it is a mostly empty object, but it will be added to after 3.0 to allow for additional export options (like resizing on export while leaving the original image intact) libgimp/gimpexport.c was removed, and most of its content was copied into libgimp/gimpexportoptions.c. gimp_export_image () was replaced with gimp_export_options_get_image () in all export plug-ins. GimpExportProcedure has a new function to set the default image capabilities for each plug-in on creation. It also sets up a new callback function, which allows the options to respond to user setting changes (such as toggling 'Save as Animation' in the GIF or WEBP Plug-in).
2024-05-06 18:38:12 +00:00
'gimpexportoptions.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpfileprocedure.h',
libgimp: move GimpFont, GimpGradient and GimpPalette to their own file. Even though we don't have specific additional functions right now, it's just much more cleaner this way.
2023-08-19 00:44:51 +02:00
'gimpfont.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpgimprc.h',
libgimp: move GimpFont, GimpGradient and GimpPalette to their own file. Even though we don't have specific additional functions right now, it's just much more cleaner this way.
2023-08-19 00:44:51 +02:00
'gimpgradient.h',
app, libgimp, pdb, plug-ins: new GimpGroupLayer class in libgimp. Also: - renaming gimp_layer_group_new() to gimp_group_layer_new() in order to keep the same name as in core code (i.e. GimpGroupLayer, not GimpLayerGroup). - renaming gimp_image_merge_layer_group() to gimp_group_layer_merge() - new functions: gimp_procedure_add_group_layer_argument(), gimp_procedure_add_group_layer_aux_argument() and gimp_procedure_add_group_layer_return_value(). This can be tested, e.g. in Python with these calls: ```py i = Gimp.get_images()[0] g = Gimp.GroupLayer.new(i, "hello") i.insert_layer(g, None, 1) g2 = Gimp.GroupLayer.new(i, "world") i.insert_layer(g2, g, 1) g.merge() ``` This was work started long ago, stored in an old stash which I finally finish now! :-)
2024-07-06 17:24:11 +02:00
'gimpgrouplayer.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpimage.h',
'gimpimagecolorprofile.h',
libgimp: better organization of gimp_image_metadata_*() API. gimpimagemetadata.[ch] was built into libgimpui because GTK+ was used for dialog query for rotation metadata. gimpimagemetadata-save.c only was built into libgimp, which made no sense as the declaration for its public function was inside gimpimagemetadata.h! That was a weird situation and somehow only made visible in the build system because GIR build was complaining about missing annotations to gimp_image_metadata_save_prepare() (the annotation was actually present but in the implementation which was not in the same library as the header, how weird!): > Warning: GimpUi: gimp_image_metadata_save_prepare: return value: Missing (transfer) annotation Moreover it means that only plug-ins linking libgimpui had access to the gimp_image_metadata*() API, which is obviously not cool (that should be a core API). Instead I moved everything into libgimp and replaced gimp_image_metadata_load_finish() with gimp_image_metadata_load_finish_batch(), which is essentially the same function except that it's not interactive (it will proceed to rotate the image without user confirmation, provided the right flag is present). Then I add gimpimagemetadata-interactive.[ch] which contains only gimp_image_metadata_load_finish() and is the alternative interactive version of gimp_image_metadata_load_finish_batch(). Most plug-ins won't even have to be changed (at least none in core GIMP) and would still work as before, whereas now a non-interactive version exists, which doesn't mandate to link GTK+.
2020-09-13 13:09:59 +02:00
'gimpimagemetadata.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpimageprocedure.h',
libgimp: sync autotools and meson to the same list of introspectable… … headers. gimpitem.h was missing, as noted (again!) by Massimo, which resulted into introspected plug-ins errors (breaking parenting of classes).
2019-10-10 12:39:07 +02:00
'gimpitem.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimplayer.h',
'gimplayermask.h',
'gimploadprocedure.h',
libgimp: move GimpFont, GimpGradient and GimpPalette to their own file. Even though we don't have specific additional functions right now, it's just much more cleaner this way.
2023-08-19 00:44:51 +02:00
'gimppalette.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpparamspecs.h',
libgimp, app, pdb: Rename GimpVectors to GimpPath This commit renames the GimpVectors object to GimpPath in both app/core and in libgimp. It also renames the files to gimppath.[ch] and updates the relevant build and translation files. There are still outstanding gimp_vectors_* () functions on the app side that need to be renamed in a subsequent commit.
2024-07-12 06:16:25 +00:00
'gimppath.h',
app, libgimp, pdb: new gimp_pattern_get_buffer() and improved GimpPatternSelectButton. Similar to the latest commits for GimpBrush: - gimp_pattern_get_buffer() returns a GeglBuffer and allow getting a scaled version of the pattern. - Old gimp_pattern_get_pixels() is made private. - Moved GimpPattern into its own file and store the buffer to avoid re-querying it through PDB continuously. No as for the widget to select a pattern: - Preview frame ensured to be square. - Default size increased. - Drawing code using the new gimp_pattern_get_buffer(). - Cleaned up code.
2023-08-19 00:13:36 +02:00
'gimppattern.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimppdb.h',
'gimpplugin.h',
'gimpprocedure.h',
libgimp: Convert gimpprocedure-params macros to functions In order for Python plug-ins to be able to create custom parameters like GeglColor and GimpChoice, we need to create actual functions rather than using macros. A subsequent commit will update all plug-ins to use them.
2024-06-07 03:05:04 +00:00
'gimpprocedure-params.h',
libgimp: add GimpProcedureConfig which implements the GimpConfig interface It's the base for bringing proper management of saved settings (including the last used values) and generated GUI using prop_widgets to plug-ins.
2019-09-20 12:31:11 +02:00
'gimpprocedureconfig.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpprogress.h',
2.99 libgimp: add GimpResource, GimpBrush, GimpPropWidgetBrush So procedures can declare args and GimpProcedureDialog show chooser widgets Fix so is no error dialog on id_is_valid for resources Palette.pdb changes and testing Memory mgt changes Gradient pdb Font and Pattern tests Test brush, palette Cleanup, remove generator Rebase, edit docs, install test-dialog.py Whitespace, and fix failed distcheck Fix some clang-format, fix fail distcheck Fix distcheck Cleanup from review Jehan
2022-09-05 19:28:35 -04:00
'gimpresource.h',
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 03:08:57 +00:00
'gimpexportprocedure.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpselection.h',
app, libgimp, pdb, plug-ins: new GimpTextLayer class in libgimp. Now text layers are proper types, which means that the binding API will also be nicer (e.g. `txt_layer.set_text('hello world')` in Python). This commit also adds the param specs allowing to create plug-in procedures with text layer parameters. Finally it fixes the few calls in file-pdf-save (apparently the only plug-in using specific text layer API right now) with explicit type conversion.
2022-09-30 16:21:47 +02:00
'gimptextlayer.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpthumbnailprocedure.h',
libgimp: fix libgimp introspection. - Fix a few broken references and an inconsistent argument name. - Add the new headers in the introspectable header list. - Add a few missing class descriptions for GimpProcedure and subclasses.
2024-04-24 16:02:08 +02:00
'gimpvectorloadprocedure.h',
libgimp: fix introspection of PDB functions in meson build. PDB headers had been forgotten and therefore a whole bunch of functions were not introspected.
2019-09-14 23:24:35 +02:00
pdb_wrappers_headers,
Meson port.
2017-11-01 14:27:13 +01:00
]
libgimp_headers = [
libgimp_headers_introspectable,
]
libgimpui_sources_introspectable = [
'gimpaspectpreview.c',
libgimp: rename Gimp*SelectButton widgets to Gimp*Chooser. This name was really irking me because it's not a button (anymore? Maybe it used to be just a button). Depending on the specific widget, it will have several sub-widgets, including a label. And it can theoretically even be something else than a button. So let's just rename these widgets with the more generic "chooser" name.
2023-08-19 01:22:09 +02:00
'gimpbrushchooser.c',
libgimp: new GimpDrawableChooser widget, associated propwidget function and… … generation of such a widget for drawable arguments in PDB procedures.
2023-08-28 21:42:39 +02:00
'gimpdrawablechooser.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpdrawablepreview.c',
libgimp: rename Gimp*SelectButton widgets to Gimp*Chooser. This name was really irking me because it's not a button (anymore? Maybe it used to be just a button). Depending on the specific widget, it will have several sub-widgets, including a label. And it can theoretically even be something else than a button. So let's just rename these widgets with the more generic "chooser" name.
2023-08-19 01:22:09 +02:00
'gimpfontchooser.c',
'gimpgradientchooser.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpimagecombobox.c',
'gimpitemcombobox.c',
libgimp: rename Gimp*SelectButton widgets to Gimp*Chooser. This name was really irking me because it's not a button (anymore? Maybe it used to be just a button). Depending on the specific widget, it will have several sub-widgets, including a label. And it can theoretically even be something else than a button. So let's just rename these widgets with the more generic "chooser" name.
2023-08-19 01:22:09 +02:00
'gimppalettechooser.c',
'gimppatternchooser.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpprocbrowserdialog.c',
libgimp: add GimpProcedureDialog, the new dialog class for plug-ins It knows about the procedure and its config, and so far implements the entire construction boilerplate and "Reset" on its own.
2019-09-20 19:24:40 +02:00
'gimpproceduredialog.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpprocview.c',
'gimpprogressbar.c',
libgimp*, plug-ins: reorganize the resource property choosers. - Move the property widget functions for GimpResource properties into a new libgimp/gimppropwidgets.[ch] file. This mirrors the files libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types. - Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new(). - gimp_prop_chooser_factory() doesn't need to be public. - Add a label to GimpResourceSelectButton, make so that the gimp_prop_chooser_*_new() functions set the property nick to this label and add this label to the size group in GimpProcedureDialog.
2023-08-17 23:02:38 +02:00
'gimppropwidgets.c',
libgimp: rename Gimp*SelectButton widgets to Gimp*Chooser. This name was really irking me because it's not a button (anymore? Maybe it used to be just a button). Depending on the specific widget, it will have several sub-widgets, including a label. And it can theoretically even be something else than a button. So let's just rename these widgets with the more generic "chooser" name.
2023-08-19 01:22:09 +02:00
'gimpresourcechooser.c',
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 03:08:57 +00:00
'gimpexportproceduredialog.c',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpui.c',
'gimpzoompreview.c',
libgimp: new GimpVectorLoadProcedureDialog widget. As expected, it is made to reuse shared code for every GimpVectorLoadProcedure. In particular, they all need to choose dimensions to load at, so we are sharing a same GimpResolutionEntry widget logic everywhere now. I am in fact still very unsure about the code logic for this widget by the way for these reasons: * It still puts too much emphasis on the "resolution" (pixel density) part, which makes people believe it's important, while they should in fact choose the pixel dimensions most of the time and not care about the pixel density. * Right now we can't break ratio (which in fact was already impossible in most vector format plug-ins we had). Do we want to add a chain and allow this? * If we consider the pixel density as the one we want to set the document with (which may not be the same thing as the one from when we load the document), we also want to break link between width/height dimensions and pixel density. Right now we can't (updating one field updates the others too). * There is always this issue of precision with pixel density vs. pixel dimensions because we don't necessarily find the same values when computing from one side to another because of lack of precision and this confuses people. * Finally there is the question of multi-page documents (e.g. PDF) where the chosen dimensions are the document dimensions whereas each page may have a different size which has to be recomputed independently and this got me off-by-one errors. I think I'll need to review a bit the logic, but I'll do once I've ported all the vector format load plug-ins first to see the most common usages.
2024-04-23 22:27:26 +02:00
'gimpvectorloadproceduredialog.c',
Meson port.
2017-11-01 14:27:13 +01:00
]
libgimpui_sources = [
libgimpui_sources_introspectable,
gimpuimarshal,
libgimp: re-promote GimpResolutionEntry in its own file and improve its API. The code comes from plug-ins/common/file-pdf-load.c and apparently it used to be in libgimpwidgets (very long ago). I'm copying it to its own file and massively improve the code (depending on property binding which makes the behavior much more robust). Still I left it as private because I don't want to say the API is finale without having tested it a bit more. But eventually we should make it public for plug-ins to use it directly too. When this happens, it should get back to libgimpwidgets.
2024-04-22 23:54:10 +02:00
# TODO: eventually move to libgimpwidgets.
'gimpresolutionentry-private.c'
Meson port.
2017-11-01 14:27:13 +01:00
]
libgimpui_headers_introspectable = [
libgimp: reduce GObject Introspection warnings. Thanks to Massimo for helping: > To reduce the number of warnings down to 2, it is necessary to list > gimptypes.h and gimpenums.h right after gimp.h and gimpui.h > gimpuitypes.h at the start of libgimpui_headers_introspectable like > they are in the corresponding list in Makefile.gi. > > Their order evidently matters See #4018. Some stuff are still wrong, but this is a first step in the right direction.
2019-10-10 12:26:26 +02:00
# Order matters. Leave these headers at the top.
'gimpui.h',
'gimpuitypes.h',
# Other headers
Meson port.
2017-11-01 14:27:13 +01:00
'gimpaspectpreview.h',
libgimp: rename Gimp*SelectButton widgets to Gimp*Chooser. This name was really irking me because it's not a button (anymore? Maybe it used to be just a button). Depending on the specific widget, it will have several sub-widgets, including a label. And it can theoretically even be something else than a button. So let's just rename these widgets with the more generic "chooser" name.
2023-08-19 01:22:09 +02:00
'gimpbrushchooser.h',
libgimp: new GimpDrawableChooser widget, associated propwidget function and… … generation of such a widget for drawable arguments in PDB procedures.
2023-08-28 21:42:39 +02:00
'gimpdrawablechooser.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpdrawablepreview.h',
libgimp: rename Gimp*SelectButton widgets to Gimp*Chooser. This name was really irking me because it's not a button (anymore? Maybe it used to be just a button). Depending on the specific widget, it will have several sub-widgets, including a label. And it can theoretically even be something else than a button. So let's just rename these widgets with the more generic "chooser" name.
2023-08-19 01:22:09 +02:00
'gimpfontchooser.h',
'gimpgradientchooser.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpimagecombobox.h',
'gimpitemcombobox.h',
libgimp: rename Gimp*SelectButton widgets to Gimp*Chooser. This name was really irking me because it's not a button (anymore? Maybe it used to be just a button). Depending on the specific widget, it will have several sub-widgets, including a label. And it can theoretically even be something else than a button. So let's just rename these widgets with the more generic "chooser" name.
2023-08-19 01:22:09 +02:00
'gimppalettechooser.h',
'gimppatternchooser.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpprocbrowserdialog.h',
libgimp: fix typo and libgimpui build. Apart from some obvious typo, libgimpui link was failing with meson because it now relies on a function from libgimpconfig (i.e. gimp_config_reset()), since commit bfb7f43dbcb. This fixes: > /usr/bin/ld: libgimp/gimpproceduredialog.c:223: undefined reference to `gimp_config_reset'
2019-09-21 01:25:56 +02:00
'gimpproceduredialog.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpprocview.h',
'gimpprogressbar.h',
libgimp*, plug-ins: reorganize the resource property choosers. - Move the property widget functions for GimpResource properties into a new libgimp/gimppropwidgets.[ch] file. This mirrors the files libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types. - Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new(). - gimp_prop_chooser_factory() doesn't need to be public. - Add a label to GimpResourceSelectButton, make so that the gimp_prop_chooser_*_new() functions set the property nick to this label and add this label to the size group in GimpProcedureDialog.
2023-08-17 23:02:38 +02:00
'gimppropwidgets.h',
libgimp: rename Gimp*SelectButton widgets to Gimp*Chooser. This name was really irking me because it's not a button (anymore? Maybe it used to be just a button). Depending on the specific widget, it will have several sub-widgets, including a label. And it can theoretically even be something else than a button. So let's just rename these widgets with the more generic "chooser" name.
2023-08-19 01:22:09 +02:00
'gimpresourcechooser.h',
libgimp: GimpSaveProcedure to GimpExportProcedure This patch continues porting save API to export for the 3.0 release.
2024-04-20 03:08:57 +00:00
'gimpexportproceduredialog.h',
libgimp: fix libgimp introspection. - Fix a few broken references and an inconsistent argument name. - Add the new headers in the introspectable header list. - Add a few missing class descriptions for GimpProcedure and subclasses.
2024-04-24 16:02:08 +02:00
'gimpvectorloadproceduredialog.h',
Meson port.
2017-11-01 14:27:13 +01:00
'gimpzoompreview.h',
]
libgimp_introspectable = [
libgimp_sources_introspectable,
libgimp_headers_introspectable,
]
libgimpui_introspectable = [
libgimpui_sources_introspectable,
libgimpui_headers_introspectable,
]
libgimp = library('gimp-'+ gimp_api_version,
libgimp_sources,
include_directories: rootInclude,
dependencies: [
libgimp: libgimp does not depend on GTK+. Only libgimpui depends on GTK+, display servers and other GUI-related dependencies. There was a problematic include added in commit 0b56aa0d133 for macOS, but the needed code (testing the macro GDK_WINDOWING_QUARTZ to use some [NSApp activateIgnoringOtherApps:YES] API) doesn't seem to be present anymore in there, so I think that removing this include (replace by including GLib for other calls) should work fine. Of course, we'll know it when the separate CI will test a macOS build as we still don't have in-Gitlab macOS jobs. :-/
2022-12-26 22:22:37 +01:00
cairo,
gdk_pixbuf,
meson: Declare internal libgimp(ui) dependency By using Meson's `declare_dependency()`, we can avoid specifying the linked libraries, dependencies and includes we need over and over again. Basically, this conceptually acts like an internal pkg-config.
2020-05-11 06:34:31 +02:00
gegl,
gexiv2,
drmingw,
app, libgimp, plug-ins: improve GimpVectorLoadProcedure workflow. I'm moving the logic of choosing a correct default for width/height by adding an "extract dimensions" callback in the procedure. The logic is that every vector format out there should likely have metadata either for pixel dimensions or physical dimensions, or at the very least for no-unit dimensions (ratio only). Vector load procedures will have to implement only the extraction of such data in a callback called by GIMP but not how to act upon them, so that we have a common logic for all vector images. I am implementing this callback first in the SVG plug-in, moving all the code to extract dimensions (and improving it) in this callback. Also I am deleting "file-svg-load-thumb" procedure. I could simply reimplement it using the same code, but it looks to me like this is very useless for vector formats to have a specific thumbnail procedure (unless it were to use very specific metadata for faster result). This is vector data, just ask it directly at the proper bounding box size.
2024-04-26 01:07:59 +02:00
math,
app, devel-docs, libgimp: updating gimp_text_layer_[gs]et_font() and new… … function gimp_font_get_pango_font_description(). Also updating file-pdf-save which is the only plug-in using these right now. Note that I am not fully happy with the new function gimp_font_get_pango_font_description() because I experienced some weird behavior in file-pdf-save which is that some fonts were wrong if this is called after pango_cairo_font_map_set_resolution(). But let's say this is a first step looking for improvements.
2023-09-13 19:13:51 +02:00
pango,
pangoft2,
Meson port.
2017-11-01 14:27:13 +01:00
],
Issue #4291: meson: pdbgen not working. The build now successfully build the PDB files into the source folder itself. Unfortunately it seems I can't get meson dependencies to work properly, once more! I added a "sources" argument to the relevant library() or static_library() but it still uses old versions to build these. E.g. if I add an error on purpose to a pdb file, the next build still passes, yet the second-next fails (as it should have before). Note that I even tested a declare_dependency() with just the "sources" arguments, because it says "sources to add to targets (or generated header files that should be built before sources including them are built)" (so I assume it means that it should be trigger a rebuild, otherwise it's useless) but it's just not working. I'll investigate more. Still going with this for now, because at least generating the PDB source was a big miss until now. But we should
2022-03-27 22:07:32 +02:00
sources: [
pdbgen
],
Meson port.
2017-11-01 14:27:13 +01:00
c_args: [ '-DG_LOG_DOMAIN="LibGimp"', '-DGIMP_COMPILATION', ],
link_with: [
libgimpbase,
libgimpcolor,
libgimpconfig,
libgimp: fix (again) the meson build. My previous commit still is not completely right. Why is my local build and the CI working so differently?!
2021-08-04 00:55:29 +02:00
libgimpmodule,
Meson port.
2017-11-01 14:27:13 +01:00
],
vs_module_defs: 'gimp.def',
install: true,
version: so_version,
)
meson: Declare internal libgimp(ui) dependency By using Meson's `declare_dependency()`, we can avoid specifying the linked libraries, dependencies and includes we need over and over again. Basically, this conceptually acts like an internal pkg-config.
2020-05-11 06:34:31 +02:00
# Define an internal dependency for ease of reuse
libgimp_dep = declare_dependency(
Meson port.
2017-11-01 14:27:13 +01:00
dependencies: [
meson: Declare internal libgimp(ui) dependency By using Meson's `declare_dependency()`, we can avoid specifying the linked libraries, dependencies and includes we need over and over again. Basically, this conceptually acts like an internal pkg-config.
2020-05-11 06:34:31 +02:00
cairo,
gdk_pixbuf,
gegl,
Meson port.
2017-11-01 14:27:13 +01:00
],
link_with: [
libgimp,
libgimpbase,
libgimpcolor,
libgimp: fix typo and libgimpui build. Apart from some obvious typo, libgimpui link was failing with meson because it now relies on a function from libgimpconfig (i.e. gimp_config_reset()), since commit bfb7f43dbcb. This fixes: > /usr/bin/ld: libgimp/gimpproceduredialog.c:223: undefined reference to `gimp_config_reset'
2019-09-21 01:25:56 +02:00
libgimpconfig,
meson: Declare internal libgimp(ui) dependency By using Meson's `declare_dependency()`, we can avoid specifying the linked libraries, dependencies and includes we need over and over again. Basically, this conceptually acts like an internal pkg-config.
2020-05-11 06:34:31 +02:00
libgimpmath,
libgimp: fix (again) the meson build. My previous commit still is not completely right. Why is my local build and the CI working so differently?!
2021-08-04 00:55:29 +02:00
libgimpmodule,
meson: Declare internal libgimp(ui) dependency By using Meson's `declare_dependency()`, we can avoid specifying the linked libraries, dependencies and includes we need over and over again. Basically, this conceptually acts like an internal pkg-config.
2020-05-11 06:34:31 +02:00
],
include_directories: rootInclude,
)
libgimpui = library('gimpui-'+ gimp_api_version,
libgimpui_sources,
dependencies: [
libgimp_dep,
gexiv2,
gtk3,
],
libgimp: have libgimpui depend on pdbgen. There was a weird instance of build failure in CI when compiling one of the libgimpui files. It could not find one of the PDB-generated function: > ../libgimp/gimpaspectpreview.c:329:19: error: call to undeclared function 'gimp_image_get_selection'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] My assumption is that as a multi-threaded build, this file was compiled just at the same time as the PDB was generating it, and therefore it was empty, hence a very bad timing creating a build failure. As I recall, I created the bogus stamp file stamp-pdbgen.h specifically for such race condition issues (because meson has no generic dependency rule, so we can't just ask one job to wait for another). We were using this bogus object as source to libgimp, but not libgimpui. Hopefully this will fix the problem and it won't re-happen randomly.
2024-08-13 18:16:39 +02:00
sources: [
pdbgen
],
meson: Declare internal libgimp(ui) dependency By using Meson's `declare_dependency()`, we can avoid specifying the linked libraries, dependencies and includes we need over and over again. Basically, this conceptually acts like an internal pkg-config.
2020-05-11 06:34:31 +02:00
c_args: [ '-DG_LOG_DOMAIN="LibGimpUI"', '-DGIMP_COMPILATION', ],
link_with: [
Meson port.
2017-11-01 14:27:13 +01:00
libgimpwidgets,
],
vs_module_defs: 'gimpui.def',
install: true,
version: so_version,
)
meson: Declare internal libgimp(ui) dependency By using Meson's `declare_dependency()`, we can avoid specifying the linked libraries, dependencies and includes we need over and over again. Basically, this conceptually acts like an internal pkg-config.
2020-05-11 06:34:31 +02:00
# Define an internal dependency for ease of reuse
libgimpui_dep = declare_dependency(
dependencies: [
libgimp_dep,
gtk3,
],
link_with: [
libgimpui,
libgimpwidgets,
],
include_directories: rootInclude,
)
Meson port.
2017-11-01 14:27:13 +01:00
install_headers(
libgimp_headers,
libgimpui_headers_introspectable,
subdir: gimp_api_name / 'libgimp',
)
### GObject introspection
Split GIR into Gimp-3.0 and GimpUi-3.0 Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/4065
2020-05-08 21:41:00 +02:00
libgimp_introspectable_files = [
Meson port.
2017-11-01 14:27:13 +01:00
libgimp_introspectable,
libgimpbase_introspectable,
libgimpcolor_introspectable,
libgimpconfig_introspectable,
libgimpmath_introspectable,
libgimp: libgimpmodule is part of libgimp not libgimpui. Thanks to Stanislav Grinkov for noticing this error in the meson scripts (cf. his comment in #6362).
2021-08-03 15:54:49 +02:00
libgimpmodule_introspectable,
Introduce a global ID space for GimpData/GimpResource objects Much like for images and items. Change the PDB to transmit IDs instead of names for brush, pattern etc. and refactor a whole lot of libgimp code to deal with it. modified: libgimp/gimpplugin-private.h
2023-05-31 16:12:04 +02:00
'gimpparamspecs-body.c'
Split GIR into Gimp-3.0 and GimpUi-3.0 Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/4065
2020-05-08 21:41:00 +02:00
]
libgimpui_introspectable_files = [
libgimpui_introspectable,
Meson port.
2017-11-01 14:27:13 +01:00
libgimpwidgets_introspectable,
]
meson: make gir buildable yocto/oe is capable of building gobject introspection despite cross-compiling. add an option to enable gir build even if cross-compiling Signed-off-by: Markus Volk <f_l_k@t-online.de> Reviewer note (Jehan): this whole stuff is a mess. Actually I'd like to simply get rid of the whole no-gir-when-cross-compiling logics but I still can't figure out how to cross-build generically with GIR. Yet since some manage it with yocto, let's unblock them. See #7208.
2021-09-01 16:44:13 +02:00
if meson.is_cross_build() and not get_option('can-crosscompile-gir')
extensions: do not build Vala plug-in without GObject Introspection. Though GObject Introspection is normally not an option, the only case we don't build it yet is when cross-compiling (as we haven't found the right way to do it). So let's not build the Goat Exercise plug-in in Vala in such case as we needed the introspected libgimp.
2020-10-18 00:34:02 +02:00
have_gobject_introspection = false
libgimp: disable GObject Introspection generation when cross-compiling. This is hopefully a temporary setback since we want to consider the introspected API as a core feature (otherwise we'd end up with third party builds deactivating the feature, and get a very random experience depending on where you got GIMP) hence don't want it to be optional (note that I haven't added a configure option). Anyway for now, it seems that cross-building introspected data is not really supported (or I'm still figuring it out).
2019-09-22 19:51:07 +02:00
gobject_introspection_warning = '\n '.join(['',
'GObject Introspection is disabled while cross-compiling because',
'GI tools do not manage to properly generate introspection data',
'while cross-compiling. Nevertheless we consider our introspected',
'API as a core component of GIMP, thus you are expected to build',
INSTALL, libgimp: document a bit better the GIR cross-tool exception.
2022-01-06 19:24:32 +01:00
'this data natively.',
'To forcefully build with GObject Introspection, set:',
'-Dcan-crosscompile-gir=true'
libgimp: disable GObject Introspection generation when cross-compiling. This is hopefully a temporary setback since we want to consider the introspected API as a core feature (otherwise we'd end up with third party builds deactivating the feature, and get a very random experience depending on where you got GIMP) hence don't want it to be optional (note that I haven't added a configure option). Anyway for now, it seems that cross-building introspected data is not really supported (or I'm still figuring it out).
2019-09-22 19:51:07 +02:00
])
warning(gobject_introspection_warning)
warnings += gobject_introspection_warning
libgimp: (meson) disable GIR building when a sanitizer is set. Similar to the change in autotools, a few commits before.
2023-02-22 13:42:59 +01:00
elif get_option('b_sanitize') != 'none'
have_gobject_introspection = false
gobject_introspection_warning = '\n '.join(['',
'GObject Introspection is disabled while building with a sanitizer.',
'See: https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/375'
])
warning(gobject_introspection_warning)
warnings += gobject_introspection_warning
libgimp: disable GObject Introspection generation when cross-compiling. This is hopefully a temporary setback since we want to consider the introspected API as a core feature (otherwise we'd end up with third party builds deactivating the feature, and get a very random experience depending on where you got GIMP) hence don't want it to be optional (note that I haven't added a configure option). Anyway for now, it seems that cross-building introspected data is not really supported (or I'm still figuring it out).
2019-09-22 19:51:07 +02:00
else
extensions: do not build Vala plug-in without GObject Introspection. Though GObject Introspection is normally not an option, the only case we don't build it yet is when cross-compiling (as we haven't found the right way to do it). So let's not build the Goat Exercise plug-in in Vala in such case as we needed the introspected libgimp.
2020-10-18 00:34:02 +02:00
have_gobject_introspection = true
Split GIR into Gimp-3.0 and GimpUi-3.0 Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/4065
2020-05-08 21:41:00 +02:00
libgimp_gir_includes = [
'Babl-0.1',
'cairo-1.0',
'GdkPixbuf-2.0',
'Gegl-0.4',
'Gio-2.0',
'GLib-2.0',
'GObject-2.0',
app, devel-docs, libgimp: updating gimp_text_layer_[gs]et_font() and new… … function gimp_font_get_pango_font_description(). Also updating file-pdf-save which is the only plug-in using these right now. Note that I am not fully happy with the new function gimp_font_get_pango_font_description() because I experienced some weird behavior in file-pdf-save which is that some fonts were wrong if this is called after pango_cairo_font_map_set_resolution(). But let's say this is a first step looking for improvements.
2023-09-13 19:13:51 +02:00
'Pango-1.0',
Split GIR into Gimp-3.0 and GimpUi-3.0 Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/4065
2020-05-08 21:41:00 +02:00
]
gir_args = [
'-DGIMP_COMPILATION',
'-DGIMP_BASE_COMPILATION',
'-DGIMP_COLOR_COMPILATION',
'-DGIMP_CONFIG_COMPILATION',
'-DGIMP_MATH_COMPILATION',
'-DGIMP_MODULE_COMPILATION',
'-DGIMP_THUMB_COMPILATION',
'-DGIMP_WIDGETS_COMPILATION',
'--quiet',
]
libgimp: disable GObject Introspection generation when cross-compiling. This is hopefully a temporary setback since we want to consider the introspected API as a core feature (otherwise we'd end up with third party builds deactivating the feature, and get a very random experience depending on where you got GIMP) hence don't want it to be optional (note that I haven't added a configure option). Anyway for now, it seems that cross-building introspected data is not really supported (or I'm still figuring it out).
2019-09-22 19:51:07 +02:00
libgimp_gir = gnome.generate_gir(
libgimp,
libgimpbase,
libgimpcolor,
libgimpconfig,
libgimpmath,
libgimp: fix the meson build. Commit 24dc6bfeac was not totally complete.
2021-08-03 23:18:38 +02:00
libgimpmodule,
Meson port.
2017-11-01 14:27:13 +01:00
Split GIR into Gimp-3.0 and GimpUi-3.0 Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/4065
2020-05-08 21:41:00 +02:00
sources: libgimp_introspectable_files,
libgimp: disable GObject Introspection generation when cross-compiling. This is hopefully a temporary setback since we want to consider the introspected API as a core feature (otherwise we'd end up with third party builds deactivating the feature, and get a very random experience depending on where you got GIMP) hence don't want it to be optional (note that I haven't added a configure option). Anyway for now, it seems that cross-building introspected data is not really supported (or I'm still figuring it out).
2019-09-22 19:51:07 +02:00
nsversion: gimp_api_version,
namespace: 'Gimp',
identifier_prefix: 'Gimp',
Split GIR into Gimp-3.0 and GimpUi-3.0 Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/4065
2020-05-08 21:41:00 +02:00
symbol_prefix: 'gimp',
export_packages: 'gimp-' + gimp_api_version,
libgimp: Make sure GIR includes the right header When using GIR-based bindings that will eventually include the header files (like Vala), we need to make sure to tell the gir-scanner what file that is. Otherwise tools like `vapigen` have to make an educated guess (which will be wrong).
2019-08-20 18:20:01 +02:00
header: 'libgimp/gimp.h',
Split GIR into Gimp-3.0 and GimpUi-3.0 Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/4065
2020-05-08 21:41:00 +02:00
includes: libgimp_gir_includes,
extra_args: gir_args,
include_directories: rootInclude,
install: true,
)
Meson port.
2017-11-01 14:27:13 +01:00
Split GIR into Gimp-3.0 and GimpUi-3.0 Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/4065
2020-05-08 21:41:00 +02:00
libgimpui_gir = gnome.generate_gir(
libgimpui,
libgimpwidgets,
Meson port.
2017-11-01 14:27:13 +01:00
Split GIR into Gimp-3.0 and GimpUi-3.0 Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/4065
2020-05-08 21:41:00 +02:00
sources: libgimpui_introspectable_files,
nsversion: gimp_api_version,
namespace: 'GimpUi',
identifier_prefix: 'Gimp',
libgimp: 'gimp_ui' as priority prefix for GimpUi introspected module. Since meson 0.43.0 (below our current requirement), 'symbol_prefix' argument of gnome.generate_gir() allows an ordered list. If I prepend 'gimp_ui', it makes any gimp_ui_*() function to not start with 'ui_'. In particular, GimpUi.ui_init() becomes GimpUi.init() which is much less redundant.
2020-09-21 01:20:38 +02:00
symbol_prefix: [ 'gimp_ui', 'gimp' ],
Split GIR into Gimp-3.0 and GimpUi-3.0 Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/4065
2020-05-08 21:41:00 +02:00
export_packages: 'gimp-ui-' + gimp_api_version,
header: 'libgimp/gimpui.h',
libgimp: libgimp does not depend on GTK+. Only libgimpui depends on GTK+, display servers and other GUI-related dependencies. There was a problematic include added in commit 0b56aa0d133 for macOS, but the needed code (testing the macro GDK_WINDOWING_QUARTZ to use some [NSApp activateIgnoringOtherApps:YES] API) doesn't seem to be present anymore in there, so I think that removing this include (replace by including GLib for other calls) should work fine. Of course, we'll know it when the separate CI will test a macOS build as we still don't have in-Gitlab macOS jobs. :-/
2022-12-26 22:22:37 +01:00
includes: [ libgimp_gir_includes, 'Gtk-3.0', libgimp_gir[0] ],
Split GIR into Gimp-3.0 and GimpUi-3.0 Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/4065
2020-05-08 21:41:00 +02:00
extra_args: gir_args,
libgimp: disable GObject Introspection generation when cross-compiling. This is hopefully a temporary setback since we want to consider the introspected API as a core feature (otherwise we'd end up with third party builds deactivating the feature, and get a very random experience depending on where you got GIMP) hence don't want it to be optional (note that I haven't added a configure option). Anyway for now, it seems that cross-building introspected data is not really supported (or I'm still figuring it out).
2019-09-22 19:51:07 +02:00
include_directories: rootInclude,
install: true,
)
Allow building vala plugins
2020-05-08 21:49:44 +02:00
libgimp: generate build-only GIR/Typelib variants for macOS. The previous commit worked for all the compiled executables, but for Python plug-ins (and likely all other GObject-Introspected bindings), we need to generate a temporary typelib linking to the in-build-directory libgimp* libraries. This is similar to what the script `package/macports_build_app.sh` does for packaging in gimp-macos-build repository.
2024-04-14 16:20:39 +02:00
if platform_osx
g_ir_compiler = find_program('g-ir-compiler')
gimp_exe_typelib = custom_target('macos-typelib.stamp',
output: [ 'macos-typelib.stamp' ],
command: [
'make-in-build-typelib.sh', libgimp_gir, libgimpui_gir,
meson.current_build_dir(), prefix, g_ir_compiler
],
build_by_default: true)
endif
Allow building vala plugins
2020-05-08 21:49:44 +02:00
if have_vala
vapi_deps = [
'babl-0.1',
'cairo-1.0',
'gdk-pixbuf-2.0',
'gegl-0.4',
'gio-2.0',
'glib-2.0',
'gobject-2.0',
'gtk+-3.0',
]
libgimp_vapi = gnome.generate_vapi('gimp-' + gimp_api_version,
sources: libgimp_gir[0],
packages: vapi_deps,
install: true,
)
libgimpui_vapi = gnome.generate_vapi('gimp-ui-' + gimp_api_version,
sources: libgimpui_gir[0],
packages: vapi_deps + [ libgimp_vapi ],
install: true,
)
endif
libgimp: disable GObject Introspection generation when cross-compiling. This is hopefully a temporary setback since we want to consider the introspected API as a core feature (otherwise we'd end up with third party builds deactivating the feature, and get a very random experience depending on where you got GIMP) hence don't want it to be optional (note that I haven't added a configure option). Anyway for now, it seems that cross-building introspected data is not really supported (or I'm still figuring it out).
2019-09-22 19:51:07 +02:00
endif
issue #8274: Port .def files check in meson. The check script now takes into account both the autotools and meson file hierarchy (in autotools, built libs are in .libs/ subdirs). Also it now properly fails on missing lib.
2022-07-31 20:03:12 +02:00
Issue #11317: make Python plug-ins mandatory. Unlike the other bindings (Lua, JS, Vala) where we only have a demo plug-in, we actually have a bunch of interesting and useful Python plug-ins. Furthermore, we are running several Python scripts through GIMP during our build (to generate a few images), so pygobject becomes a build dependency anyway, even if it may not be a run dependency with -Dpython=disabled. This all becomes a bit confusing and in fact handling this case (of not installing Python plug-ins) seems like an annoyance while we lose good core plug-ins. So let's just make Python plug-ins mandatory. It's not like Python is very controversial these days, and AFAWK, it is available on every platform out there.
2024-08-09 01:01:58 +02:00
if not platform_windows and not platform_osx
libgimp: don't run defcheck.py on Windows. Ironically, it is a test for the Windows platform but it cannot run on Windows. First, because it expects a .so (which could be easily fixed), but even more because from web search, it looks like the nm tool may not exist on Windows (though I haven't checked). Anyway we only ever ran it from Linux machines and up to now, it worked just fine and was useful anyway. So let's go with it. Also clean a bit remnants from older attempts to run this script.
2022-08-01 21:15:32 +02:00
# Verify .def files for Windows.
# Ironically we only check this on non-Windows platform, since the
# script expects .so libraries, and I'm not sure that the `nm` tool is
# available on Windows.
# On the other hand, it is how it always has been, since we used to
# only run this on dist step (which we historically run on a GNU/Linux
# machine). And it worked fine until now.
issue #8274: Port .def files check in meson. The check script now takes into account both the autotools and meson file hierarchy (in autotools, built libs are in .libs/ subdirs). Also it now properly fails on missing lib.
2022-07-31 20:03:12 +02:00
custom_target('check-def-files',
input: [
'../libgimpbase/gimpbase.def',
'../libgimpcolor/gimpcolor.def',
'../libgimpconfig/gimpconfig.def',
'../libgimp/gimp.def',
'../libgimp/gimpui.def',
'../libgimpmath/gimpmath.def',
'../libgimpmodule/gimpmodule.def',
'../libgimpthumb/gimpthumb.def',
'../libgimpwidgets/gimpwidgets.def',
],
depends: [
libgimpbase,
libgimpcolor,
libgimpconfig,
libgimp,
libgimpui,
libgimpmath,
libgimpmodule,
libgimpthumb,
libgimpwidgets
],
output: [ 'check-def-files', ],
command: [
meson: fix warnings of deprecated features. Now that we bumped our meson requirement, meson is complaining about several features now deprecated even in the minimum required meson version: s/meson.source_root/meson.project_source_root/ to fix: > WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead. s/meson.build_root/meson.project_build_root/ to fix: > WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead. Fixing using path() on xdg_email and python ExternalProgram variables: > WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to fix: > WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
2022-08-31 01:07:27 +02:00
python, meson.project_source_root() / 'tools' / 'defcheck.py', meson.project_source_root(),
issue #8274: Port .def files check in meson. The check script now takes into account both the autotools and meson file hierarchy (in autotools, built libs are in .libs/ subdirs). Also it now properly fails on missing lib.
2022-07-31 20:03:12 +02:00
],
build_by_default: true,
)
endif
Reference in a new issue Copy permalink