When creating shortcuts, there almost always are a trigger and an action
available for use. So make gtk_shortcut_new() take those as arguments.
Also add gtk_shortcut_new_with_arguments() so people can easily pass
those in, too.
Similar to GtkShortcutTrigger, GtkShortCutAction provides all the
different ways to activate a shortcut.
So far, these different ways are supported:
- do nothing
- Call a user-provided callback
- Call gtk_widget_activate()
- Call gtk_widget_mnemonic_activate()
- Emit an action signal
- Activate an action from the widget's action muxer
When creating shortcuts, there almost always are a trigger and an action
available for use. So make gtk_shortcut_new() take those as arguments.
Also add gtk_shortcut_new_with_arguments() so people can easily pass
those in, too.
Similar to GtkShortcutTrigger, GtkShortCutAction provides all the
different ways to activate a shortcut.
So far, these different ways are supported:
- do nothing
- Call a user-provided callback
- Call gtk_widget_activate()
- Call gtk_widget_mnemonic_activate()
- Emit an action signal
- Activate an action from the widget's action muxer
- Activate a GAction
This is a huge reorganization of GtkDropTarget. I did not know how to
split this up, so it's unfortunately all one commit.
Highlights:
- Split GtkDropTarget into GtkDropTarget and GtkDropTargetAsync
GtkDropTarget is the simple one that only works with GTypes and offers
a synchronous interface.
GtkDropTargetAsync retains the full old functionality and allows
handling mime types.
- Drop events are handled differently
Instead of picking a single drop target and sending all DND events to
it, every event is sent to every drop target. The first one to handle
the event gets to call gdk_drop_status(), further handlers do not
interact with the GdkDrop.
Of course, for the ultimate GDK_DROP_STARTING event, only the first
one to accept the drop gets to handle it.
This allows stacking DND event controllers that aren't necessarily
interested in handling the event or that might decide later to drop
it.
- Port all widgets to either of those
Both have a somewhat changed API due to the new event handling.
For the ones who should use the sync version, lots of cleanup was
involved to operate on a sync API.
It is enough to just set the parent (and make the parent
call gtk_native_check_resize in size_allocate).
This commit removes the relative_to argument to the
constructors of GtkPopover and GtkPopoverMenu, and
updates all callers.
GtkFileChooser's API predates GIO by a few years, so it started off with
filenames and URI as character arrays. After introducing GIO as a
dependency, the API included GFile-based entry points.
It's much more appropriate to use GFile everywhere, as we want to
encourage people to use GIO instead of passing random bytes to low level
POSIX API.
See: #2455
Restructure the getters for event fields to
be more targeted at particular event types.
Update all callers, and replace all direct
event struct access with getters.
As a side-effect, this drops some unused getters.
Add properties, and use string arrays instead of lists.
Among other things, this renames gtk_icon_theme_list_icons
to gtk_icon_theme_get_icon_names.
Fixes: https://gitlab.gnome.org/GNOME/gtk/issues/2410
Content providers are meant to be immutable, apart from very special
cases, but in those cases they need to emit
gdk_content_provider_content_changed().
Having a constructor that just uses a get_func invites abuse of this
by not making developers aware of those requirments.
In fact, all users in GTK failed to do this.
Instead, code should use the GtkDragSource::prepare signal to create
content providers when needed.
The same problem exists with gdk_content_provider_new_with_formats(),
but this commit doesn't touch that.
