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*
That's kinda weird but allows us to delete the texture case from
GtkIconHelper and GTK_IMAGE_TEXTURE from the GtkImageType enum.
And it doesn't cause any other problems because the cell renderer
can't deal with paintables - otherwise it would mirror GtkImage and have
a "paintable" property instead.
Do the mouse cursor un-obscuring in the ::motion handler instead of in
the ->event handler. We don't get rid of the GtkWidgetClass::event
handler altogether that way, but it's a step in the right direction.
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.
The main GDK thread lock is not portable and deprecated.
The only reason why gdk_threads_add_timeout() and
gdk_threads_add_timeout_full() exist is to allow invoking a callback
with the GDK lock held, in case 3rd party libraries still use the
deprecated gdk_threads_enter()/gdk_threads_leave() API.
Since we're removing the GDK lock, and we're releasing a new major API,
such code cannot exist any more; this means we can use the GLib API for
installing timeout callbacks.
https://bugzilla.gnome.org/show_bug.cgi?id=793124
We were allocating the progress bar to the full size
of the entry. This made entry icons loose their cursors,
since they were 'covered' by the progress bar, even though
it doesn't draw anything there.
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.
Instead of allowing people to pass a uint user-data, insist on them
comparing mime types.
The user data was a uint instead of a pointer anyway, so uniqueness
could not be guaranteed and it caused more issues than it was worth.
And that's ignoring the fact that it basically wasn't used.
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.
Change constructors to reflect that.
While doing so, also add a fallback argument to the cursor constructors,
so it is now possible to create cursors with fallback.
These are no longer used, instead we always covert to surface as
early as possible and drop the pixbuf.
This means we never store both the pixbuf and the surface at
for any longer time, which is wasteful. Also, its one step further
to drop GdkPixbufs from generic use in our APIs.
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.
Those should be interpreted by widget-local gestures, not guessed at a
high level with no notions of the specific context. Users will want
GtkGestureMultiPress to replace these events.
The emoji chooser gets disposed already, because it is attached
to the toplevel as a popover. Doing it again when the object data
is cleared is leading to a crash.
https://bugzilla.gnome.org/show_bug.cgi?id=787103
Since the move from button-press to gesture events, Shift-clicking did
not work to start a selection (from none) or truncate an existing one.
This was due to the code being copy-pasted around and some logic being
broken in the process. This makes both of those work as they should, by
shuffling it again so the end result is the same as before. Highlights:
(1) ::button-press if extending due to a single press would call
set_positions(tmp_pos, tmp_pos), which is what made the Shift+click to
create a selection work. That was lost. Add it back to make that work.
(2) ::button-press in the “Truncate current selection” branch would not
execute all the stuff around “extend_to_left”, as that was the else
case. So, set extend_selection = FALSE so we skip over that later on.
(3) BUT! This Truncate case never fired because it was in the else
branch of if (in_selection())! Of course, it must be in the true branch.
(4) The IM context was not reset if the Shift-click occurred within an
existing selection, only if it did not. In ::button-press this was the
first thing done if extending a selection, regardless. Make it so again.
https://bugzilla.gnome.org/show_bug.cgi?id=780750
Add an "Insert Emoji" item to the context menu in entries.
We also add a show-emoji-icon property, which when set to
TRUE, will add an icon that can be clicked to bring up
the Emoji chooser.
Our ::query-tooltip handler first checks whether the pointer is over any
of the icons, returning their tooltip if so, and if not chains up to
Widget::query-tooltip in order to show the text for the widget overall.
But ensure_has_tooltip(), which exists to update :has-tooltip based on
whether ::query-tooltip is needed, only set :has-tooltip to TRUE if any
icon had a tooltip, without caring whether the widget as a whole does.
That is asymmetrical and meant that if the Entry had a tooltip, but
subsequently all icons had their tooltips unset, :has-tooltip would be
set to FALSE, and hence the tooltip for the widget would become lost.
The fix is to set :has-tooltip to TRUE if the widget has a tooltip of
its own, and we only need to check the icons if that is not the case.
https://bugzilla.gnome.org/show_bug.cgi?id=785672
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.
