This will be used to let the inspector and other users
pick insensitive widgets again. For now, update all
callers to pass no flags, preserving the current
behavior.
We were not paying enough attention to detail when updating
hover and focus state while generating crossing events. The
invariant that we need to preserve here is that when a widget
has focus or hover, its parent does too.
We were walking the parent chain here, which now
always needs to consider whether it should stop
at roots. Like this one should.
The symptom was that a label with a popup attached to
it would end up with an unintentional focus ring that
would not go away.
Instead of using a grab on a GtkInvisible, use
a hook in the GTK event propagation machinery to
get events.
The only downside of this approach is that we
lose the crosshair cursor. But we get rid of
the last use of GtkInvisible.
The event_widget is the widget that the surface belongs to which got
this event. The target widget is the one that will receive the event.
The previous terminology was confusing.
Do not call _gtk_widget_captured_event(), in propagate_event_down(), or
gtk_widget_event(), in propagate_event_up(), when the widget has been
unrealized.
The previous attempt at removing configure events entirely
was causing some dialogs not to show up under Wayland.
Presumably due to ordering issues with emitting ::size-change
out of the backend.
Instead, keep configure events in the event queue, but handle
them on the gdk side. This keeps the ordering intact, while
still removing configure events from the api. The dialogs
show up now.
... if none of the debug displays have any debug flags set. This way, we
can ignore the first parameter to e.g. GTK_DISPLAY_NOTE, which is
usually a call to gtk_widget_get_display.
Before this patch, gtk_widget_get_display was the slowest part of
gtk_widget_query_size_for_orientation.
We still need a drag gesture both on front (capture) and back (bubble)
to handle dragging from both the GtkWindow widget and chrome in the
headerbar. But we can do it through 2 drag gestures, instead of special
event handling code.
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*
This renames the GdkWindow class and related classes (impl, backend
subclasses) to surface. Additionally it renames related types:
GdkWindowAttr, GdkWindowPaint, GdkWindowWindowClass, GdkWindowType,
GdkWindowTypeHint, GdkWindowHints, GdkWindowState, GdkWindowEdge
This is an automatic conversion using the below commands:
git sed -f g GdkWindowWindowClass GdkSurfaceSurfaceClass
git sed -f g GdkWindow GdkSurface
git sed -f g "gdk_window\([ _\(\),;]\|$\)" "gdk_surface\1" # Avoid hitting gdk_windowing
git sed -f g "GDK_WINDOW\([ _\(]\|$\)" "GDK_SURFACE\1" # Avoid hitting GDK_WINDOWING
git sed "GDK_\([A-Z]*\)IS_WINDOW\([_ (]\|$\)" "GDK_\1IS_SURFACE\2"
git sed GDK_TYPE_WINDOW GDK_TYPE_SURFACE
git sed -f g GdkPointerWindowInfo GdkPointerSurfaceInfo
git sed -f g "BROADWAY_WINDOW" "BROADWAY_SURFACE"
git sed -f g "broadway_window" "broadway_surface"
git sed -f g "BroadwayWindow" "BroadwaySurface"
git sed -f g "WAYLAND_WINDOW" "WAYLAND_SURFACE"
git sed -f g "wayland_window" "wayland_surface"
git sed -f g "WaylandWindow" "WaylandSurface"
git sed -f g "X11_WINDOW" "X11_SURFACE"
git sed -f g "x11_window" "x11_surface"
git sed -f g "X11Window" "X11Surface"
git sed -f g "WIN32_WINDOW" "WIN32_SURFACE"
git sed -f g "win32_window" "win32_surface"
git sed -f g "Win32Window" "Win32Surface"
git sed -f g "QUARTZ_WINDOW" "QUARTZ_SURFACE"
git sed -f g "quartz_window" "quartz_surface"
git sed -f g "QuartzWindow" "QuartzSurface"
git checkout NEWS* po-properties
This way, we can support external libraries providing implementations of
GtkMediaFile.
We also add a media backend called 'nomedia' that can be enabled to not
compile any support for GtkMediaFile. This is useful when people want to
statically compile GTK into an application that does not use media.
For now, this option is the default.
We also support a new environment variable GTK_MEDIA that allows
selecting the implementation to use.
GTK_MEDIA=help can be used to get info about the available
implementations.
Add an extension point called gtk-im-module, which requires
the type GtkIMContext. Simplify the loading by using GIO
infrastructure. Drop the locale filtering for now, I don't
think it is really necessary nowadays.
Convert existing platform modules to gio modules.
Sill to do: Drop the conditional build machinery.
Either always include them, or never.
The code assigning the display to the debug_flags struct gets only
called when the default display changes, which never happens
when there already is one.
This makes it call the change callback in case a display is already
there.
The same fix was applied to gtk3 in !26 where calling gdk_init()
before gtk_init() would trigger this case. With gdk_init() gone
in master this is less likely to happen, but still possible
if gdk_display_open() is called before gtk_init().
See https://gitlab.gnome.org/GNOME/pygobject/issues/166
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.
GDK has a lock to mark critical sections inside the backends.
Additionally, code that would re-enter into the GTK main loop was
supposed to hold the lock.
Back in the Good Old Days™ this was guaranteed to kind of work only on
the X11 backend, and would cause a neat explosion on any other GDK
backend.
During GTK+ 3.x we deprecated the API to enter and leave the critical
sections, and now we can remove all the internal uses of the lock, since
external API that uses GTK+ 4.x won't be able to hold the GDK lock.
https://bugzilla.gnome.org/show_bug.cgi?id=793124
These functions are entirely trivial, their documentation
is much longer than their implementation, and it contains
an example that is annotated as "don't do this"...
event_widget is not modified anymore after the assignment from
handle_pointing event and we need the event's user data set for the
_gtk_window_check_handle_wm_event call.
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.
For a start, this makes gtk_main() work different from g_main_loop_run()
calls.
But most importantly, modern GDK does proper syncing itself and doesn't
need to rely on a catch-all to get it right.
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.
As we now refrain from sending the crossing events if there's an
implicit grab, those events must be sent on button release when
the implicit grab is broken.
Check the grab widget (both explicit and implicit) and check for a cursor
from the target widget up to this grab widget. If the target widget is
outside the grab widget, only the grab wigdet's cursor will be checked.
This also means that we have to ensure the cursor is updated on button
releases, as an implicit grab being deactivated must trigger a cursor
lookup from the target widget.
Unlike GTK+ grabs which are global to all/one device, the implicit grab
is per focus, which means each may have implicit grabs on different or
the same widget.
Implement target finding per-pointer/touchpoint through GtkPointerFocus and
_gtk_toplevel_pick(). Focus changes are handled through the emission of
crossing events between the old target and the new one.
gtk_init() removed its support for supporting arguments, so we ought to do
likewise for Windows, which actually defines items that call gtk_init()
the old way (and also get rid of argument support in those functions,
since the direction is to not support them).
https://bugzilla.gnome.org/show_bug.cgi?id=773299
We want to simplify our initialization code and remove all commandline
argument handling from it. The first stop for this is to reduce the
number of gtk_init variants we have.
This causes the snapshotting algorithm to dump all widget nodes into
their own container node. We then name that group accordingly (ie
"GtkSwitch<0xdeadbeef>") so you can easily see which node belongs where.
The feature is toggleable in the inspector's visual tab.
There's a few problems with it, becuse GtkSnapshot optimized container
nodes away if they are not needed, so we are losing some widgets...
Includes the ability to turn on updates in the inspector. Animations are
now run via a tick function which allows us to neatly overlay a
semi-transparent red rectangle and fade it out over time.
It also probably enables way more, but somebody with more UI neatness
than me needs to figure out what it eanbles first...
The update tracking code was ugly and using deprecated drawing APIs. It
was also in the wrong place.
So instead of trying to keep it working, I'll remove it. We need to find
a better way to put it and make it work there.
