If a surface is unmapped by the client while gdk is processing updates,
(for example Firefox un-mapping its window on Expose events), the
windowing backend resources might be lost (for example with Wayland)
which can cause a crash in end_paint().
Make sure we drop the cairo surfaces as well when hiding the surface,
that will avoid the crash in gdk_surface_impl_wayland_end_paint() when
trying to attach the staging cairo surface to a released wl_surface,
these will be recreated when needed when the surface becomes visible
again and there is no need to keep such buffers around for a surface
which is not visible anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=793062
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 is an automatic rename of various things related
to the window->surface rename.
Public symbols changed by this is:
GDK_MODE_WINDOW
gdk_device_get_window_at_position
gdk_device_get_window_at_position_double
gdk_device_get_last_event_window
gdk_display_get_monitor_at_window
gdk_drag_context_get_source_window
gdk_drag_context_get_dest_window
gdk_drag_context_get_drag_window
gdk_draw_context_get_window
gdk_drawing_context_get_window
gdk_gl_context_get_window
gdk_synthesize_window_state
gdk_surface_get_window_type
gdk_x11_display_set_window_scale
gsk_renderer_new_for_window
gsk_renderer_get_window
gtk_text_view_buffer_to_window_coords
gtk_tree_view_convert_widget_to_bin_window_coords
gtk_tree_view_convert_tree_to_bin_window_coords
The commands that generated this are:
git sed -f g "GDK window" "GDK surface"
git sed -f g window_impl surface_impl
(cd gdk; git sed -f g impl_window impl_surface)
git sed -f g WINDOW_IMPL SURFACE_IMPL
git sed -f g GDK_MODE_WINDOW GDK_MODE_SURFACE
git sed -f g gdk_draw_context_get_window gdk_draw_context_get_surface
git sed -f g gdk_drawing_context_get_window gdk_drawing_context_get_surface
git sed -f g gdk_gl_context_get_window gdk_gl_context_get_surface
git sed -f g gsk_renderer_get_window gsk_renderer_get_surface
git sed -f g gsk_renderer_new_for_window gsk_renderer_new_for_surface
(cd gdk; git sed -f g window_type surface_type)
git sed -f g gdk_surface_get_window_type gdk_surface_get_surface_type
git sed -f g window_at_position surface_at_position
git sed -f g event_window event_surface
git sed -f g window_coord surface_coord
git sed -f g window_state surface_state
git sed -f g window_cursor surface_cursor
git sed -f g window_scale surface_scale
git sed -f g window_events surface_events
git sed -f g monitor_at_window monitor_at_surface
git sed -f g window_under_pointer surface_under_pointer
(cd gdk; git sed -f g for_window for_surface)
git sed -f g window_anchor surface_anchor
git sed -f g WINDOW_IS_TOPLEVEL SURFACE_IS_TOPLEVEL
git sed -f g native_window native_surface
git sed -f g source_window source_surface
git sed -f g dest_window dest_surface
git sed -f g drag_window drag_surface
git sed -f g input_window input_surface
git checkout NEWS* po-properties po docs/reference/gtk/migrating-3to4.xml
Rename all *window.[ch] source files.
This is an automatic operation, done by the following commands:
for i in $(git ls-files gdk | grep window); do
git mv $i $(echo $i | sed s/window/surface/);
git sed -f g $(basename $i) $(basename $i | sed s/window/surface/) ;
done
git checkout NEWS* po-properties po
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
The internal known_globals hashtable is used to carry accounting for
interfaces that depend on others (as ordering is not guaranteed), extend
its usage so it also keeps track of unimplemented interfaces (here at
least).
The API call will then use this to allow querying the globals offered by
the compositor, it will be useful to determine whether we can use
text-input protocols or should fallback to other IMs.
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 GDK_POINTER_MOTION_HINT_MASK enumeration value is gone, but we're
still keeping around the "is_hint" field in GdkEventMotion, even though
every backend sets it to `false` — except for the core X11 device
manager.
GdkContentFormatsBuilder is currently not introspectable, as it does not
have a GType. We can turn it into a boxed type, but we need to implement
memory management for it.
The current gdk_content_formats_builder_free() function returns a newly
constructed value, so we cannot use it as a GBoxedFreeFunc; additionally
copying a GdkContentFormatsBuilder contents would make it a bit odd, as
you could get multiple identical GdkContentFormats out of the copies.
A simple approach is to model the GdkContentFormatsBuilder API to follow
the GBytes one: use reference counting for memory management, and have
a function to release a reference, return a GdkContentFormats, and reset
the GdkContentFormatsBuilder state.
For language bindings, we can provide a get_formats() function that
returns the GdkContentFormats instance and resets the builder instance,
leaving the reference count untouched.
For C convenience we can keep gdk_content_formats_builder_free(), and
make it a wrapper around gdk_content_formats_builder_get_formats(), with
the guarantee that it'll free the builder instance regardless of its
current reference count.
https://bugzilla.gnome.org/show_bug.cgi?id=793097https://blogs.gnome.org/otte/2018/02/03/builders/
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
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
BTN_STYLUS3 is defined by the Linux 4.15 kernel and is sent when the
third button on a stylus is pressed. At the moment, only Wacom's "Pro
Pen 3D" has three stylus buttons. Pressing this button triggers a button
8 event to be sent under X11, so we use the same mapping here.
https://bugzilla.gnome.org/show_bug.cgi?id=790033
We have a couple of Python 3.x scripts that parse C files, and since C
does not have any encoding, we need to force one ourselves, to avoid the
case when we're running the build in a non-UTF-8 locale.
https://bugzilla.gnome.org/show_bug.cgi?id=792497
This state flag is used in several places in GTK+, for example to
ignore RESIZE_INC hints if tiled. Setting it is also necessary for
backwards compatibility with applications that changed their behaviour
when tiled, such as GNOME Terminal and its MATE fork.
Signed-off-by: Simon McVittie <smcv@debian.org>
https://bugzilla.gnome.org/show_bug.cgi?id=789357
The query function for cursor sizes and capabilities
are not very interesting. At least, they are not used
in GTK+, and all backends but X11 just hardcode
made-up values anyway. So, lets drop them.
As far as possible, use per-display debug flags.
This will minimize the debug spew that we get from
the inspector if it is running on a separate display.
Instead, pass the source window to gdk_drag_begin().
Also make Wayland use this window instead of the one under the pointer
(though those 2 Windows are most likely the same anyway).
Without selections, drags can't have them either.
Also included is removing the selection from GtkSelectionData.
Includes a bunch of crude cleanups to Wayland code that no longer has to
care about selection atoms.
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.
Instead of just passing the GdkContentFormats, we are now passing the
GdkContentProvider to gdk_drag_begin().
This means that GDK itself can now query the data from the provider
directly instead of having to send selection events.
Use this to provide the private API gdk_drag_context_write() that allows
backends to pass an output stream that this data will be written to.
Implement this as the mechanism for providing drag data on Wayland.
And to make this all work, implement a content provider named
GtkDragContent that is implemented by reverting to the old DND
drag-data-get machinery inside GTK, so for widgets everything works just
like before.
Instead, pass the actions as part of gdk_drag_begin() and insist DND is
always managed.
A new side effect is that gdk_drag_begin() can now return %NULL.
This is the replacement for selection usage.
Backend implementations for X11 (missing support for backwards compat
formats like COMPOUND_TEXT) and Wayland are included.
GTK code should be adapted to use gdk_drop_read_*() functions instead
of gtk_drag_get_data().
In order to map a window with the correct initial parent-child
relationship when a modal dialog is set up to be a child of an imported
foreign window, the relationship must be set up before the window is
mapped.
In order to do this, if a window is not yet mapped, postpone the
relationship setup until when the window is eventually mapped.
https://bugzilla.gnome.org/show_bug.cgi?id=791062
Traditionally (and on most backends) there's a single master pointer driven
by all pointing devices. The notable exception is Wayland though, where
master pointing devices are created per capability in the case of
pointer/touch, and one for each drawing tablet.
This function call makes it easy to access all these.
https://bugzilla.gnome.org/show_bug.cgi?id=790920
I decided to put this in a custom subclass, because then I could keep
the whole gtk primary protocol self-contained.
The other option would have been reusing GdkWaylandClipboard, but that
didn't seem worth it, especially because that code needs to interact
with the DND machinery, while the primary doesn't.
The wayland backend currently never emits GDK_SELECTION_CLEAR events.
GtkClipboard uses this signal in order to clear the clipboard owner when
the selection is set to something outside the application.
This commit ensures the wayland backend emits GDK_SELECTION_CLEAR before
setting the clipboard owner to NULL, as this means we lost the
selection.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790031
Make sure the API reflects the idea that GdkContentFormats is a set
containing mime types. In particular, treat the object itself as a
plural - it's named content format`S' after all - and therefor use
the correct verb form.
Also make GdkContentFormats keep an array instead of a list, now that
it's immutable.
Instead, turn the functions into backend API:
gdk_broadway_display_add_selection_targets()
gdk_broadway_display_clear_selection_targets()
Remove the old per-backend functions, too.
We must reset the image delay when stopping the timeout,
otherwise the code setting it up thinks it is still running.
This fixes cursor animation only working for the very first
enter of a widget with an animated cursor, as seen in the
cursors example in gtk4-demo.
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.
The preferred api to create cursors is by name, and the
GdkCursorType enumeration can directly trace its ancestry
to the horrible X cursor font. So lets stop using it.
GTK+ now uses the gtk-xft-dpi setting directly.
Note: this commit only fixes the backends that
currently provide this setting. The win32 and
Quartz backends still need to be fixed.
Drop the screen argument from gdk_dnd_find_window_for_screen
and rename the function to gdk_dnd_find_window. The screen
argument does not add anything here since the drag context
is already tied to the display. Update all backends, and
update all callers.
According to the documentation, gdk_monitor_get_geometry() reports the
monitor geometry in ”application pixels”, not in ”device pixels”,
meaning that the actual device resolution needs to be scaled down by the
scale factor of the output.
x11 backend does that downscaling, whereas Wayland backend did not,
causing a discrepancy depending on the backend used.
https://bugzilla.gnome.org/show_bug.cgi?id=783995
If the compositor prefers server-side decorations and the client doesn't
customize the title bar, we disable client-side decorations and let the
compositor know. Otherwise, we continue to use client-side decorations.
Signed-off-by: Drew DeVault <sir@cmpwn.com>
https://bugzilla.gnome.org/show_bug.cgi?id=781909
Under Wayland, an xdg_surface.configure with size 0x0 means it's up to
the client to set its size.
When transitioning from maximized state to un-maximized, the Wayland
compositor will send such an 0x0 configure so that the client can
restore its original size.
However, the original size was already constrained, so re-applying
size constrains can lead to a smaller size when using size increments.
Avoid this caveat by not applying size constrains when we are restoring
the original size.
https://bugzilla.gnome.org/show_bug.cgi?id=777072
We were unnecessarily spewing warnings when blank cursors
were getting a new scale set. Standardize on "none" as the
name for blank cursors, and avoid the warning.
https://bugzilla.gnome.org/show_bug.cgi?id=775217
When building with G_DISABLE_ASSERT, the g_assert_not_reached()
statement won't do anything, and we're going to fall through, and the
compiler will emit a warning that we're not returning anything from a
function with a return value.
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.
-Wint-conversion is important because it checks casts from ints to
pointers.
-Wdiscarded-qualifiers is important to catch cases where we don't
strings when we should.
There is no guarantee that the gtk_surface won't be NULL,
and Wayland API does not safeguard against NULL, so we have
to do that ourselves here.
We were also mistakenly cheking for the surface version off
by one, fix that too by checking if the surface version is
equal or greater.
It may result in a protocol error on older mutters, as GTK+ will
invariably request a higher version than what's available. Make
GTK+ also accept v1 if it's all the compositor has got.
Otherwise, we can't negotiate the latest version with the
compositor, making the compositor use v1 of the protocol and
pretty much ignoring all the edge constraints work.
Instead of relying on special values of edge constraints, this
patch adds an internal-only gdk_window_supports_edge_constraints()
function that by default returns FALSE, and is implemented by
GdkWindowWayland and GdkWindowX11.
This way, we can properly detect server-side support for this
feature and adapt accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
Now that GTK windows have the ability to properly handle
per-edge tiling constraints, this patch extends GTK's
internal Wayland protocol to have a proper enum with the
relevant edge data.
Once this approach is validated, we can think of upstreaming
this work as an official Wayland protocol extension.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
We create various windows during the initial creation of display
objects, which causes some bootstrapping issues when we try to
find the default screen to get its root window. To work around this,
pass the display object into gdk_window_new.
This is not an API change, since gdk_window_new is no longer public API.
Interpret NULL as "root window" here - we only have one
screen nowadays, so there is no choice involved, and this
will let us avoid dealing with the root window in the
fontend code.
This adds support for the shortcut inhibitor protocol in gdk/wayland
backend.
A shortcut inhibitor request is issued from the gdk wayland backend for
both the older, deprecated API gdk_device_grab() and the new gdk seat
API gdk_seat_grab(), but only if the requested capability is for the
keyboard only.
https://bugzilla.gnome.org/show_bug.cgi?id=783343
Adds support for creating scroll events from Wayland tablet wheel events.
Even though no Wacom tablet puck has a smooth-scrolling wheel, both event
types need to be generated to make the upper layers happy.
https://bugzilla.gnome.org/show_bug.cgi?id=783716
If a tablet device is used to perform actions like window moving or resizing,
GTK must provide the correct implicit grab serial number over Wayland to Mutter
in order for the action to succeed. This commit adds tablet support to the
implicit serial getters.
https://bugzilla.gnome.org/show_bug.cgi?id=777333
If a bad behaving application tries to make the window/display beep too
often, throttle the beep requests so that we don't end up filling the
Wayland socket queue.
The throttle is set to 50 beeps per second, which far more beeps than
will ever make any sense from a user experience point of view, but will
avoid terminating due to an excessive amount of requests.
https://bugzilla.gnome.org/show_bug.cgi?id=778188
Under Wayland, when multiple keys are pressed and the user releases a
key, key repeat should continue unless the key released is the one
currently repeating.
In the case of:
- key1 press
- key1 repeat
- key2 press -> key1 repeat stopped
- key2 repeat
- key2 release
The behavior should be to cancel keyboard repeat, though key1 is still
held down. This is consistent with prior X11/XWayland behavior.
The following also must work:
- key1 press
- key2 press
- key2 release
- key2 press
- key1 release
- key2 should continue to repeat
The fix for bug #778019 should continue to work:
- key1 press
- key1 repeat
- key2 press -> key1 repeat stopped
- key1 release
- key2 should repeat
The choice to change the counter nkeys to the flag repeat_active
helps to solve the second test case.
https://bugzilla.gnome.org/show_bug.cgi?id=781285
begin_resize_drag() and begin_move_drag() check for xdg_surface being
not null, but those apply on xdg_toplevel so they should check for
xdg_toplevel being non-null instead.
https://bugzilla.gnome.org/show_bug.cgi?id=781945
When an event is received while a tooltip is showing, the GtkTooltip's
event handling code can end up calling gdk_window_set_transient_for()
from gtk_tooltip_set_last_window().
The Wayland GDK backend will try to automatically create a subsurface
in gdk_wayland_window_set_transient_for() but if the parent surface is
gone meanwhile, this will will cause a crash when trying to create a
subsurface from a parent with a null surface.
Checking for the parent is not sufficient, we ought to check for the
parent surface as well to avoid the crash.
https://bugzilla.gnome.org/show_bug.cgi?id=782283
Applications can specify the type hint as utility even on toplevel
windows.
When that toplevel is also marked as a transient for another window,
GDK Wayland backend would translate that as an xdg_popup which is not
appropriate.
While utility temp windows should remain mapped as subsurfaces (such as
the ones used by treeviews), regular windows should not translate as
neither a subsurface nor an xdg_popup.
https://bugzilla.gnome.org/show_bug.cgi?id=781945
There is no need to have every application log a warning when the
Wayland display server goes away, and we are using _exit instead of
exit elsewhere.
This is also what the X11 backend does (see gdk_x_io_error).
https://bugzilla.gnome.org/show_bug.cgi?id=745289
Aborting the application makes it look like an application bug, when
it is the expected thing to do when the Wayland display server goes
way. eg., when the user logs out. The log level is also demoted to
avoid a storm of warnings in the log from all applications whenever
this happens.
This is also what the X11 backend does (see gdk_x_io_error).
https://bugzilla.gnome.org/show_bug.cgi?id=783047
Use the gravity enum values when converting to gravity. It doesn't fix
anything, since the enum values were identical, but it makes a coverity
warning go away.
https://bugzilla.gnome.org/show_bug.cgi?id=780301
The common compiler and linker flags control, among other things, the
default visibility of symbols; without them, we leak symbols that ought
to be private.
We can build the name of the input and output files for the Wayland
protocols we use from the protocol name, stability, and version. This is
similar to how the autotools build does it, except much more clear and
without shelling out twice to sed just to resolve the Makefile rule.
gdkprivate-wayland.h includes generated wayland client protocol
headers and is included from gdkdisplaymanager.c, so we need to
generate those client protocol headers first also when building
main gdk itself.
This is how it's done in the autotools build. Also avoids problems
with multiple source files having the same name (gdkeventsource.c).
Also move broadway backend code into broadway subdir.
With Wayland, GDK_DEBUG=events would log key events but not explicitly
state whether the event is a key press or release, or if it's
originating from a key repeat.
Add some more verbosity to make sure these informations are logged on
key delivery when GDK_DEBUG is set.
https://bugzilla.gnome.org/show_bug.cgi?id=781767
It is generally a good idea to license individual files under the
same terms as the project license (in particular when the mismatch
boils down to having copied the wrong license header), so relicense
the code under the LGPL.
https://bugzilla.gnome.org/show_bug.cgi?id=781422
For some reason, we are seeing damage being NULL here.
While that should never be the case, crashing on it is
unkind and makes the Wayland experience unusable.
Make sure to clear up the number of keys being pressed on enter/leave so
that we don't end up with leftovers if a new window is mapped by a
keyboard shortcut.
https://bugzilla.gnome.org/show_bug.cgi?id=779374
The key repeat is stopped as soon as a key is pressed, so if the user
quickly presses a key while another is already pressed and being
repeated, key repeat gets cancelled:
- key1 press
- key1 repeat
- key2 press -> key1 repeat stopped
- key1 release
- key 2 is not repeated even though it's kept depressed
This is a different behavior from X11, which confuses migrating users.
To mimic the X11 behavior, keep track of the number of keys pressed
simultaneously and cancel key repeat only when none is pressed.
This way, if a user pressed a key while another one is being repeated,
the new key press can possibly be repeated as well.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=778019
When resizing an xdg_popup immediately after the initial mapping, there
is a race condition between the client and the compositor which is
processing the initial size given by the xdg_positioner, leading to the
xdg_popup to be eventually of the wrong size.
Only way to make sure the size is correct in that case is to hide and
show the window again. Considering this occurs before the initial
configure is processed, it should not be noticeable.
https://bugzilla.gnome.org/show_bug.cgi?id=772505
Clamping the anchor values as introduced in commit 9a5ffcd to fix bug
777176 breaks menu positioning.
By keeping the anchors rectangle size greater than zero, we end up
deducting some positive value from the original position, so there is no
need to clamp() actually, keeping the values positive is enough and
avoids the issue with menu positioning on the menubar.
An additional benefit is to make the code a lot simpler.
https://bugzilla.gnome.org/show_bug.cgi?id=778009
Currently hiding destroys the wl_surface and all related interfaces,
(including the gtk_surface1) so the next time the GdkWindow is mapped,
we don't bother to set the DBus properties. Toggle the check off so
it's actually issued again after the GdkWindow gets a gtk_surface1.
https://bugzilla.gnome.org/show_bug.cgi?id=773686
This is how windows are meant to be hidden as per the wayland
protocol, there's no need to destroy the xdg_surface and other
interfaces.
Also, rename gdk_wayland_window_hide_surface() to clear_surface(),
as that's what it does.
https://bugzilla.gnome.org/show_bug.cgi?id=773686
Elsewhere we already go through the keymap to get modifiers so we
should do the same here. In fact, this was relying on xkb modifier
mask values being bitwise compatible with GdkModifierType which isn't
necessarily true.
https://bugzilla.gnome.org/show_bug.cgi?id=770112
Gtk+ treats MOD1 as a synonym for Alt, and does not expect it to be
mapped around, so we should avoid adding GDK_META_MASK if MOD1 is
already included to avoid confusing gtk+ and applications that rely on
that behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=770112
When a subsurface is used as a parent of a popup, GDK needs to traverse
up to the transient-for as the next parent, to properly find the parent
used by the popup positioner. This is because the parent of a popup
must always either be an xdg_popup or an xdg_surface, but traversing
the "parent" (in GDK terms) upwards from a subsurface will end up on
the fake root window before we hit the actual parent (in Wayland terms).
https://bugzilla.gnome.org/show_bug.cgi?id=776225
Passing a rectangle with zero width or height to xdg_shell-v6
set_anchor_rect() will cause a protocol error and terminate the client,
as with gedit when pressing the Win key.
Reason for this is because the rectangle used to set the anchor comes
from gtk_text_layout_get_iter_location() which uses the pango layout
width/height, which can be empty if there is not character at the given
location.
Make sure we don't use 0 as width or height as an anchor rectangle to
avoid the protocol error, and compensate the logical position of the
given rectangle if the size is changed, so that the actual position
remains as expected by the client.
https://bugzilla.gnome.org/show_bug.cgi?id=777176
We're not currently using this, and dropping it allows us to loose
a bunch of code which leads us towards the goal of having GdkWindow
only for toplevels (and reparenting makes not sense for toplevels).
We can't really support these on e.g. wayland anyway, and we're trying
to get rid of subwindow at totally in the long term, so lets drop this.
It allows us to drop a lot of complexity.
For subsurfaces, the new state which includes the input shape is not
applied by the compositor if the subsurface is in effective synchronous
mode.
So we need to apply the input shape once parent surface is in effective
desynchronized mode, which is when it's committed, otherwise the input
shape may never be applied if the widget is not using being_paint() /
end_paint() to draw on its subsurface, like clutter does.
We do that only for empty input shape as those won't need update when
the subsurface is resized, for all other non-empty input shape, the
client still has to use begin_paint()/end_paint() for the input shape to
be applied.
https://bugzilla.gnome.org/show_bug.cgi?id=774534
I read the code as if (use_gl) instead of if (!use_gl) and commented it
out in bddfd7bb41. That broke drawing on
Wayland without OpenGL completely.
Whoops.
Now it's back.
This is a way to query the damaged area of the backbuffer.
The GL renderer uses this to compute the extents of that damage region
(computed via buffer age) and use them to minimize the area to redraw.
This changes the semantics of GL rendering to "When calling
gdk_window_begin_frame() with a GL context, the area by
gdk_gl_context_get_damage() needs to be redrawn and every other pixel of
the backbuffer is guaranteed to be correct.
After gdk_window_end_frame() on a GL-drawn window, the whole backbuffer
must be correct.
We can always glXBufferSwap() now because of this.
... instead of a gl context.
This requires some refactoring in the way we mark the shared context as
drawing: We now call begin_frame/end_frame() on it and ignore the call
on the main context.
Unfortunately we need to do this check in all vfuncs, which sucks. But I
haven't found a better way.
This way, we can query the GL context's state via
gdk_gl_context_is_drawing().
Use this function to make GL contexts as attached and grant them access
to the front/backbuffer for rendering.
All of this is still unused because GL drawing is still disabled.
No visible changes as GL rendering is disabled at the moment.
What was done:
1. Move window->invalidate_for_new_frame to glcontext->begin_frame
This moves the code to where it is used (the GLContext) and prepares it
for being called where it is used when actually beginning to draw the
frame.
2. Get rid of buffer-age usage
We want to let the application render directly to the backbuffer.
Because of that, we cannot make any assumptions about the contents the
application renders outside the clip area.
In particular GskGLRenderer renders random stuff there but not actual
contents.
3. Pass the actual GL context
Previously, we passed the shared context to end_frame, now we pass the
actual GL context that the application uses for rendering. This is so
that the vfuncs could prepare the actual contexts for rendering (they
don't currently).
4. Simplify the code
The previous code set up the final drawing method in begin_frame.
Instead, we now just ensure the clip area is something we can render
and decide on the actual method in end_frame.
This is both more robust (we can change the clip area in between if we
want to) and less code.
Now that subsurfaces can be created as child of another GdkWindow (and
not just the root window), they must be placed according to the location
of their parent, i.e. the abs_x/abs_y must be updated and taken int
account when placing and moving subsurfaces under Wayland.
https://bugzilla.gnome.org/show_bug.cgi?id=774917
This can be triggered on workspace switches, and on hidpi results in
the scale factor being reset to 1 while the window is not in the
current workspace.
https://bugzilla.gnome.org/show_bug.cgi?id=774476
For wayland clients, the startup notification ID is currently only set
from the DESKTOP_STARTUP_ID environment variable. As that variable is
only set for clients launched via exec(), startup completion is not
indicated correctly for DBus-activated applications unless an explicit
ID is specified - usually that is not the case, as the default handling
uses gdk_notify_startup_complete().
To address this, we need API to set the startup notification ID from GTK
as we have on X11.
https://bugzilla.gnome.org/show_bug.cgi?id=768531
gdk_wayland_window_attach_image() is normally called from
gdk_window_end_paint() to notify the compositor of newly staged drawing.
If any of the drawing code inadvertently dispatches the wayland event
loop (for instance with a gdk_flush() call), then it's possible that by
the time gdk_window_end_paint() is called, the staged drawing is already
destroyed.
This commit bypasses the attach_image call in scenarios where the staged
drawing is prematurely dropped.
https://bugzilla.gnome.org/show_bug.cgi?id=773274
Switch code to use gdk_display_is_composited() instead.
The new code also doesn't use a vfunc to query the property but rather
requires the backend to call set_composited()/set_rgba() to change the
value.
