On wayland, such axes are per-tool, we must update device capabilities
on the fly as new tools enter proximity, first the slave device so
it matches the current tool, and then the master device so it looks
the same than the current slave device.
Only the management of tablets and tools is added so far. No tablet events
are yet interpreted.
As it's been the tradition in GTK+, erasers are split into their own device,
whereas the rest of the tools are meant to be routed through the
GDK_SOURCE_PEN device. Both pen/eraser devices are slaves to a master
pointer device, separate to wl_pointer's. This is so each tablet can
maintain its own cursor/positioning accounting.
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
This will enable multiple "pointers" to have separate data here.
Will come out useful when adding support for tablets, as they
will have a separate cursor for all purposes.
Because there are multiple different types of styluses that can be used with
tablets, we have to have some sort of identifier for them attached to the
GdkDeviceTool, especially since knowing the actual tool type for a GdkDeviceTool
is necessary for matching up a GdkDeviceTool with it's appropriate
GdkInputSource in Wayland (eg. matching up a GdkDeviceTool eraser with the
GDK_SOURCE_ERASER GdkInputSource of a wayland tablet).
Signed-off-by: Stephen Chandler Paul <thatslyude@gmail.com>
On the devices and backends that support it, this signal will be emitted
on slave/floating devices whenever the tool they are interacting with
changes. These notifications may also work as a sort of proximity events,
as the tool will be unset when the pen moves too far.
For backends, gdk_device_update_tool() has been included, all that should
be done on their side is just calling this whenever any tool might have
changed.
GdkDeviceTool is an opaque object that can be used to identify a given
tool (eg. pens on tablets) during the app/device lifetime. Tools are only
set on non-master devices, and are owned by these.
The accounting functions are made private, the only public call on
GdkDeviceTool so far is gdk_device_tool_get_serial(), useful to identify
the tool across runs.
This fixes a bug that was introduced by db1b24233e.
The reason why 0:0 coordinates were passed was that SWP_NOREPOSITION was
misinterpreted as SWP_NOMOVE. That is not the case - SWP_NOREPOSITION
prevents owner Z-order change, not the window position change.
gnome-control-center is calling gtk_window_resize() on configure-event
signals which leads to a busy loop.
Avoids such a busy loop by not re-configuring a window with the same
size, unless this is coming from and xdg-shell configure.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764374
When we invalidate a window we need to also invalidate all child windows
that are native (non-native are automatically invalidated as we track
invalidation once per native window only). This was done in a pretty
inefficient way, recursing over the entire tree.
This makes the invalidation much faster by only looking at the native
children of the native window we're in, filtering out those that
are not a descendant of the client side window we're interested in.
Given that there are very few native subwindows this is much faster.
Currently only one kind of decorative window is in use - the shape
indicator that is shown when snapping windows to the edge of the screen.
When normal toplevel class is used, its window procedure expects certain
motions from GDK (passing user data to CreateWindowEx(), registering
handle in a hash map etc), and might crash if that is not done.
Dumb window doesn't require anything, it can just be.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
Now halfleft/halfright/fullup snaps do hug screen edges as intended.
Documents AeroSnap behaviour when snapped windows are drag-resized
(currently this implementation handles this in a very simplistic way).
Don't believe GTK when it tells us that window shadow is 0, preserve
previous values (but do remember that GTK wants no shadow, in case
we need that).
Fixes a couple of bugs in unsnapping (check offset against the half
of the window; don't put pointer in the middle of the window vertically
if it still fits in the top half).
https://bugzilla.gnome.org/show_bug.cgi?id=763013
Implements gdk_win32_window_set_shadow_width().
Uses shadow width/height to adjust max tracking size, allowing
windows to be drag-resized to cover the whole desktop.
Also uses SM_C*VIRTUALSCREEN instead of SM_C*MAXTRACK.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
Indicator is a bare layered click-through native window,
painted completely by GDK, including animation.
This commit also isolates some of the more spam-ish debug logging
under ifdef.
This commit also changes the system metric used for maximal window
height for the snapping purposes. Turns out, SM_CYMAXTRACK is way
too large, use SM_CYVIRTUALSCREEN instead.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
This implements the part of AeroSnap that snaps windows when you
drag them (while moving or resizing) to the edge of the screen.
It also fixes drag behaviour for snapped and maximized windows
(if such windows are dragged, first they must be unmaximized/unsnapped).
Note that this code does not take into account the shadow width, and
because of that the under-pointer-position-preserving window moves
might not look as such for maximized windows, which lack the shadow
when maximized, but do have the shadow when unmaximized.
This commit also doesn't cover some corner-cases the same way AeroSnap does.
Also, the snapping indicator (which is supposed to be a window shape that
shows where the window will be if the drag op is stopped at its current
point) is not being drawn, all routines responsible for its creation,
moving and drawing are stubs.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
This is what AeroSnap does. If a window is being unsnapped on
a new monitor, check if the work area is large enough for the
window to fit in its normal size. If the window fits, just
reposition it so that the ratio of
left-window-edge-to-screen-edge / right-window-edge-to-screen-edge
remains the same, without scaling the window.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
It works exactly like AeroSnap.
Except for shift+win+left/right, which is left for AeroSnap
to handle (AeroSnap takes action before we get the message,
so there's no way for us to override it).
The only thing that doesn't work is shift+win+left/right on
a maximized window, for reasons unknown at the moment.
This only implements winkey+stuff behaviour of AeroSnap,
not the drag-to-the-edge-and-something-funny-happens one.
https://bugzilla.gnome.org/show_bug.cgi?id=763013
If a layered window was hidden and is made visible, erase its
contents before showing it. GDK will schedule a redraw, but until
then we generally don't want to show old contents.
https://bugzilla.gnome.org/show_bug.cgi?id=763783
This is achieved by sending undocumented message WM_SYSMENU
to the window.
Before doing that, the window is given WS_SYSMENU style
(to enable window menu) and some combination of
WS_MAXIMIZEBOX (for "Mazimize" item)
WS_MINIMIZEBOX (for "Minimize" item)
WS_SIZEBOX (for "Size" item)
depending on which operations are currently permissible.
WM_SYSMENU is processed by DefWindowProc(), which results
in showing the window menu. We remove extra styles
at the first opportunity (WM_INITMENU message), as they
alter the way our window is rendered.
https://bugzilla.gnome.org/show_bug.cgi?id=763851
These functions are supposed to return the numbers of consecutive
1 bits in each components mask as precision. However, due to a
copy-paste mistake when this code was moved around in
commit 70d689cddd, the precision
was always reported as zero. This affects only a few applications
that directly set window background on X11 windows, such as emacs.
https://bugzilla.gnome.org/show_bug.cgi?id=764210
Delay as long as possible before calling OpenClipboard(),
call CloseClipboard() as quickly as possible after that.
Don't call OpenClipboard() when we don't need to (for example,
we don't need to open clipboard to call GetClipboardOwner()).
Also, print out actual W32 error code in some cases where it
was not printed before.
https://bugzilla.gnome.org/show_bug.cgi?id=763907
Error codes can be easily looked up in an error code list
and/or googled up. Error messages, while descriptive, often
describe the wrong thing, and the messages themselves are not
part of the documentation of a function, unlike error codes.
It would be preferable to have the code, or both.
https://bugzilla.gnome.org/show_bug.cgi?id=763913
gtk+ currently depends on the scaling factor and the cairo device scale
of both the backend surfaces and image surfaces to be equal.
Until now we didn't apply a cairo device scale at all and depended on the
automatic scaling of CGContexts. This works when drawing with cairo but
fails in case of image surfaces, which get requested at a too small size.
To make the quartz backend behave more like the X11 one, set the cairo device
scale on the surface in gdk_quartz_ref_cairo_surface(). As this conflicts
with the default scaling done by CGContext (we would get double scaling)
undo the CGContext scaling using CGContextScaleCTM().
This patch is based on the following patches by Brion Vibber:
https://bugzilla.gnome.org/show_bug.cgi?id=740199#c4https://bugs.freedesktop.org/show_bug.cgi?id=69796#c4https://bugzilla.gnome.org/show_bug.cgi?id=763779
If the configure-event gives us the same size as we had before,
which is common for animation resizes, then try to keep the
existing buffer around. This saves us a memfd_create() syscall
on every frame.
https://bugzilla.gnome.org/show_bug.cgi?id=763350
Now that GdkWaylandDeviceData is gone, the functions prefixed
"gdk_wayland_device_" and taking a GdkWaylandSeat as first
parameter feel out of place. Renaming those makes it more obvious
that it's seat functions.
https://bugzilla.gnome.org/show_bug.cgi?id=763859
It's the same than gdk_device_get_seat() nowadays. Also, rename the
usages of GdkWaylandDeviceData to GdkWaylandSeat in the functions
affected by the removal.
https://bugzilla.gnome.org/show_bug.cgi?id=763859
We were just relying on the drag context finalize() to destroy
the window. But with garbage-collected bindings, that might
not happen as soon as we like, so explicitly hide the window
when the drag ends successfully.
https://bugzilla.gnome.org/show_bug.cgi?id=763659
Using UpdateLayeredWindow() on iconic windows brings them *back* from
their iconic (minimized) state. That is bad.
As a precaution, also don't use SetWindowPos() on iconic windows.
This means that iconic windows can't be moved. That is fixable
by using SetWindowPlacement(), but there is no pressing need to do so,
as there are very few cases when windows need to be moved while minimized.
https://bugzilla.gnome.org/show_bug.cgi?id=763835
Two errors here:
1) A typo in splashscreen rectangle calculation - sets right twice
instead of setting top
2) Centering for dialogs is off because it doesn't convert
GDK virtual desktop coordinates to Windows WM virtual desktop
coordinates by adding _gdk_offset_*
https://bugzilla.gnome.org/show_bug.cgi?id=763628
The way gdk_drag_status() may be called multiple times during the
processing of drag and drop events throughout the widget hierarchy
brings some superfluous messaging going in, esp. when it's the last
request the one we want to honor, yet we emit messaging requests on
all.
This is barely appreciable in the X11 backend, but due to the design
of the wayland protocol, quick series of changes like this it have
some self-amplificating consequences which may end up flooding the
connection.
We can delegate this to a late "commit" call, performed within GDK
event management. This way gdk_drag_status() calls may be cached
and only result in windowing messaging once per ::drag-motion or
::drag-data-received event. Emitting the final status will also
avoid spurious action changes on the compositor and the other peer.
https://bugzilla.gnome.org/show_bug.cgi?id=763298
This code:
> gdk_window_get_root_origin (window, &x, &y);
> x -= root_x;
> y -= root_y;
> pointer_window = gdk_device_get_window_at_position (device, &x, &y);
was meant to find the child gdk window at coordinates root_x and root_y.
These 4 lines had 2 bugs:
1) x = x - root_x (same for y) is wrong, it should be x = root_x - x
2) gdk_device_get_window_at_position() does not give you the window
at position x and y. It gives you the window under the device
(mouse pointer) and the returns the device coordinates in x and y.
https://bugzilla.gnome.org/show_bug.cgi?id=763533
MacOS provides the NSEventTypeMagnify which is very similar to the
Gtk ZOOM gesture and NSEventTypeRotate which is very similar to the
Gtk Rotate gesture. Those two event sequences are translated to a
sequence of GDK_TOUCHPAD_PINCH events. This sequence is then detected
in the upper gtk layers as Gtk Zoom/Rotate Gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=760276
When compressing window state events, we didn't free the discarded
event after removing it from the queue, causing us to leak it. This
commit makes sure to free the discarded event after unqueuing it.
https://bugzilla.gnome.org/show_bug.cgi?id=762468
A gtk_surface.present request was added to gtk_surface which takes
timestamp from some input event, and uses that timestamp to figure out
whether the window can be presented or not. If we don't have a
timestamp, we should just give up instead of making up our own,
otherwise we might steal someones focus.
https://bugzilla.gnome.org/show_bug.cgi?id=763037
The gtk_shell protocol used some half baked unstable protocol semantics
that worked by only allowing binding the exact version of the
interface. This hack is a bit too confusing and it makes it impossible
to do any compatible changes without breaking things.
So, instead rename it to include a number in the interface names. This
way we can add requests and events without causing compatibility issues,
and we can later remove requests and events by bumping the number in
the interface names.
https://bugzilla.gnome.org/show_bug.cgi?id=763001
This request actually means nothing to the upper GDK layers,
we used to preempt a GDK_SELECTION_REQUEST event, but this is too
eager, and not like things work in X11.
Originally in wayland, this event may be used for feedback purposes.
We however don't perform any mimetype-based feedback, so we can
safely ignored.
This makes data_source_send() the only place where we actually
trigger GDK_SELECTION_REQUEST, this one is conceptually the same
than the X11 selection request event.
The virtual host assigns the name of the mouse device to
"VirtualBox USB Tablet" in VirtualBox and we'd use that device as mouse.
If not, GtkTooltip is not enabled.
https://bugzilla.gnome.org/show_bug.cgi?id=763017
Other portions of the GDK-Win32 backend make use of this function as
layered windows need to be disabled for GL windows and possibly other
parts, so make this function a private function that is available within
the backend.
https://bugzilla.gnome.org/show_bug.cgi?id=763285
Layered windows and GL do not work well together, so disable layered
windows when initiating a GdkGLContext, so that GtkGLArea programs can run
properly.
Also based on patch by LRN to address the issue.
https://bugzilla.gnome.org/show_bug.cgi?id=763080
The default value for the double-click key in the
org.gnome.settings-daemon.peripherals.mouse schema is 400.
Use the same value as the declared default for the
gtk-double-click-time GTK+ setting, to avoid pointless
differences in corner cases.
https://bugzilla.gnome.org/show_bug.cgi?id=720950
This removes the event_poll_fd global variable and the (ab)use of
get_default_display. It is also more consistent with other backends.
Also store display
Use gdk_window_get_effective_toplevel when looking for
a suitable transient parent, to skip over offscreen windows
that we might encounter in the window tree. This fixes
a crash in glade.
https://bugzilla.gnome.org/show_bug.cgi?id=763110
Fixes bug 763023: in certain circumstances, XRRGetOutputInfo will return
a null pointer. This commit adds a check to detect and handle this
return value.
Otherwise WM-dependent default cursor is used, which does not
match our theme. Worse, later GDK will realize that we have
our own left_ptr cursor and will apply it after all, making
the discrepancy even more noticeable.
https://bugzilla.gnome.org/show_bug.cgi?id=762902
* Explicitly grab the device, setting appropriate cursor on it.
* Fix gdk_device_virtual_set_window_cursor() to just set the
cursor, without trying to check that mouse is over the given
window. Also prevent it from immediately resetting cursor.
* Alse take into account things that happen in other parts of
GDK - don't look for replacement cursor, GDK already did that,
and don't create a default arrow cursor instead of NULL,
GDK-W32 already did that up the stack as well.
Warn about inappropriate cursor == NULL argument instead.
https://bugzilla.gnome.org/show_bug.cgi?id=762711
Toplevels are now true layered windows that are moved,
resized and repainted via UpdateLayeredWindow() API call.
This achieves transparency without any extra effort,
and prevents window size and window contents desychronization
(bug 761629).
This also changes the way CSD windows are detected. We now
use window decorations to detect CSDiness of a window,
and to decide whether a window should be layered (CSD windows should
be) or not.
Decorations are now stored in the window implementation,
not as a quark-based property of the window-as-gobject.
https://bugzilla.gnome.org/show_bug.cgi?id=748872
Normally works only on CSD windows, non-CSD windows continue
to use WM modal loop for drag-resizing and drag-moving. However,
if it is activated on non-CSD windows, it does work.
Has the advantage of being completely immune to AeroSnap.
AeroSnap only worked partially on CSD windows, with the only part
that worked being "don't let users drag window titlebar outside of
the desktop". Now AeroSnap doesn't work on windows moved by
this code at all, which is good, since they currently don't work
well with it due to the way shadows are drawn.
It's possible to also re-implement AeroSnap (or something similar),
but that is a story for another commit.
This code was originally intended to fix the problem of window
size and window contents desynchronization, but failed to achieve
that result in the end. Nevertheless, it serves as a foundation for
other changes to the way window resizing works.
https://bugzilla.gnome.org/show_bug.cgi?id=761629
key repeat is handled client side, which means stalls in the compositor
dispatching key release events can lead to fictious repeat events.
This commit ties key repeat to a server roundtrip to ensure the client
and server are in sync.
https://bugzilla.gnome.org/show_bug.cgi?id=757942
We don't need the key repeat rate or anything like that when
handling key up events, so do key up events first before querying
for that information.
https://bugzilla.gnome.org/show_bug.cgi?id=757942
deliver_key_event is sometimes called from a timeout handler and
sometimes called directly. We currently erroneously return TRUE
(G_SOURCE_CONTINUE) in the case where it's called directly, but to
no ill effect, since we ignore that return value. In the future,
we're going to need to call it directly in other parts of the code
where the return value would be relevant and handling TRUE, would
require adding redundant code.
Instead, this commit just changes the code to always reset the timer
manually, and never rely on glib's ability to automatically reset
the timer by returning TRUE. This makes the code smaller, too, since
there's less special casing required.
https://bugzilla.gnome.org/show_bug.cgi?id=757942
If the parent of a transient is not a native Wayland window (e.g.
offscreen window), the transient loop check will crash.
Check for the actual type in the transient loop check and do not assume
the parent is necessarily Wayland native.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=761156
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
If there are already a window state event for a given window queued
when the window state is changed, drop that event and queue a new event
with a changed_mask based on the state before last event that was queue
without compression.
https://bugzilla.gnome.org/show_bug.cgi?id=762468
According to xdg_shell, an xdg_surface.configure with size 0x0 should
be interpreted as that it is up to the client to set a size.
When transitioning from maximize or fullscreen state, this means the
client should configure its size back to what it was before being
maximize or fullscreen.
This problem currently only occurs on weston because weston sends a
configure with size 0x0 when transitioning back from maximize or
fullscreen.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762713
gdk_display_list_devices is deprecated and all the backends
implement the same fallback by delegating to the device manager
and caching the list (caching it is needed since the method does
not transfer ownership of the container).
The compat code can be shared among all backends and we can
initialize the list lazily only in the case someone calls the
deprecated method.
https://bugzilla.gnome.org/show_bug.cgi?id=762891
The staging buffer gets allocated any time begin_paint is called
on the window. This can happen even with an empty paint region,
so we should cope with that situation. At the moment we crash
trying to post a runtime warning.
https://bugzilla.gnome.org/show_bug.cgi?id=762755
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
The g_print documentation explicitly says not to do this, since
g_print is meant to be redirected by applications. Instead use
g_message for logging that can be triggered via GTK_DEBUG.
gdk_display_add_seat was prepending new seats to the list, which
was effectively making the added seat the new default. Since that
is probably not intended, append to the list.
The gdkprivate-wayland.h header file is included from the top-level gdk
directory; this means that all included files referenced in the header
must be relative to the `gdk` directory, otherwise the build will fail
when the build directory is not equal to the source directory.
This commit fixes a build failure under continuous:
In file included from ../../gdk/gdkdisplaymanager.c:60:0:
../../gdk/wayland/gdkprivate-wayland.h:40:51: fatal error:
gtk-primary-selection-client-protocol.h: No such file or directory
#include "gtk-primary-selection-client-protocol.h"
^
compilation terminated.
Makefile:1155: recipe for target 'libgdk_3_la-gdkdisplaymanager.lo' failed
make[4]: *** [libgdk_3_la-gdkdisplaymanager.lo] Error 1
Except for the init function, all the visual related code is made
of gdkscreen vfuncs, so let's move it to gdkscreen-win32. This way
we avoid keeping other static variables and instead store the info
inside the screen struct.
I am testing GTK+ master against mutter 3.19.90, so I'd
like GTK+ to survive even when the compositor does not
support the primary selection interface.
Implement it using the internal copy of the protocol. Otherwise,
we just deal with it the same than clipboard selection, just mapping
it to the PRIMARY atom instead of the CLIPBOARD one.
https://bugzilla.gnome.org/show_bug.cgi?id=762561
This protocol is an internal mirror of the primary selection drafts
being proposed for wayland-protocols. No changes besides prefix/suffix
changes.
https://bugzilla.gnome.org/show_bug.cgi?id=762561
1f74f12d9 rendered entry of keypad decimal mark unuseable for
several national keyboard layouts, this commit amends that, at
least for W32, and makes GTK+ behave more or less the same way
W32 behaves.
The patch works like this:
- When typing the first character at the keyboard or when switching
keyboard layouts, the decimal mark character will be cached in the
static variable "decimal_mark" within gdkkeys-win32.c
- in case of WIN32, gdk_keyval_to_unicode() asks gdkkeys-win32.c for the
current decimal_mark when converting GDK_KEY_KP_Decimal.
https://bugzilla.gnome.org/show_bug.cgi?id=756751
1) MSDN says that the coordinates of the maximized window
must be specified as if the window was on the primary display,
even if nearest display where it ends up is not the primary display.
So instead of using nearest display work area verbatim,
use it only to account for taskbar size, while using
primary display top-left corner (0:0) as the reference point.
2) MSDN says that max tracking size is a system property, we
should just call GetSystemMetrics() and use that.
https://bugzilla.gnome.org/show_bug.cgi?id=762629
Sigh.
Now that we've neutered the QEMU USB tablet, I'm finding that
spice is doing just the same nonsense. It has a fake "spice vdagent
tablet". Blacklist that as well.
Remember the last source device we're generating multiple clicks for,
just so we can bail out if the device changed. That will just reset
the counting.
https://bugzilla.gnome.org/show_bug.cgi?id=723659
The significant change here is a memory leak fix in init_xrandr15.
The rest of the changes makes init_xrandr13 and init_xrandr15 more
parallel, and simplifies init_multihead.
Add a gtk_shell.set_startup_id request, so the application can communicate
to the compositor the startup id that it received through the
DESKTOP_STARTUP_ID envvar, or other means.
When running with a Wayland compositor which doesn't support the
xdg_shell interface, gtk+ will segfault while trying to access the
corresponding wl proxy.
Check for xdg_shell support and do not use Wayland if not present, so
that it can fallback to X11, hoping that Xwayland is usable.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762258
There is no point in attaching and then committing the same buffer if
there was no damage. This will also make us do less unnecessary backfill
read backs, for the cases where we paint with an empty paint region.
https://bugzilla.gnome.org/show_bug.cgi?id=762120
If a after-paint was scheduled but nothing was painted, for example when
the it was scheduled by a subsurface wanting to update its position,
we'd still try to read back from the backfill cairo surface and update
the committed cairo surface reference even though no buffer was
attached.
Fix this by adding a new state, 'pending_buffer_attached', which is only
true if a buffer was attached during frame. Only when this is true will
the backfill be read back and the committed cairo surface reference be
updated.
https://bugzilla.gnome.org/show_bug.cgi?id=762120
That way we can let ::cancel callers to override the visual
result of the operation (eg. when detaching notebook tabs on
NO_TARGET).
Also, document gdk_drag_drop_done() so it is mentioned that
this is a one-shot call.
https://bugzilla.gnome.org/show_bug.cgi?id=761954
We should conform to a minimal set of reasons for the gtk side to emit
a better GtkDragResult than GTK_DRAG_RESULT_ERROR. This fixes the notebook
tab DnD feature, where we rely on GTK_DRAG_RESULT_NO_TARGET.
In the wayland side, unfortunately we can't honor either NO_TARGET nor
USER_CANCELLED, we don't know of the latter, so we could return false
positives on the former.
https://bugzilla.gnome.org/show_bug.cgi?id=761954
The first time a window is shown we should always call SW_SHOWNORMAL.
Understand whether to call SW_SHOW or SW_SHOWNORMAL and the specific
ones for the temporary windows depending on IsWindowVisible.
This also fixes the problem when calling gtk_window_present and
the window is snapped to the left or right of the screen.
This patch is based on the patches provided by Yevgen Muntyan
and Aleksander Morgado.
https://bugzilla.gnome.org/show_bug.cgi?id=698652
If the window is iconified we want to restore the window
to get the proper size instead of showing it normal which
would change the size of the window.
https://bugzilla.gnome.org/show_bug.cgi?id=698652
Right now we use one buffer for both staged changes (freshly painted
changes waiting for the frame clock to send to the compositor) and
committed changes (changes actively being read by the compositor
process). This creates a problem in the event we need to stage updates
at the same time the compositor is processing committed updates: we
can't change what the compositor is actively processing.
The current solution for handling this contention is to allocate a
temporary buffer on the spot at the time the updates are staged, and to
copy that buffer back to the shared buffer later. The problem, though,
is that the copy to the shared buffer currently happens as soon as
the updates are finished being staged, not when the shared buffer is
done being processed by the compositor.
In order to address that problem, this commit changes the code to always
stage changes to a dedicated staging buffer. The staging buffer is
used exclusively by the client until the client is done with it, and then
once that staging buffer is committed, the client never writes to that
buffer again. If the client needs to stage new updates, it allocates a
brand new staging buffer, draws to it, and back fills the undrawn parts
of the buffer from a copy of the contents of the committed buffer.
As an optimization, the compositor has the option of releasing the
committed buffer back to the client. If it does so before the client
needs to stage new updates, then the client will reuse the buffer
for staging future updates. This optimization prevents having to allocate
a new staging buffer and the associated cost of back filling
that new buffer with a readback of the committed buffer.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
Right now we handle buffer releases coming from the
compositor in a central place. We add a listener when
first creating the shared buffers.
This is problematic because a buffer can only have
one listener on it at once so users of the buffer
can't get notified when it's released.
This commit moves the buffer listener code from the
centrally managed display code to the cursor and window
code.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
The client and compositor share access to the window
pixel buffers. After the client hands off (commits)
the buffer to the compositor it's not supposed to write
to it again until it's released by the compositor.
The code tries to deal with this contention by allocating
a temporary buffer and using that in the mean time. This
temporary buffer is allocated by a higher layer of the code
when begin_paint returns TRUE. Unfortunately, that layer of
the code has no idea when the buffer is released, so it ends
up blitting the temporary buffer back to the shared buffer
prematurely.
This commit changes begin_paint to always return FALSE.
A future commit will address the contention problem in
a different way.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
There are a few places where we destroy a cairo surface and
then nullify it. This commit changes those to use
g_clear_pointer instead.
It also drops a cairo_surface_finish call that is unnecessary
https://bugzilla.gnome.org/show_bug.cgi?id=761312
The name surface is really overloaded when dealing
with wayland windows.
To alleviate ambiguity, this commit changes the name
of the "surface" and "subsurface" members to have
a wl_ prefix.
https://bugzilla.gnome.org/show_bug.cgi?id=761312
The fallback behaviour of get_work_area () divides the
screen width and height by the window scaling factor, but
those values are already scaled down.
https://bugzilla.gnome.org/show_bug.cgi?id=761474
Set _GTK_THEME_VARIANT to empty string when default theme variant
is used. This will allow to understand whether _GTK_THEME_VARIANT
is not supported or default variant is requested.
https://bugzilla.gnome.org/show_bug.cgi?id=761476
