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
After the :can-focus change in the previous commit, widgets
need to set suitable focus and grab_focus implementations
to implement the desired focus behavior.
This commit does that for all widgets.
This is an automated change doing these command:
git sed -f g gtk_widget_set_has_window gtk_widget_set_has_surface
git sed -f g gtk_widget_get_has_window gtk_widget_get_has_surface
git sed -f g gtk_widget_set_parent_window gtk_widget_set_parent_surface
git sed -f g gtk_widget_get_parent_window gtk_widget_get_parent_surface
git sed -f g gtk_widget_set_window gtk_widget_set_surface
git sed -f g gtk_widget_get_window gtk_widget_get_surface
git sed -f g gtk_widget_register_window gtk_widget_register_surface
git sed -f g gtk_widget_unregister_window gtk_widget_unregister_surface
git checkout NEWS*
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.
Instead, add a function gtk_image_set_icon_size() for the cases where
overriding the icon size is necessary.
Treat icon sizes the same way as pixel sizes, too. So gtk_image_clear()
no longer unsets the icon size.
Instead of returning the icon size with them, make
gtk_image_get_icon_name() and gtk_image_get_gicon() only return the icon
itself.
As a benefit, we can turn them into regular getters that return values
instead of requiring out parameters.
Instead, provide gtk_image_get_icon_size() to query the icon size.
This patch makes that work using 1 of 2 options:
1. Add all missing enums to the switch statement
or
2. Cast the switch argument to a uint to avoid having to do that (mostly
for GdkEventType).
I even found a bug while doing that: clearing a GtkImage with a surface
did not notify thae surface property.
The reason for enabling this flag even though it is tedious at times is
that it is very useful when adding values to an enum, because it makes
GTK immediately warn about all the switch statements where this enum is
relevant.
And I expect changes to enums to be frequent during the GTK4 development
cycle.
Since setting a clip is mandatory for almost all widgets, we can as well
change the size-allocate signature to include a out_clip parameter, just
like GtkCssGadget did. And since we now always propagate baselines, we
might as well pass that one on to size-allocate.
This way we can also make sure to transform the clip returned from
size-allocate to parent-coordinates, i.e. the same coordinate space
priv->allocation is in.
GtkShortcutLabel is a widget that displays a single
shortcut accelerator or gesture in the user interface,
and is currently used by the shortcuts window.
This widget, however, has public value as other applications
also may want to expose their own shortcuts. For instance,
it'll be useful for the Keyboard panel on Control Center and
the new shortcut editor in Pitivi, among others.
This patch exposes GtkShortcutLabel as a public widget,
and adds the necessary documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=769205
Add a way to associate a detailed action name with a shortcut.
If the action name is set, update the accelerator whenever
accels change on the window that the shortcuts window is
associated with.
https://bugzilla.gnome.org/show_bug.cgi?id=764975
Always have Since: annotations at the very bottom, use the correct
ClassName::signal-name/ClassName:property-name syntax, fix a few typos
in type names, wrong function names, non-existing type names, etc.
When doing a gtk_widget_show_all() on the shortcuts window,
accelerators for both RTL and LTR directions are being shown.
Make sure that no-show-all is set by default on hidden shortcuts, and
updated if the widget direction changes.
https://bugzilla.gnome.org/show_bug.cgi?id=759541
It turns out that it is nicer in glade to have just a single
widget that can show either a shortcut or a gesture, so make
GtkShortcutsShortcut do it both.
GtkShortcutsGesture is now redundant and will be removed before
the next stable release.
The prime example for direction-dependent shortcuts is using
<Alt>Left or <Alt>Right to go back. Support this by adding a
direction property to GtkShortcutsShortcut, and filtering by
the current text direction.
https://bugzilla.gnome.org/show_bug.cgi?id=757888
