We no longer emit this signal. You can use various gestures
and event controllers instead. If you need to catch raw
motion events, use the generic ::event signal.
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 signals are no longer used in GTK+ and have a (not quite
perfect yet) replacement with GtkEventControllerMotion.
If you need to catch the raw events, the generic ::event
signal still works.
This signal is unused in GTK+ and configure events are handled
internally by GtkWindow.
If you need to catch configure events, the generic ::event
signal still works.
This signal is not used in GTK+, and has a suitable
replacement with GtkGesture and its subclasses.
If you need to catch the raw touch events, the generic ::event
signal still works, too.
This signal is not used in GTK+, and has a suitable
replacement with GtkEventControllerScroll.
If you need to catch these events, the generic ::event
signal still works, too.
Both GtkWidget and GtkContainer had similar docs regarding hfw/wfh
geometry management. Move these just to GtkWidget. Also make sure the
examples compile, port everything from gtk_preferred_* to measure and
replace some occurrences of "container" with "widget" where container
was just used to refer to a widget with child widgets.
Now all events structs are private, it doesn't make as much sense
having GdkEventPrivate wrapping allocating events. This is a first
step towards removing it.
It won't stand true anymore that the GdkEventType argument is the
first field of the GdkEvent* structs. All callers have been updated
to use event->any.type instead.
Mark the following signals as deprecated:
event, event-after, button-press-event, button-release-event,
touch-event, scroll-event, motion-notify-event, enter-notify-event,
leave-notify-event, property-notify-event, selection-clear-event,
selection-request-event, selection-notify-event, selection-received,
selection-get, proximity-in-event, proximity-out-event. Most
of these have suitable replacements in event controllers and
gestures already. The selection-related signals will soon be
irrelevant when selection handling moves to GDK.
Set G_ENABLE_DIAGNOSTIC=1 to see deprecation
warnings for uses of these signals.
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.
When I rewrote that function to not use GdkDeviceManager,
I overlooked that the window filtering needs to apply
to the master pointer as well, as other code assumes
that _gtk_widget_get_device_window will return non-NULL
on the devices in the list. Fix this.
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.
We cannot fast-track picking by using gtk_widget_contains(). Child
widgets may extend their parent using ie negative margins.
This is not just a theoretical concern, this is what's happening right
now with GtkScale's sliders relative to the trough.
The problem is that we now iterate through all widgets, even when they
aren't anywhere near the mouse pointer. So essentially every pick
operation is now guaranteed O(N_WIDGETS) which used to be the worst case
that pretty much never happened.
Widgets can now set their favorite cursor using public API.
This is very necessary because all cursor-setting APIs are still
setting it on their GdkWindow, which by now is the toplevel - oops.
Consider the coordinates passed to gtk_widget_queue_draw_region to be
relative to @widget's origin, not its parent. That implies passing
priv->allocation or priv->clip to _queue_draw_region of a widget means
using its parent as @widget.
This fixes GtkScrolledWindow overshoot invalidation, which assumed the
coordinates to be widget-relative and not parent-relative.
And have a priv->display instead of a priv->screen.
Includes turning gtk_menu_set_screen() into gtk_menu_set_display(),
because that function just forwards to its window.
When a widget unparents its child widget manually in finalize, this can
lead to the parent-set signal being emitted for those child widgets. The
parent already has a ref_count of 0 though, so it can't be used in a
meaningful way. Specifically, emitting the signal will already try to
ref the parent which prints a critical.
Since GtkWidget already has a "parent" property, one can use its notify
signal instead to get notified when the parent widget changes.
Since focus can now be represented by more than one state,
just looking at the focus_child is no longer sufficient - we
may fail to propagate :focus(visible) if we do so. For now,
just remove the shortcut and always do the work.
The gtk_widget_get_display call in this if statement is showing up in
profiles. It ends up walking up the hierarchy to the toplevel to get its
GdkScreen, etc. so it is relatively costly. Avoid that call in most
cases by first checking if the RESIZE debugging is enabled for any of
the displays and only then checking if it is enabled for the widget's
display.
It was used to mark css properties that affect widgets with text, but it
caused unnecessary invalidations. E.g. 'color' was marked as
AFFECTS_TEXT but changing just the color of a label should not
automatically queue a resize, which is what the code in
gtk_widget_real_style_updated does.
Replace this flag with GTK_CSS_AFFECTS_TEXT_SIZE and
GTK_CSS_AFFECTS_TEXT_CLIP, which GtkWidget can use only if the widget
actually has text.
After a gesture first claims, and later rejects a touch sequence,
a press event will be propagated further along. However propagation
got messed up since we only emitted as far as the toplevel.
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.
This change is made for consistency, it doesn't make sense to expose
one-way propagation, as it can only break expectations from GTK+. This
function might be made entirely private in the future, but it still
makes sense to do this in one go for our internal usecases.
This will allow further cleanups and optimizations in capture/target/bubble
event delivery. For simplicity, ATM every widget will receive its own
GtkEventControllerLegacy, it could be desirable to add finer control over
this in the future, so widgets that fully use event controllers for input
management can do away without this legacy piece.
gtk_widget_draw_internal is now only used inside gtkwidget.c, so remove
the prototype from gtkwidgetprivate.h. And since all incovacations call
it with clip_to_size=TRUE, remove that parameter.
They are not usually yellow anymore, the previous advice about how to
style them was for pre-3.20 versions, and the immediate replacement (CSS
class .tooltip) does not seem ready for primetime.
https://bugzilla.gnome.org/show_bug.cgi?id=784421
Since gtk+ draws more than the widget and allocates more size to it than
it knows about, this flag doesn't work anymore. Removing it (or setting
it to TRUE for widgets that used to set it to FALSE) fixes drawing
invalidation when these widgets get allocated a new size.
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.
The reported minimum baseline is for the reported min height, but if the
css min-height is greater than that, we need to account for that fact
when saving the baseline.
Since the reported baseline is relative to the widget's origin, we also
need to add the top values for margin, border and padding to the
reported baseline.
