Since part of our type system is resolved at run time, we need to use
run time facilities to get diagnostic messages, like deprecation
warnings for properties and signals.
We should mention the G_ENABLE_DIAGNOSTIC environment variable in the
migration guide, to let developers know how to catch deprecations and
changes while porting their code.
- Make the rules for including headers explicit
- Make the symbol visibility rules explicit, and drop the
old "leading underscore" hack
- Drop Private data structure declarations and priv pointers
from public headers
- Mention G_DECLARE_* macros
- Mention `#pragma once`
Remove all the old 2.x and 3.x version annotations.
GTK+ 4 is a new start, and from the perspective of a
GTK+ 4 developer all these APIs have been around since
the beginning.
GdkContentFormatsBuilder is currently not introspectable, as it does not
have a GType. We can turn it into a boxed type, but we need to implement
memory management for it.
The current gdk_content_formats_builder_free() function returns a newly
constructed value, so we cannot use it as a GBoxedFreeFunc; additionally
copying a GdkContentFormatsBuilder contents would make it a bit odd, as
you could get multiple identical GdkContentFormats out of the copies.
A simple approach is to model the GdkContentFormatsBuilder API to follow
the GBytes one: use reference counting for memory management, and have
a function to release a reference, return a GdkContentFormats, and reset
the GdkContentFormatsBuilder state.
For language bindings, we can provide a get_formats() function that
returns the GdkContentFormats instance and resets the builder instance,
leaving the reference count untouched.
For C convenience we can keep gdk_content_formats_builder_free(), and
make it a wrapper around gdk_content_formats_builder_get_formats(), with
the guarantee that it'll free the builder instance regardless of its
current reference count.
https://bugzilla.gnome.org/show_bug.cgi?id=793097https://blogs.gnome.org/otte/2018/02/03/builders/
This function is misnamed - it is only ever relevant for
windows. And with the ::hide-on-delete property , it is
no longer necessary to use the signal for this simple case.
These functions are entirely trivial, their documentation
is much longer than their implementation, and it contains
an example that is annotated as "don't do this"...
This is a bit of filechooser internals that gets shared with
nautilus, which is fine, but it shouldn't be part of our
public API. There are no other users than nautilus.
These can't be returned as part of the font description,
so we need new api for them. For now, this is just readonly
properties. Maybe these should be writable too, eventually.
