This avoids a bunch of policy problems with deciding how to lay
out the window menu under different WMs.
For now, we use the special event _GTK_SHOW_WINDOW_MENU, but we
hope to have this standardized in wm-spec quite soon, as KDE wants
it as well.
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.
And the counterpart to unmaximize when dragging a maximized window, if
touch devices aren't going to use EWMH moveresize, having this one at least
makes things feel a bit less awkward.
https://bugzilla.gnome.org/show_bug.cgi?id=709914
Sadly, EWMH moveresize mechanism can't work with touch devices for two
reasons:
1) As a mutter implementation detail, the device is queried in order
to check whether the dragging button is still pressed. Touch devices
won't report the button 1 being pressed through pointer emulation.
2) Even bypassing that check, on X11 touch events are selected prior
to sequences being started, either through XISelectEvents or
XIGrabTouchBegin, no late registering through active grabs is allowed,
as WMs do on reaction to EWMH moveresize messages.
So for the time being, make touch devices fallback on emulated window
dragging, which at least allows for moving windows.
https://bugzilla.gnome.org/show_bug.cgi?id=709914
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 EWMH defines _NET_WM_MOVERESIZE_SIZE_KEYBOARD and
_NET_WM_MOVERESIZE_MOVE_KEYBOARD for operations that are not
initiated by a button-press event. Allow using these by passing
a button of 0 to gdk_window_begin_move/resize_drag.
And deprecate the X11-specific version of it.
We call this new API _set_shadow_width() and not _set_frame_extents()
because we already have a gdk_window_get_frame_extents() with a
different meaning and different type of value.
https://bugzilla.gnome.org/show_bug.cgi?id=720374
Plug windows weren't redrawing properly because the embedded
window was expecting to get messages for each frame from the
compositor, but the compositor doesn't know about embedded
windows. Simply disable frame sync for GtkPlug's GdkWindow -
extending XEMBED to handle frame sync isn't interesting
at this point.
A new API gdk_x11_window_set_frame_sync_enabled() is added
to allow this to be done.
https://bugzilla.gnome.org/show_bug.cgi?id=701613
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.
If you set GDK_SCALE=2 in the environment then all windows will be
scaled by 2. Its not an ideal solution as it doesn't handle
multi-monitors at different scales, and only affects gtk apps.
But it is a good starting points and will help a lot on HiDPI
laptops.
The macros we had for checking for toplevel windows were passing
through the root window, which was not intentional and meant that
for the root window WINDOW_IS_TOPLEVEL() returned TRUE but
window->impl->toplevel was NULL, causing gdk_window_create_cairo_surface()
to crash.
* remove gdk_frame_clock_get_frame_time_val(); a convenience
function that would rarely be used.
* remove gdk_frame_clock_get_requested() and
::frame-requested signal; while we might want to eventually
be able to track the requested phases for a clock, we don't
have a current use case.
* Make gdk_frame_clock_freeze/thaw() private: they are only
used within GTK+ and have complex semantics.
* Remove gdk_frame_clock_get_last_complete(). Another convenience
function that I don't have a current use case for.
* Rename:
gdk_frame_clock_get_start() => gdk_frame_clock_get_history_start()
gdk_frame_clocK_get_current_frame_timings() => gdk_frame_clock_get_timings()
Since we're not exporting the ability to create your own frame
clock for now, remove the setters for GdkFrameTimings fields.
Also remove all setters and getters for fields that are more
about implementation than about quantities that are meaningful
to the applcation and just access the fields directly within
GDK.
Instead of making the frame clock a settable property of a window, make
toplevel windows inherently have a frame clock when created (getting
rid of the default frame clock.) We need to create or destroy frame
clocks when reparenting a window to be a toplevel, or to not be a
toplevel, but otherwise the frame clock for a window is immutable.
Deprecate gdk_window_enable_synchronized_configure() and
gdk_window_configure_done() and make them no-ops. Implement the
handling of _NET_WM_SYNC_REQUEST in terms of the frame cycle -
we know that all processing will be finished in the next frame
cycle after the ConfigureNotify is received.
For an operation like synchronizing audio to video playback, we need to
be able to predict the time that a frame will be presented. The details
of this depend on the windowing system, so make the backend predict
a presentation time for ::begin-frame and set it on the GdkFrameTimings.
The timing algorithm of GdkFrameClockIdle is adjusted to give predictable
presentation times for frames that are not throttled by the windowing
system.
Helper functions:
gdk_frame_clock_get_current_frame_timings()
gdk_frame_clock_get_refresh_info()
are added for operations that would otherwise be needed multiple times
in different locations.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
We want the compositor to do different things for frames where
"slept before" is TRUE. Communicate to the compositor that
frame is a no-delay frame (slept_before=FALSE) by ending the frame
by increasing the counter value by 1, and that the frame is a
normal frame (slept_before=TRUE) by increasing the counter value
by 3.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
In order to be able to track statistics about how well we are drawing,
and in order to be able to do sophisticated things with frame timing
like predicting per-frame latencies and synchronizing audio with video,
we need to be able to track exactly when previous frames were drawn
to the screen.
Information about each frame is stored in a new GdkFrameTimings object.
A new GdkFrameHistory object is added which keeps a queue of recent
GdkFrameTimings (this is added to avoid further complicating the
implementation of GdkFrameClock.)
https://bugzilla.gnome.org/show_bug.cgi?id=685460
Instead of communicating the start of a frame to the window manager
as soon as we begin a frame, start a frame only when we know we've
actually created damage to the contents of a window.
(This uses cairo_set_mime_data() as a notification mechanism - a
clever suggestion from Uli Schlachter.)
The advantage of this is that we aren't forcing the compositor to
do a frame cycle and send _NET_WM_FRAME_DRAWN - depending on how the
compositor is structured that might either cause it to do extra
work or it might send _NET_WM_FRAME_DRAWN early and upset frame
timing.
https://bugzilla.gnome.org/show_bug.cgi?id=685460
