Break down the beautiful core/ui abstraction barrier by inserting
a pointer to MetaWindow into a MetaUIFrame. I'm a scoundrel, I know.
We'll use this very soon to destroy meta_core_get.
We now have everything in place to pick up geometry and drawing
information from GTK+ rather than the metacity theme, so do just
that; the metacity theme is now only used for some constants
(title_scale, hide_buttons, ...), which we will replace soon.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
Sounds obvious, doesn't it?
After this change when titlebar-uses-system-font is set, the "system
font" used will not be a generic one, but match what GTK+ uses in
client-side decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=741917
For reasons related to interaction between the GTK+ CSS code and the
frame sync protocol, the dummy GtkWindow that MetaUI creates to track
theme properties has to be mapped and have MetaWindow associated with it.
Add a private function so that the test framework can filter this out.
https://bugzilla.gnome.org/show_bug.cgi?id=736505
This way the xserver never paints the frame background, even if
the client window is destroyed. This allows us to have clean
destroy window animation.
There is no problem with interactive resizing because applications
are using the XSync protocol, so we're not painting unless the
client has redrawn.
https://bugzilla.gnome.org/show_bug.cgi?id=734054
When a passive touch grab is rejected over the frame, management is punted to
the frame itself, and pointer events emulated, but the attempt to transfer the
grab from the GDK connection to the Clutter one fails with AlreadyGrabbed, and
will fail until the Clutter connection receives the XI_TouchEnd resulting from
XIRejectTouch, gotten after the XI_ButtonPress on the GDK connection.
In order to bypass this shortcoming, store the current grab operation on the
frame as long as the button is pressed, so it is retried once on the next
motion event happening during frame dragging, that will have a recent enough
timestamp to succeed. If no grabbing succeeded, the current grab operation
data will be reset on GDK_BUTTON_RELEASE.
This has one regression: the basic touch support added by
Carlos Garnacho in 991c85f is now partially reverted, since
we ported to Clutter events for this. We'll need to either
port his changes to Clutter, or restructure event handling
in mutter directly.
We can't really support the Gtk+ automatic scaling, as to much
code relies on the GdkWindow and XWindow sizes, etc to match.
In order to keep working we just disable the scaling, meaning
we will pick up the larger fonts, but nothing else. Its not
ideal but it works for now.
https://bugzilla.gnome.org/show_bug.cgi?id=706388
The reason we don't simply use gdk_window_add_filter directly is
because of some twisted idea that any GDK symbol being used from
core/ is a layer violation. While we certainly want to keep any
serious GDK code out of ui/, event handling is quite important
to have in core/, so simply use a GDK event filter directly.
Currently touch events are ignored in the core event handler,
and hence dealt with within GDK. If those touch events were
emulating pointer events, GDK would attempt to convert back
those events to pointer events as the frame GdkWindow doesn't
have the GDK_TOUCH_MASK set.
This results in XI_TouchBegin events being initially processed
by GDK, converted to button events, and triggering a grab op
that subverts touch events into pointer events, so the touch
is never ever seen again by GDK. This leaves GDK in an
inconsistent internal state wrt pointer grabs, so future
pointer-emulating touches will refer to the same window forever.
Fix this by handling touch events minimally, just enough to
convert XI_TouchBegin to GDK_BUTTON_PRESS within mutter, so GDK
is bypassed for every touch event just like it is for pointer
events. This, and the XIGrabDevice() that keeps coercing pointer
events when the grab operation starts, are enough to fix window
drag and drop on touch devices.
https://bugzilla.gnome.org/show_bug.cgi?id=723552
Since the introduction of frame sync in GTK+, updates to titlebar font and
colors haven't been working because GTK+ counts on the frame clock to
do style updates, and the frame clock doesn't run for an unmapped
GdkWindow. (It's possible that GtkStyleContext changes subsequent to
the introduction of the frame clock were also needed to fully break
things.)
We actually need to map the MetaFrames GdkWindow and let the
compositor code send out the frame sync messages in order to pick up
style changes.
Hopefully no bad side effects will occur from this - we make the window
override-redirect, 1x1, and outside the bounds of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=725751
Since the introduction of frame sync in GTK+, updates to titlebar font and
colors haven't been working because GTK+ counts on the frame clock to
do style updates, and the frame clock doesn't run for an unmapped
GdkWindow. (It's possible that GtkStyleContext changes subsequent to
the introduction of the frame clock were also needed to fully break
things.)
We actually need to map the MetaFrames GdkWindow and let the
compositor code send out the frame sync messages in order to pick up
style changes.
Hopefully no bad side effects will occur from this - we make the window
override-redirect, 1x1, and outside the bounds of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=725751
We can't really support the Gtk+ automatic scaling, as to much
code relies on the GdkWindow and XWindow sizes, etc to match.
In order to keep working we just disable the scaling, meaning
we will pick up the larger fonts, but nothing else. Its not
ideal but it works for now.
https://bugzilla.gnome.org/show_bug.cgi?id=706388
This essentially just moves install_corners() from the compositor, through
the core, into the UI layer where it arguably should have been anyway,
leaving behind stub functions which call through the various layers. This
removes the compositor's special knowledge of how rounded corners work,
replacing it with "ask the UI for an alpha mask".
The computation of border widths and heights changes a bit, because the
width and height used in install_corners() are the
meta_window_get_outer_rect() (which includes the visible borders but not
the invisible ones), whereas the more readily-available rectangle is the
MetaFrame.rect (which includes both). Computing the same width and height
as meta_window_get_outer_rect() involves compensating for the invisible
borders, but the UI layer is the authority on those anyway, so it seems
clearer to have it do the calculations from scratch.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=697758
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
A correctly constructed GtkStyleContext must have its screen
and widget paths set. Getting the frame font caused crashes
on some systems because those were not correctly initialised.
https://bugzilla.gnome.org/show_bug.cgi?id=696814
gdk_device_manager_get_client_pointer which in calls
XIGetClientPointer seems to be very slow in a XI2 world.
So use
gdk_x11_device_manager_lookup (gmanager, META_VIRTUAL_CORE_POINTER_ID)
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=693354
