Currently, gtk_event_controller_scroll_handle_event() always returns
TRUE if it is handled, which stops the propagation of the event. If
there’s a single GtkEventControllerScroll in the widget hierarchy, that
means that no others will run, depending on the propagation phase. In
Nautilus, this can be observed when adding a scroll controller to the
GtkScrolledWindow (ctrl-scrolling controls the zoom level) - either the
scrolling or the zooming breaks.
Fixes https://gitlab.gnome.org/GNOME/gtk/issues/45
This is to go along with the newly introduced GdkDrop.
This commit includes the necessary updates to the X11, Wayland
and Broadway backends. Other backends have to be updated separately.
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*
Due to the recent changes introduced in glibc 2.27 "%OB" is the
correct format to obtain a month name as used in the calendar
header. The same rule has been working in BSD family (including
OS X) since 1990s. This change is simple but makes GTK+ 4.x require
glibc >= 2.27. If this requirement cannot be fulfilled then we must
cherry-pick the full commit cbf118c from gtk-3-22 branch.
Closes: #9
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
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.
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.
CID 1432024 (#1 of 1): Uninitialized scalar variable (UNINIT)
2. uninit_use_in_call: Using uninitialized value rect.x when calling
calendar_arrow_rectangle.
Add a default case to the switch which will bail out with
g_assert_not_reached(), which should reassure Coverity that the method
is always called with a valid value that is handled in the switch.
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.
We now rely on toplevels receiving and forwarding all the events
the windowing should be able to handle. Event masks are no longer a
way to determine whether an event is deliverable ot a widget.
Events will always be delivered in the three captured/target/bubbled
phases, widgets can now just attach GtkEventControllers and let those
handle the events.
Add a new ::measure vfunc similar to GtkCssGadget's that widget
implementations have to override instead of the old get_preferred_width,
get_preferred_height, get_preferred_width_for_height,
get_preferred_height_for_width and
get_preferred_height_and_baseline_for_width.
These days exposure happens only on the native windows (generally the
toplevel window) and is propagated down recursively. The expose event
is only useful for backwards compat, and in fact, for double buffered
widgets we totally ignore the event (and non-double buffering breaks
on wayland).
So, by not setting the mask we avoid emitting these events and then
later ignoring them.
We still keep it on eventbox, fixed and layout as these are used
in weird ways that want backwards compat.
GtkCalendar can have an invalid date — mostly at initialization. This
means that GDateTime construction may fail. We need to handle that case
gracefully, like the old code did.
This fixes the `notify` test suite, which started failing with:
/Notification/GtkCalendar:
GLib-CRITICAL **: g_date_time_get_day_of_week: assertion 'datetime != NULL' failed
inside the Continuous builder.
If the first of the month was falling on a Sunday, we would not
render any days of the previous month, and instead show two weeks
of the next month at the bottom. Improve this by showing one week
of each.
https://bugzilla.gnome.org/show_bug.cgi?id=301835
When allocated more than the requested height, GtkCalendar
was 'falling apart'. Not only was the main part rendered
at the far end of the allocation, clicking on days was
broken in this scenario.
Fix this by always placing the main part directly under
the header and day names.
https://bugzilla.gnome.org/show_bug.cgi?id=737670
It may be unusual, but handlers of day-selected may want to transfer
focus somewhere else, without getting it reset back right after by/to
the calendar. This makes popovers demo work on the calendar again, for
one...
When trying to drag, we currently the position of the first motion
event to determine where the drag came from. This might be alright
in the case of the old animation, but the data will be inaccurate
if the user has moved the pointer quite a bit since pressing the
cursor to start dragging. While we could monkey patch the GdkEvent
at the widget layer, this is unintuitive and strange.
Add a new API that takes a set of pointer coordinates describing
the origin of the drag. Additionally, adapt most widgets to use
it and use it with correct coordinates.
https://bugzilla.gnome.org/show_bug.cgi?id=705605
