If an app pops up an OR window and sets input focus to it, like
Steam does, we'll think the focus window is null, causing us to
think the app is not focused.
OR windows should not be special if they get input focus, where
the input focus would be set to NULL. Instead, the window should
be marked as focused.
https://bugzilla.gnome.org/show_bug.cgi?id=647706
Mutter previously defined display->focus_window as the window that the
server says is focused, but kept display->expected_focus_window to
indicate the window that we have requested to be focused. But it turns
out that "expected_focus_window" was almost always what we wanted.
Make MetaDisplay do a better job of tracking focus-related requests
and events, and change display->focus_window to be our best guess of
the "currently" focused window (ie, the window that will be focused at
the time when the server processes the next request we send it).
https://bugzilla.gnome.org/show_bug.cgi?id=647706
The hierarchy handling is handled in the shell by adding stuff
directly to the uiGroup, and we have a dedicated actor for
the overview there, so we don't need this anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
Make it a static function for now, but this will be a private
function soon, replacing meta_window_lost_focus. This should
contain no functional changes, only cosmetic indentation changes,
so best viewed with ignorews=1 or -w or -b, you know the drill.
https://bugzilla.gnome.org/show_bug.cgi?id=647706
Clients using _NET_WM_MOVERESIZE to start a drag operation may encounter
a race condition if the user presses and releases a mouse button very
fast, getting "stuck" in a grab state. While this is easily fixed with
the user pressing the button or hitting Escape as the EWMH spec suggests,
its's still a bit of annoyance for users.
After starting a grab operation, check that the button is actually pressed
by the client, and if not, cancel the grab operation. This prevents the
stuck grab in a race-free way, although it requires an extra round-trip
to the server.
With client-side decorations becoming more popular, the use of
_NET_WM_MOVERESIZE is on the rise, thus this bug is seen more frequently
than before.
https://bugzilla.gnome.org/show_bug.cgi?id=699777
As we only had one string-array preference so far, we didn't bother
with adding a generic way to handle string-array preferences, and
just handled the preference in question explicitly. However we are
going to parse another string-array setting, so generalize the
existing code to make it reusable for that case.
https://bugzilla.gnome.org/show_bug.cgi?id=700223
g-ir-scanner will emit more warnings regarding broken GTK-Doc
syntax in the near future, which due to --warn-error being used
would break the build:
'''
ui/theme.c:1883: Warning: Meta: missing ":" at column 20:
* @tokens_p: (out) The resulting tokens
^
g-ir-scanner: compile: gcc -Wall -Wno-deprecated-declarations ...
g-ir-scanner: link: /bin/sh ../libtool --mode=link --tag=CC gcc ...
libtool: link: gcc -o /home/dieterv/gnome.org/checkout/mutter/...
<unknown>:: Fatal: Meta: warnings configured as fatal
<unknown>:: Fatal: Meta: warnings configured as fatal
make[4]: *** [Meta-3.0.gir] Error 1
'''
https://bugzilla.gnome.org/show_bug.cgi?id=699636
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>
This makes it a bit simpler for other functions on a MetaUIFrame to
get this information.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=697758
Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
XUngrabKey() doesn't work for XI2 grabs and XI2 doesn't provide API
with similar functionality. As such, we have to refactor the code a
bit to be able to call XIUngrabKeycode() for each key binding, then
reload keybindings and finally grab the new ones.
https://bugzilla.gnome.org/show_bug.cgi?id=697003
compositor/meta-background.c:64: error: redefinition of typedef 'MetaBackgroundPrivate'
./meta/meta-background.h:51: error: previous declaration of 'MetaBackgroundPrivate' was here
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
Right now we call unset_texture from MetaBackground's dispose method.
unset_texture assumes there's a pipeline available, but there may not
be if the object was just created.
This commit fixes that incorrect assumption.
https://bugzilla.gnome.org/show_bug.cgi?id=696157
Cogl automatically caches pipelines with no eviction policy,
so we need to make sure to reuse snippets to prevent
identical pipelines from getting cached separately.
https://bugzilla.gnome.org/show_bug.cgi?id=696157
g_task_propagate_pointer relinishes the GTask
of its reference to the propagated pointer, so we need to
unref it ourselves when we're done with it.
https://bugzilla.gnome.org/show_bug.cgi?id=696157
