The compositing that is meant here is really specific to the
X11 Composite extension, and does not apply to Wayland.
This is very rarely used functionality anyway, and none of
the other backends support it.
Theoretically, we apply the shape mask client-side ourselves
with an ARGB32 pixmap and intersect it to get a union shape,
but I don't particularly care enough to write that code.
Realistic application code using bounding shapes in 2014 is
quite rare.
It seems that some backends implemented get_root_origin wrong
and returned the client window coordinates, not the frame window
coordinates. Since it's possible to implement generically for all
windows, let's do that instead of having a separate impl vfunc.
Lots of code, including dragging code in GtkWindow, use these
fields. Setting them to 0 causes lots of strange and weird bugs.
Use the same "hack" from query_device_state of just using
win_x / win_y for now. We'll convert this to the proper fake root
coordinate system used by get_root_coords in the next commit.
window->x / window->y are in "root window coordinates", e.g. relative
to the topmost toplevel. However, the coordinates in get_xdg_popup are
relative to the passed-in surface, so we need to do the reverse
translation here.
GtkWindow calls set_shadow_width then maps the window, meaning
that we never set the margin. Save it when we set and then set
it when we create the XDG surface.
Instead of destroying the surface in the backend if this is
unable to resize, let the core code do it, and do it properly.
Based on a patch by Benjamin Otte.
https://bugzilla.gnome.org/show_bug.cgi?id=725172
The code in GDK is incredibly broken and nobody is quite sure what's
right-side-up and what's upside down, but this breaks mutter-wayland
now, so let's remove it. It might leak, but we should probably do a
full restructuring of GDK drawing to fix it.
Like in other backends (except X) we can't resize cairo image surfaces
so let's sync the code here with what the other backends do.
This prevents the painting machinery above us to paint on the wrong
buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=724968
We can't destroy buffers if they're in-use by the compositor. Well,
technically we can, but that is considered undefined by Wayland and
mutter won't cope with it very well -- it simply kills the client.
To solve this, we need to delay the destroy operation until the
compositor tells us that it's released the buffer. To do this, hold
an extra ref on the cairo surface as long as the surface is in-use
by the compositor.
This prevents warnings like
(gtk3-demo:14948): Gdk-CRITICAL **: _gdk_frame_clock_thaw: assertion 'GDK_IS_FRAME_CLOCK (clock)' failed
(gtk3-demo:14948): Gdk-CRITICAL **: gdk_frame_clock_get_timings: assertion 'GDK_IS_FRAME_CLOCK (frame_clock)' failed
We need to do this, as the compositor might have already sent us a frame
event, in-flight, at the same time we destroy our window. In this case, we'll
receive the then-in-flight "done" event, and then warn as we try to look
up the frame clock on a destroyed window.
Add a GtkSetting for whether the desktop shell is showing the desktop
folder icons.
This is on by default because most desktop shells do show the icons on
the desktop. We already have a patch in gnome-settings-daemon to bind
this to the org.gnome.desktop.background show-desktop-icons GSettings
key which is off by default on GNOME.
https://bugzilla.gnome.org/show_bug.cgi?id=712302
If a motion event handler (or other handler running from the flush-events
phase of the frame clock) recursed the main loop then flushing wouldn't
complete until after the recursed main loop returned, and various aspects
of the state would get out of sync.
To fix this, change flushing of the event queue to simply mark events as
ready to flush, and let normal event delivery handle the rest.
https://bugzilla.gnome.org/show_bug.cgi?id=705176
Some symbols in the generated Wayland code were getting
decorated with WL_EXPORT, causing them to show up in the
libgdk exports. We don't want that.
https://bugzilla.gnome.org/show_bug.cgi?id=710141
We may get a NULL region passed to the backend, which means
'nothing is opaque'. In that case, don't crash, but pass
the information on to the compositor.
http://bugzilla.gnome.org/show_bug.cgi?id=709854
The surface is destroyed when we hide a window, but
gdk_window_set_opaque_region can be called before the window is
shown again, so we need to ensure the surface exits.
https://bugzilla.gnome.org/show_bug.cgi?id=707328
In the gnome-ostree model builddir contains all generated files not in
git (unless the build system explicitly overrides that). Here the
wayland-client-protocol.h was in $(builddir)/wayland, so we need to
find it using our already extant -I$(top_builddir)/gdk, rather than
relying on same-directory lookup.
Add the concept of shell capabilities, which allow the compositor
to advertise support for the app menu and the global menubar,
which are then propagated as GdkSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=707129
If the compositor supports the gtk-shell interface, use it to
export the application ID, dbus name and paths that can be used
for the application menu.
https://bugzilla.gnome.org/show_bug.cgi?id=707129
This reverts commit b2e666bf8f.
We need to keep cursor blinking configurable for accessibility
reasons.
https://bugzilla.gnome.org/show_bug.cgi?id=704134
Conflicts:
gdk/win32/gdkproperty-win32.c
gdk/x11/gdksettings.c
gtk/gtksettings.c
gtk/gtktextview.c
We want a surface so we can properly represent the scale factor for it.
All backends are converted to use surfaces and we reimplement the
backwards compat code in the generic code.
If we don't dispatch the pending events then we can enter poll with events
still requiring to be processed and which can then lead to us deadlocking
there.
Many parts of GTK+ assume that all windows have a cairo surface
assoicated with them. This change provides a logically 1x1 cairo surface
(respecting scale) for the root window.
https://bugzilla.gnome.org/show_bug.cgi?id=704554
If we bind to a global with an higher version than implemented, or
we make requests that appeared in a later version, we would get
fatal wayland errors.
https://bugzilla.gnome.org/show_bug.cgi?id=704104
With the introduction of the use of buffer scaling in ed4fcee4ct we
must request version 3 of the compositor as that is the version of the
surface interface that adds this new functionality. See the following
commit in weston:
commit a85118c1b85df6fbf8f896dca971a5b79a94da71
Author: Jason Ekstrand <jason@jlekstrand.net>
Date: Thu Jun 27 20:17:02 2013 -0500
Use wl_resource_create() for creating resources
This commit sets the version numbers for all added/created objects. The
wl_compositor.create_surface implementation was altered to create a surface
with the same version as the underlying wl_compositor. Since no other
"child interfaces" have version greater than 1, they were all hard-coded to
version 1.
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
https://bugzilla.gnome.org/show_bug.cgi?id=703817
Ths allows the retrieval of the wl_surface before the window is shown.
The surface is still created in the original places since the surface
and shell surface is destroyed when the surface is programmatically
hidden.
We've long had double precision mouse coordinates on wayland (e.g.
when rotating a window) but with the new scaling we even have it on
X (and, its also in Xinput2), so convert all the internal mouse/device
position getters to use doubles and add new accessors for the
public APIs that take doubles instead of ints.
We track the list of outputs each window is on, and set the
scale to the largest scale value of the outputs. Any time the scale
changes we also emit a configure event.
We bind to the newer version of the wl_output which supports
the new done and scale events, and if we use this to get the
scale for each monitor (defaulting to 1 if not supported).
If we got the release event for the last buffer then we're
fine with writing directly to the window surface, as wayland
will not be looing at it. This saves us from allocating
and copying more data.
Change the visibility handling to be the same way we do it in
GLib now. We pass -fvisibility=hidden to gcc and decorate public
functions with __attribute__((visibility("default"))).
This commit just does this for GDK, GTK+ will follow later.
When we call _gdk_wayland_display_load_cursor_theme during
the initial opening of the first display, gdk_setting_get does
not work yet, since it relies on the default display/screen
being set, which only happens after open returns.
Instead, just use the screen of this display.
There is currently no Wayland protocol for providing presentation
timestamps or hints about when drawing will be presented onscreen.
However, by assuming the straightforward algorithm used by the
DRM backend to Weston, we can reverse engineer the right values.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Combine duplicate code for creating and destroying surfaces.
To make the operation of the destroy() operation more obvious, the
destruction of the (fake) root window at display dispose time is
changed to not be a "foreign" destroy.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Use wl_surface_frame() to get notification when the compositor paints
a frame, and use this to throttle drawing to the compositor's refresh
cycle.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
Lazily creating the cairo surface that backs a window when we
first paint to it means that the call to
gdk_wayland_window_attach_image() in
gdk_wayland_window_process_updates_recurse() wasn't working the
first time a window was painted.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
When exposing an area, we were individually damaging and committing
each rectangle, *before* drawing. Surprisingly, this almost worked.
Order things right and only commit once.
https://bugzilla.gnome.org/show_bug.cgi?id=698864
This makes Wayland and X11 no longer call into XKB and libX11 for these
functions but use GDK's own copy of these functions, just like the
win32, quartz and broadway backends.
This is another step towards making GdkDisplayManager backend-agnostic.
Most of the backends profit from this as their atom implementations
where generic anyway - x11 needed that to allow multiple X displays and
broadway, quartz and wayland don't have the concept of displays.
The X11 backend still did things, so I only #if 0'd some code but did
not actually update anything.
In the case that the client is started directly by the compositor the
WAYLAND_SOCKET environment variable is set containing the fd to use that was
created by a socketpair.
This environment variable is consumed by a call to wl_display_connect so a
second call will not take advantage of it.
https://bugzilla.gnome.org/show_bug.cgi?id=697673
Under Wayland we don't know the absolute position of the device but there are
some API calls that expect to get an root window position. Previously we were
not assigning any value to these out parameters potentially leaving the values
undefined.
This change returns the current surface relative position of the device.
The is_modifier field is supposed to be set if the key
would act as a modifier, not if any modifiers are currently
active. To fix this, introduce a private
_gdk_wayland_keymap_key_is_modifier function.
At the same time, make the hardware_keycode field in key
events actually contain the hardware keycode, not a copy
of the keyval.
We always emit direction-changed when we get a new keymap, but
for state changes, we compare old and new direction and only
emit the signal when the direction actually changes.
We can get G_IO_HUP and G_IO_IN at the same time, if the compositor writes
data to us and then closes our connection. Make sure that we dispatch events
always if we have G_IO_IN and then error out if we get G_IO_HUP after that.
The cursor buffer is only non-null when a cursor is created from pixbuf,
so it is not necessary to keep track of whether to free this buffer on
finalize.
By keeping a pointer to the wl_cursor struct in GdkWaylandCursor, it is
no longer necessary to duplicate cursor data (width, height, hotspots,
etc.) between wl_cursor and GdkWaylandCursor.
Instead of maintaining the init refcount in regular event handlers that can
fire in case of hotplug or mode changes, use a dedicated sync callback
to wait for roundtrips.
The global_removal argument is the _name_ of the object.
We were comparing it to the _object id_ of the object.
To fix this, store the name at the time the object is bound.
We need to be a bit more careful when updating the screen
size - the code that was there would not do the right thing
if e.g. the width of one monitor was reduced.
We use a ref-count mechanism to track whether parts of the init sequence
still needs round trips to receive remaining initial state. Typically
we need a couple of roundtrips total to get the global list, then the
input and output configurations, but with the ref-count we avoid making
global assumptions like that.
https://bugzilla.gnome.org/show_bug.cgi?id=696340
Allow to set a GdkWindow to use a custom surface instead of a
wl_shell_surface. It allows to register the surface as a custom type
with some Wayland interface.
https://bugzilla.gnome.org/show_bug.cgi?id=695861
The GDK model for keymaps expects the keymap object to stay
around and emit a ::keys-changed signal. So, do that. This
should make layout changes work, but it remains untested since
weston does not support layout changes at runtime.
At the same time, plug a memory leak where GdkWaylandKeymap
forgot to free its xkb objects in finalize.
https://bugzilla.gnome.org/show_bug.cgi?id=696339
With this commit, we pick up xft settings from GSettings
as well. Among other things, this makes the Large Text
setting work. Still to do: pick up fontconfig changes without
having all clients use up inotify watches for all font
directories.
The check for GDK_CURSOR_IS_PIXMAP was ineffective, since _all_
cursors have this type, from the looks of it. Instead, store
buffer ownership information separately.
These might be candidates for a future settings interface; until
then, we use GSettings directly. Note again that we are careful
to avoid a dependency on GNOME schemas.
Key repeat under X is not affected by modifiers. And on some systems
(e.g my Thinkpad), NumLock is permanently on, rendering key repeat
nonfunctional. This commit changes the Wayland backend to do
key repeat regardless of modifiers.
http://bugzilla.gnome.org/show_bug.cgi?id=695497
Commit 0d9d808217 fixed the hotspot issue,
but commit f2cc52fddd then optimized away
cursor changes a little too aggressively. We always need to set the
cursor on enter. Make sure we clear the current cursor on leave so we
don't think it's already set on the next enter.
https://bugzilla.gnome.org/show_bug.cgi?id=695512
Until we figure out where we want to go with settings under
Wayland, this makes GTK+ applications a lot easier to deal
with under Wayland.
Note that we are careful to deal with the absence of schemas,
so this does not introduce a dependency on GNOME settings.
