As they are generated by gi-docgen thanks to the newly added async annotations.
It allows bindings that don't expose the _finish
functions to propose less-confusing docs
Those property features don't seem to be in use anywhere.
They are redundant since the docs cover the same information
and more. They also created unnecessary translation work.
Closes#4904
Remove a boatload of "or %NULL" from nullable parameters
and return values. gi-docgen generates suitable text from
the annotation that we don't need to duplicate.
This adds a few missing nullable annotations too.
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 API allows specifying a GType and va_args of a value of that type
to set the clipboard contents. This massively simplifies setting weird
object types into the clipboard.
2 example patches included in this patch are the GtkTextBuffer and the
file list in the file chooser.
Using gobject-introspection, this should work without specifying the
type, so that you can literlally say
clipboard.set ("Hello World")
or
clipboard.set (pixbuf)
which is why I've also marked all other setters as (skip). They just
exist in C as wrappers for type safety reasons.
This is in preparation of using input streams to show that these
coordinates aren't needed most of the time and can otherwise be saved
during GtkWidget::drag-drop.
Also make clipboard_claim() a vfunc so backends can override it.
Because the whole operation a vfunc, backends have the option of adding
code before the actual claim is done and potentially even fail or do
something after the successful claim.
Instead of having just one function that has the gtype and mime type as
out arguments, have 3 functions: 1 that finds any match, 1 that finds a
GType match and one for a mime type match.
This makes the API way more convenient to use.
This requires implementing a "pipe" so we can have 2 streams running:
contentprovider => serializer => outputstream
inputstream => deserializer => reader
And the pipe shoves the data from the outputstream into the inputstream.
GdkContentProvider is the object that represents local data in the
clipboard.
This patch only introduces the object and adds the clipboard properties,
it does not yet provide a way for the actual implementations to access
it.
The only access that is implemented is the local shortcut GValue access.
This allows us not just to pass any mime type to the read function, but
it also makes it possible to pass multiple mime types and the clipboard
can then try them in order until it finds a supported one.
This is so far not implemented though.
