Especially need to watch out with forgetting `(array)` and `(out)`
annotations, as they can really give a different API in certain (if not
most) bindings.
gimp_config_type_register() currently overrides GimpConfig::equal()
to only compare the properties of the most-derived type. However,
this prevents the properties of GimpOperationSettings from being
considered during comparison of operation-config objects. Instead,
don't override GimpConfig::equal(), and rely on
GIMP_CONFIG_PARAM_DONT_COMPARE to exclude specific base-class
properties from comparison.
Allow calling gimp_scanner_new_string() with a NULL `text` and a
negative `text_len` (which is interpreted as 0), instead of
requiring `text_len == 0` in this case. This allows passing a
negative `text_len` unconditionally to infer the length, even when
the string may be NULL.
In gimp_config_deserialize_fundamental(), cast integer token values
to the target value type *before* negating them, to avoid
performing unsigned negation, which can result in a positive value
when cast to the target value type (in particular, when the target
value type is float/double).
More of the files were wrong, or at least not absolutely identical to
the files generated by the autotools. I am not doing any code change
other than trying to make both build systems produce identical files
(except for slight differences on 2 files not worth the effort) even
though maybe some things can be improved (especially on the include
list). Maybe to be improved later.
Also fixing 2 of the previously autotools-generated files because of
space typos which should have been committed earlier.
Finally it is to be noted that there is no logics to copy the generated
files back to the source directory in the meson rules. I am not sure
anyway this is really worth it and maybe we should just stop tracking
these generated files eventually.
Allow passing a non-NULL `pspecs` with `n_pspecs == 0` to
gimp_config_type_register(), in particular since
g_object_class_list_properties() may return such values.
There is at least one valid case of a config type registration with no
parameters: when registering the gegl:nop operation. This is the default
case when running the GEGL operation tool. See implementation of
gimp_filter_tool_get_operation().
Therefore we ended up crashing GIMP just by calling this tool.
It now supports all GParamSpecs possible on the wire protocol, except
the ones that are implemented in app/ and libgimp/ (image, drawable,
...) and are not visible to libgimpconfig
GimpConfigWriter contains several constructors with the convention
`gimp_config_writer_new_* ()`. This will lead to problems however with
languages like Vala, where it cannot disambiguate the following:
```
// calls config_writer_new_string()
Gimp.ConfigWriter w = new ConfigWriter.string("xxx");
// calls config_writer_string()
w.string("xxx")
```
Using `from_` in constructors is general practice in GObject-bsed
libraries because of this.
This also fixes an error when trying to use vapigen on the GIMP .GIR
file.
The `GIMP_CONFIG_PROP_*` macros do not automatically set
`G_PARAM_STATIC_STRINGS`, which means each property that uses such a
macro does not have this flag set by default (and almost none set it
themselves). By adding `G_PARAM_STATIC_STRINGS` to
`GIMP_CONFIG_PARAM_FLAGS`, we can prevent this from happening, which
should lead to some unnecessary string copies being prevented.
libgimp is anyway processed at the very end after all other libgimp*
were built. This way, it also fixes#3746, by removing the $(top_srcdir)
everywhere from introspected files, hence making the build work again
with older automake.
Basically this commit makes sure that all return values that are marked
as "Returns:" also have a `(nullable)` annotation if it is mentioned on
the same line that NULL can also be returned.
This will prevent a few problems in GObject-introspection.
The latter is broken and doesn't guarantee a decimal point with the
current bug. Also, g_ascii_dtostr() doesn't need the format parameter
and produces nicer output.
A number without a decimal point can be put into a gdouble just fine,
no need to refuse them. Moreover, g_ascii_dtostr() serializes doubles
without fractional part without a decimal point, and we are soon going
to use it.
Several returned values had no documentation, and needed in particular
(transfer) annotations.
Fixes various warnings:
> return value: Missing (transfer) annotation
Only libgimpwidgets is not introspected yet as it didn't work from
scratch and I don't have the time right now to look into it. Anyway with
all the others, we already have so many warnings during the GObject
Introspection step now that we have a lot of work to do already!
When an error occurs, we want to prevent overwriting any previous
version of the file by incomplete contents. So run
g_output_stream_close() with a cancelled GCancellable to do so.
See also discussion in #2565.
Move swap/cache and temporary files out the GIMP user config dir:
libgimpbase: add gimp_cache_directory() and gimp_temp_directory()
which return the new default values inside XDG_CACHE_HOME and the
system temp directory. Like all directories from gimpenv.[ch] the
values can be overridden by environment variables. Improve API docs
for all functions returning directories.
Add new config file substitutions ${gimp_cache_dir} and
${gimp_temp_dir}.
Document all the new stuff in the gimp and gimprc manpages.
app: default "swap-path" and "temp-path" to the new config file
substitutions. On startup and config changes, make sure that the swap
and temp directories actually exist.
In the preferences dialog, add reset buttons to all file path pages.
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
Niels De Graef
sarah