We have no need for normally reported events during grabs. In fact, it
might be harmful. A plugin might grab the keyboard through
meta_begin_modal_for_plugin() and then expect events to be reported to
the grab window they provide. If meanwhile this XIGrabDevice is
issued, events might start being reported normally to one other of our
windows breaking the plugin event processing.
In particular, on an empty workspace, we set input focus to our
no_focus_window. Then, if gnome-shell calls
meta_begin_modal_for_plugin() and meta_display_freeze_keyboard(), in
that order, input events will start being reported to no_focus_window.
There are two issues with this. One is that no_focus_window isn't
selecting for XI input events and thus the server discards them
completely. But even if that is fixed, events being reported to any
window other than the one gnome-shell expects - the clutter stage
window - means that events will stop reaching it.
https://bugzilla.gnome.org/show_bug.cgi?id=701219
This will make it possible to implement input source switching in
gnome-shell using the popular modifiers-only keybinding that's
implemented on the X server through an XKB option.
https://bugzilla.gnome.org/show_bug.cgi?id=697002
We'll use this in gnome-shell to freeze the keyboard right before
switching input source and unfreeze it after that's finished so that
we don't lose any key events to the wrong input source.
https://bugzilla.gnome.org/show_bug.cgi?id=697001
If a binding is updated with a clear set of strokes (effectively
disabling it) we aren't signaling that the binding changed and thus
the previous strokes will continue to be grabbed.
This fixes that and tries to do a better effort at checking if the
binding changed or not.
https://bugzilla.gnome.org/show_bug.cgi?id=697000
gnome-shell has traditionally just called XSetInputFocus when wanting to
set the input focus to the stage window, but this might cause strange,
hard-to-reproduce bugs because of an interference with mutter's focus
prediction. Add API to allow gnome-shell to focus the stage window that
also updates mutter's internal focus prediction state.
https://bugzilla.gnome.org/show_bug.cgi?id=700735
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
In 97a4cc8c, we accidentally lost the check that kept us from
sending multiple configures to a window before it responds to
_NET_WM_SYNC_REQUEST. So _NET_WM_SYNC_REQUEST stopped working
properly. Add a check back with the same effect.
https://bugzilla.gnome.org/show_bug.cgi?id=696091
During a resize, if we don't have a configure pending, then a counter
change shouldn't trigger anything other than the normal drawing:
it's just a spontaneous frame from the application. So don't try
to update the position or remove our timeout ID.
https://bugzilla.gnome.org/show_bug.cgi?id=696091
ClutterBinLayout's get_preferred_width / get_preferred_height
doesn't respect fixed child positioning when calculating the
size of the layout, but does when allocating. This is absurdly
broken, but it's what we're given. Use a ClutterFixedLayout,
which doesn't have these issues.
https://bugzilla.gnome.org/show_bug.cgi?id=696089
Trying to track the fullscreen status outside of Mutter, as GNOME Shell
was doing previously, was very prone to errors, because Mutter has a
very tricky definition of when a window is set to be fullscreen and
*actually* acting like a fullscreen window.
* Add meta_screen_get_monitor_in_fullscreen() and an
::in-fullscreen-changed signal. This allows an application to
track when there are fullscreen windows on a monitor.
* Do the computation of fullscreen status in a "later" function that
runs after showing, so we properly take focus into account.
* To get ordering of different phases right, add more values
to MetaLaterType.
* Add auto-minimization, similar to what was added to GNOME Shell
earlier in this cycle - if a window is set to be fullscreen, but
not actually fullscreen, minimize.
https://bugzilla.gnome.org/show_bug.cgi?id=649748
Since the tile mode is now always reset on maximize(), this code
no longer does anything (not to mention that side-by-side tiled
windows haven't snapped back for a while now).
https://bugzilla.gnome.org/show_bug.cgi?id=682779
We used to restore side-by-side tiling when unmaximizing, so we
kept the tile-mode during maximization. Since commit 10d53fc7d
there's no longer a good reason to do so, and it can result in
tile previews being shown erroneously on window drag operations
without motion (double-click on titlebar), so reset the tile
mode in maximize().
https://bugzilla.gnome.org/show_bug.cgi?id=682779
The tile preview is expected to be shown underneath the focus window.
However the code that restacks the preview broke when override-redirect
windows were moved to a separate window group.
To fix, special-case tile previews to put them in the NORMAL layer.
https://bugzilla.gnome.org/show_bug.cgi?id=696053
If _NET_WM_OPAQUE_REGION is set when the window is first mapped, the
initial load_properties will happen before the window actor is created,
and we'll have a call to meta_compositor_window_shape_changed. Just
fizzle this call out instead of doing anything fancy, as we'll pick
up the opaque region when the window actor is eventually created.
https://bugzilla.gnome.org/show_bug.cgi?id=695813
Previously, we were handling failure to respond to _NET_WM_SYNC_REQUEST
in the code path for throttling motion events. But this meant that
if a window didn't respond to _NET_WM_SYNC_REQUEST and there were no
motion events - for a keyboard resize, or after the end of the grab
operation - it would end up in a stuck state.
Use a separate per-window timeout to reliably catch the failure to respond
to _NET_WM_SYNC_REQUEST.
https://bugzilla.gnome.org/show_bug.cgi?id=694046
During resizing we froze window updates when configuring the
window, and unfroze the window updates when processing the
next resize. This wasn't absolutely reliable, because we might
not have a next resize. Instead tie window freezing more
directly to the current sync request value - a window is
frozen until it catches up with the last value we sent it
in _NET_WM_SYNC_REQUEST.
Testing with unresponsive clients showed that there was a bug
where window->disable_sync once set, would not actually disable
sync, but it *would* disable noticing that the client was
unresponsive for the next resize. Fix that by checking for
->disable_sync before sending _NET_WM_SYNC_REQUEST.
https://bugzilla.gnome.org/show_bug.cgi?id=694046
Window actors might be temporarily parented to intermediate actors during
effect, but we should not require that the plugin keeps track of stacking.
Rather, assume that the intermediate groups holds a whole stack, and
applying position within it.
https://bugzilla.gnome.org/show_bug.cgi?id=695711
When windows get redirected off screen, all that gets left behind
is black. We don't want to flicker black at startup, though.
This commit maps the overlay window early, before redirecting
toplevels, so they end up getting snapshotted onto the background
pixmap of the overlay window when the overlay window is mapped.
https://bugzilla.gnome.org/show_bug.cgi?id=694321
Send a _NET_WM_FRAME_DRAWN for each newly created window, as required
by the specification. This avoids a race where a window might be created
frozen but already unfrozen by the time we first see fetch the
counter value.
Remove a duplicate call to meta_compositor_set_updates_frozen() which
was called before the MetaWindowActor is created and hence did nothing.
https://bugzilla.gnome.org/show_bug.cgi?id=694771
mutter currently only filters the overlay key through the shell
when there is a grab operation and that grab operation belongs to the
shell (because the shell is pushModal'd). This means the shell can't
filter out overlay key press events events at startup (since the shell
isn't normally modal).
This commit changes the code to always run the shell filtering code,
even when the shell is not modal.
https://bugzilla.gnome.org/show_bug.cgi?id=694837
The background vignette currently fits itself to the painted
texture, instead of the monitor. This causes some very
wrong looking drawing for backgrounds that don't fill the screen.
This commit reworks the vignette shader code to be clearer, more
correct, and parameterized so that it knows how to scale and
position the vignette.
https://bugzilla.gnome.org/show_bug.cgi?id=694393
The WALLPAPER style of background painting currently
draws starting in the upper left corner of each monitor.
This isn't really correct, it means the seam between
monitors doesn't match up and edges look unbalanced if
the tile isn't a multipe of monitor size.
Really, the tiles should be centered in the middle of
the screen. (Just like when tiling a bathroom floor,
tiles should start in the center of the room.)
This commit reworks the math to make that happen.
https://bugzilla.gnome.org/show_bug.cgi?id=694393
Commit 4f2bb583bf started to use a clutter_threads_add_repaint_func_full
callback instead of connecting to the stage's paint signal.
The callback has to return TRUE if it wants to be called again, so fix that
as we want to call it for every frame (otherwise apps supporting the WM SYNC
protocol will stop drawing).
https://bugzilla.gnome.org/show_bug.cgi?id=695006
Doing so causes useless full stage redraws and breaks culling
as clutter cannot know how the signal handler affects painting.
So use clutter_threads_add_repaint_func_full with the
CLUTTER_REPAINT_FLAGS_POST_PAINT flag instead.
https://bugzilla.gnome.org/show_bug.cgi?id=694988
gnome-shell shouldn't announce to the session manager it's
"ready" until it's fully initialized. It currently tells
the session manager it's ready as soon as it hits the main
loop. This causes nautilus in classic mode to start before
we have workspaces initialized.
https://bugzilla.gnome.org/show_bug.cgi?id=694876
During compositor grabs, all global keybindings that don't go
through mutter's keybinding system are blocked. To allow other
processes to make use of it, gnome-shell will expose a simple
grab API on DBus; for this, add API to grab key combos directly
instead of parsing accelerators stored in GSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=643111
There is currently code to try to fill gradients in a
hardware native format, using #ifdefs. That optimization is
unimportant since gradients only use 2 byte buffers. It's
also incorrect because it's getting the channel order wrong
at buffer initialization time.
This commit drops the ifdefs for clarity and fixes the
channel order.
https://bugzilla.gnome.org/show_bug.cgi?id=694641
meta_screen_get_monitor_for_rect will return the monitor that
a given rect belongs in (choosing the "best" monitor based on
overlap, if there are overlapping monitors).
It doesn't work with 0x0 rects, though.
This commit fixes that.
https://bugzilla.gnome.org/show_bug.cgi?id=694725
meta_window_is_remote compares a cached copy of the system hostname
with the hostname of the client window
(as presented by the WM_CLIENT_MACHINE property).
Of course, the system hostname can change at any time, so caching
it is wrong. Also, the WM_CLIENT_MACHINE property won't necessarily
change when the system hostname changes, so comparing it with the
new system hostname is wrong, too.
This commit makes the code call gethostname() at the time
WM_CLIENT_MACHINE is set, check whether it's remote then, and cache
that value, rather than comparing potentially out of sync hostnames
later.
https://bugzilla.gnome.org/show_bug.cgi?id=688716
Background handling in GNOME is very roundabout at the moment.
gnome-settings-daemon uses gnome-desktop to read the background from
disk into a screen-sized pixmap. It then sets the XID of that pixmap
on the _XROOTPMAP_ID root window property.
mutter puts that pixmap into a texture/actor which gnome-shell then
uses.
Having the gnome-settings-daemon detour from disk to screen means we
can't easily let the compositor handle transition effects when
switching backgrounds. Also, having the background actor be
per-screen instead of per-monitor means we may have oversized
textures in certain multihead setups.
This commit changes mutter to read backgrounds from disk itself, and
it changes backgrounds to be per-monitor.
This way background handling/compositing is left to the compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=682427
actor_is_untransformed is a function meta-window-group uses to determine
if an actor is relatively pixel aligned and not contorted. It then
returns the coordinates of the actor.
In a subsequent commit will need the function in a different file, so
this commit separates it out.
https://bugzilla.gnome.org/show_bug.cgi?id=682427
Window menus use the first key combination for a binding to show the
acceleration, so the list must be in the right configured order, which
is the opposite of what's built by g_slist_prepend()
https://bugzilla.gnome.org/show_bug.cgi?id=694045
Now that the background actor is reactive, this means that
clicks on the window group part of the stage, even when they're
on an X window, will be registered as the background actor, as
all of the other children of the group aren't reactive. This can
happen when a plugin takes a modal grab, for instance.
https://bugzilla.gnome.org/show_bug.cgi?id=681540
The guard window is effectively the background window, as it sits
in between live windows and minimized windows. This gives us a nice
easy place to allow users to allow users to right-click or long-press
on the wallpaper.
https://bugzilla.gnome.org/show_bug.cgi?id=681540
We do, in fact, need freezing to affect window geometry, so that
move-resize operations (such as an interactive resize from the
left, or a resize of a popup centered by the application) occur
atomically.
So to make map effects work properly, only exclude the initial
placement of a window from freezing. (In the future, we may want
to consider whether pure moves of a window being done in response
to a user drag should also be excluded from freezing.)
Rename meta_window_sync_actor_position() to
meta_window_sync_actor_geometry() for clarity.
https://bugzilla.gnome.org/show_bug.cgi?id=693922
If a window is frozen because it is repainting, that shouldn't kee[p
us from updating its position: we don't want a slow-to-update window
to move around the screen chunkily when dragged. (This does reduce
the efficiency of begin/end frames for replacing double-buffering,
but that never works very well in the case where there was an overlapping
window or the entire screen needed redrawing for whatever reason.)
This fixes a bug where a window that was mapped frozen would not get
positioned properly until after the map effect finished, and would
jump from 0,0 at that point. Since effects *do* need to prevent
actor repositioning by Mutter, we must position the actor before any
effect starts.
Because we now are queuing invalidates on frozen windows, fix the
logic for that so that we properly update everything when the window
unfreezes.
https://bugzilla.gnome.org/show_bug.cgi?id=693922
The WM spec requires _NET_WM_FRAME_DRAWN to *always* be sent when
there is an appropriate update to the sync counter value. We were
potentially missing _NET_WM_FRAME_DRAWN when an application did a
spontaneous update during an interactive resize and during effects.
Refactor the code to always send _NET_WM_FRAME_DRAWN, even when
a window is frozen.
https://bugzilla.gnome.org/show_bug.cgi?id=693833
During resizing, An odd counter value (indicating the beginning of a frame)
shouldn't cause us to redraw and start a new frame, only an even counter
value. This was causing the frozen state for the window frame counter to
overlap the frozen state for the resize, causing the window not to be
updated.
https://bugzilla.gnome.org/show_bug.cgi?id=693833
Put override redirect windows such as menus into a separate window group
stacked above everything else. This will allow us to visually put these
above other compositior chrome.
Based on a patch from Muffin.
https://bugzilla.gnome.org/show_bug.cgi?id=633620
In different places we checked the grab op differently when determing
whether we are using _NET_WM_SYNC_REQUEST. This was somewhat covered
up previously by the fact that we only had a sync alarm when using
_NET_WM_SYNC_REQUEST, but that is no longer the case, so consistently
use meta_grab_op_is_resizing() everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
When a client is drawing as hard as possible (without sleeping
between frames) we need to draw as soon possible, since sleeping
will decrease the effective frame rate shown to the user, and
can also result in the system never kicking out of power-saving
mode because it doesn't look fully utilized.
Use the amount the client increments the counter value by when
ending the frame to distinguish these cases:
- Increment by 1: a no-delay frame
- Increment by more than 1: a non-urgent frame, handle normally
https://bugzilla.gnome.org/show_bug.cgi?id=685463
We previously had timestamp information stubbed out in
_NET_WM_FRAME_DRAWN. Instead of this, add a high-resolution timestamp
in _NET_WM_FRAME_DRAWN then send a _NET_WM_FRAME_TIMINGS message
after when we have complete frame timing information, representing
the "presentation time" of the frame as an offset from the timestamp
in _NET_WM_FRAME_DRAWN.
To provide maximum space in the messages,_NET_WM_FRAME_DRAWN and
_NET_WM_FRAME_TIMINGS are not done as WM_PROTOCOLS messages but
have their own message types.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Add a function to convert from g_get_monotonic_time() to a
"high-resolution server timestamp" with microsecond precision.
These timestamps will be used when communicating frame timing
information to the client.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Use XSyncSetPriority() to prioritize the compositor above applications
for X server priority. In practice, this makes little difference because
the Xorg "smart scheduler" will schedule in a single application for
time slices that exceed the frame drawing time, but it's theoretically
right and might make a difference if the X server scheduler is improved.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Using a "sync delay" where we wait for 2 ms after the vblank before
starting to draw the next frame provides for much more predictable
latency for applications. An application can know that if it completes
a frame any time between 8ms before the vblank to the vblank,
it will reliably be drawn on the following vblank period, rather than
having an unpredictable latency depending on whether the compositor
is currently busy drawing a frame or not.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Instead of defining CLUTTER_ENABLE_EXPERIMENTAL_API and
COGL_ENABLE_EXPERIMENTAL_API in individual source files, enable
them on the command line. We weren't tracking exactly what pieces of
experimental API we were using and we were using the experimental
API in most source files that used Clutter and Cogl, so the
local #defines were annoying rather than useful.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
It's possible that a client might update the (extended)
_NET_WM_SYNC_REQUEST_COUNTER counter twice without actually drawing
anything. In that case, we still should send a _NET_WM_FRAME_DRAWN
message since it's hard for a client to know every case in which
no damage is generated. For now, do it the easy way by forcing a
stage repaint.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Resizing the frame triggers creation of a new backing pixmap for the
window, so we should do that first before we resize the client window
and mess up the contents of the old backing pixmap.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
When the application provides the extended second counter for
_NET_WM_SYNC_REQUEST, send a client message with completion
information after the next redraw after each counter update
by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
If an application provides two values in _NET_WM_SYNC_REQUEST_COUNTER,
use that as a signal that the applications wants an extended behavior
where it can update the counter as well as the window manager. If the
application updates the counter to an odd value, updates of the
window are frozen until the counter is updated again to an even value.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Instead of creating a new alarm each time we resize a window
interactively, create an alarm the first time we resize a window
and keep it around permanently until we unmanage the window.
Doing it this way will be useful when we allow the application to
spontaneously generate sync request updates to indicate
frames it is drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
Replace the unused meta_compositor_set_updates() with
a reversed-meaning meta_compositor_set_updates_frozen(), and use
it to implement freezing application window updates during
interactive resizing. This avoids drawing new areas of the window
with blank content before the application has a chance to repaint.
https://bugzilla.gnome.org/show_bug.cgi?id=685463
meta_screen_resize calls meta_window_update_for_monitors_changed for all
windows including OR windows when the monitors change (or screen size).
This calls meta_window_move_between_rects for the window which attempts to
move the OR window by calling meta_window_move_resize.
meta_window_move_resize refuses to do anything on OR windows (just returns
for OR windows).
This causes a storm of assert messages when the screen
resolution changes while an OR window is visible.
(like the one gnome-control-center displays with the monitor name).
Fix that by not calling meta_window_update_for_monitors_changed for OR windows
and let the applications handle them by themselves.
https://bugzilla.gnome.org/show_bug.cgi?id=693540
- set GTK_STYLE_CLASS_TOOLTIP on the window, and use the same code of
GtkTooltip to paint it
- set GDK_WINDOW_TYPE_HINT_TOOLTIP and make the window non-resizable, so
it doesn't get an incorrect shadow from the WM
https://bugzilla.gnome.org/show_bug.cgi?id=692741
Since we're going to use the tooltip's rounded corners we need a little
bit more of margin (which wasn't a bad idea even with the frame).
Also, don't use GtkMisc for this anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=692741
As the hash table no longer stores only window IDs, we should rename it so
that we make sure to check if something is actually a window before using it
as a window.
https://bugzilla.gnome.org/show_bug.cgi?id=677215
XInput 2.3 adds support for "barrier events", which let us know when
a pointer barrier has been hit, and when the pointer has stopped
hitting the barrier, and lets us "release" the barrier, temporarily
letting the pointer pass through the barrier. These features can be
combined to allow for certain pointer gestures, such as "pushing"
against the bottom of the screen, or stopping the pointer on monitor
edges while dragging slowly for increased edge precision.
This commit should allow graceful fallback if servers with
XInput 2.3 aren't supported.
https://bugzilla.gnome.org/show_bug.cgi?id=677215
Currently, we have a few function wrappers in the shell for pointer
barriers. If we want to implement interactive features on barriers,
we need some sort of signal to be notified of the interactivity.
In that case, we need to make a more sophisticated object-based wrapper
for a pointer barrier. Add one, and stick it in mutter.
https://bugzilla.gnome.org/show_bug.cgi?id=677215
Some windows may already have event masks on them that we've selected
for, especially if we're using GTK+ windows. In particular, this fixes
window menus in the XI2 port.
https://bugzilla.gnome.org/show_bug.cgi?id=690581
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
This new hint allows compositors to know what portions of a window
will be obscured, as a region above them is opaque. For an RGB window,
possible to glean this information from the bounding shape region of
a client window, but not for an ARGB32 window. This new hint allows
clients that use ARGB32 windows to say which part of the window is
opaque, allowing this sort of optimization.
https://bugzilla.gnome.org/show_bug.cgi?id=679901
With the shape region always set, it turns out the bounding region
is only used in one place, that's easily replaced with a variable
we already have available to us.
https://bugzilla.gnome.org/show_bug.cgi?id=679901
With recent changes in the way the window mask texture is constructed,
the shape_region is always set, which means that we can remove
conditionals checking if the shape region is set.
https://bugzilla.gnome.org/show_bug.cgi?id=679901
With the shape region always set, it turns out the bounding region
is only used in one place, that's easily replaced with a variable
we already have available to us.
https://bugzilla.gnome.org/show_bug.cgi?id=679901
With recent changes in the way the window mask texture is constructed,
the shape_region is always set, which means that we can remove
conditionals checking if the shape region is set.
https://bugzilla.gnome.org/show_bug.cgi?id=679901
Currently we only unredirect monitor sized override redirect windows.
This was supposed to catch fullscreen opengl games and improve
their performance.
Newer games like fullscreen webgl games and SDL2 using games (like L4D) as well as wine based games do not use override redirect windows so we need a better
heuristic to catch them.
GLX windows always damage the whole window when calling glxSwapBuffers and
never damage sub regions. So we can use that to detect them.
The new heuristic unredirects windows fullscreen windows that have damaged the
whole window more then 100 times in a row.
https://bugzilla.gnome.org/show_bug.cgi?id=683786
We should call meta_window_actor_detach not
meta_window_actor_queue_create_pixmap to create a new pixmap when we redirect a
previously unredirected window again.
https://bugzilla.gnome.org/show_bug.cgi?id=693042
We want to put barrier wrappers in mutter, which requre XFixes 5.0.
XFixes 5.0 was released in March, 2011, which should be old enough
to mandate support for.
https://bugzilla.gnome.org/show_bug.cgi?id=677215
Using a public method for setting the (cached) icon geometry rather
than accessing the struct members directly allows setting the icon
geometry from extensions.
https://bugzilla.gnome.org/show_bug.cgi?id=692997
We have some code in gnome-shell that does the equivalent of:
window.get_workspace() == workspace || window.is_on_all_workspaces();
which is a bit unwieldy. We already have a method in mutter,
so use that and document it.
https://bugzilla.gnome.org/show_bug.cgi?id=691744
With some recent changes to how mask textures are constructed from
shapes, a helper method we made was only called in one place, allowing
us to drop a reference/destroy, and remove a double clear.
https://bugzilla.gnome.org/show_bug.cgi?id=679901
Due to a conditional error, meta_region_builder_add_rectangle was called
on every single blank pixel, rather than at the end of spans. With the new
rename, it's fairly clear to see the error. Fix the check to ensure that
we no longer make extraneous calls to meta_region_builder_add_rectangle.
https://bugzilla.gnome.org/show_bug.cgi?id=691874
GtkWindow added the BACKGROUND style class to all windows, which the
CSS file selects on to set a background color for all windows. Without
this, the background color becomes undefined, and thus window frames
look like they have "glitchy" graphics.
https://bugzilla.gnome.org/show_bug.cgi?id=690317
The minimize action does not make much sense without a window list,
which is why its default keybinding was removed in bug 643609;
getting the focused window out of the way quickly can still be useful
though, so change the description to "Hide window" instead, which does
not imply a window list. We will then assign a default shortcut again.
https://bugzilla.gnome.org/show_bug.cgi?id=682887
MetaButtonLayout is extremely unfriendly for introspection: its fields
are arrays of a fixed length, but the actual length is determined by
a custom stop value (e.g. not NULL / 0).
Without API changes this will never work nicely in introspection, but
we can at least make it work; start by filling up unused fields with
the stop value rather than leaving it at random values.
https://bugzilla.gnome.org/show_bug.cgi?id=689263
The style context of the widget is rarely what we want. We won't
fix this to be a MetaFrames style context yet; this just changes
the internal API.
https://bugzilla.gnome.org/show_bug.cgi?id=690317
Currently, we ping windows only when attempting to delete them, but
if the application is not responding, we want to show the dialog
as soon as possible. Given that we cannot be passively notified that
the window stopped responding with the current X11 protocol, a good
workaround is to ping the window when activating it.
If the window stops responding while active, it is expected the user
will try to switch window or open the overview, and when coming back
he'll get the failure dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=684340
Add meta_window_check_alive(), which is a simple wrapper over
meta_display_ping_window(), and takes care of showing the "Application
is not responding dialog" if needed.
https://bugzilla.gnome.org/show_bug.cgi?id=684340
We want to maintain the invariant that an attached modal dialog is always
of type MODAL_DIALOG, so recompute is_attached_dialog() when the window
type changes.
https://bugzilla.gnome.org/show_bug.cgi?id=690454
This removes our final dependency on Core Events, meaning
we can remove support code for them soon.
This commit is a bit ugly as it requires ui having a dependency on
core, but this is already a hack, so this is thus a hack inside a
hack, and two hacks make a right or however that goes.
https://bugzilla.gnome.org/show_bug.cgi?id=688779
In random places that are not grabs, we selected for events on
things like the root window, stage window, COW and more. Switch
these over to using the proper XI2 APIs.
https://bugzilla.gnome.org/show_bug.cgi?id=688779
As calling XIGrabDevice multiple times will change it, just
drop the XChangeActivePointerGrab path and just go down the
XIGrabPointer path always.
https://bugzilla.gnome.org/show_bug.cgi?id=688779
It's unlikely that we'll ever want to support multiple pointer
devices. Multiple keyboard devices may become useful in the future,
but for now, only care about the core keyboard.
https://bugzilla.gnome.org/show_bug.cgi?id=688779
Mechanically transform the event processing of mutter to care
about XI2 events instead of Core Events. Core Events will be left
in the dust soon, and removed entirely.
https://bugzilla.gnome.org/show_bug.cgi?id=688779
This removes some duplicate event type checks, and will make
the code cleaner in the future when we want to make the grab_op_event
handler take an XIDeviceEvent directly.
Based on a patch by Owen Taylor <otaylor@fishsoup.net>
https://bugzilla.gnome.org/show_bug.cgi?id=688779
In order to make the XI2 handling easier on us in the future, we now
split input events from non-input events. This will allow one code path
to use XIEvent, and the other to use XEvent in the future. This commit
has involved plenty of indenting changes, so it's better seen with
git diff -b or &ignorews=1
https://bugzilla.gnome.org/show_bug.cgi?id=688779
Since we want nice alt-tab applications for gnome-shell, we should up the
limit to 96. In the future, we probably want to get rid of the icon-cache,
and allow looking up a correctly sized icon directly from the window.
To prevent app breakage, set the legacy WM_HINTS pixmap size directly to
32x32.
https://bugzilla.gnome.org/show_bug.cgi?id=689651
Add an additional "switcher" keybinding for switching between
applications rather than windows (like the existing 'switch-windows'
and 'switch-group' bindings).
The purpose of the new keybinding is to be taken over by gnome-shell's
application-based alt-tab popup, so rather than actually implementing
an application switcher in mutter, let it duplicate the normal window
switcher when run standalone.
https://bugzilla.gnome.org/show_bug.cgi?id=688913
Currently meta_display_get_tab_list() will only return windows on
a single workspace. Make the workspace parameter optional to allow
requesting windows from all workspaces.
https://bugzilla.gnome.org/show_bug.cgi?id=688913
The window positioning is delayed in idle_move_resize() in case the application
resizes/maximizes its window quickly after its creation. The delayed
positioning uses window->user_rect because of bug 426519 comment 3 (see
meta_window_move_resize_now()).
user_rect was not set in the initial positioning, causing the delayed
positioning unable to know which monitor we use for this window. As a
consequence, the window could jump spontaneously from one monitor to another.
With this patch, the window does not jump anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=556696
As the overlay key works differently from normal keybindings, it
requires special treatment. However, by adding a rudimentary
MetaKeyBinding for it, we will be able to confine the special
handling to mutter and treat it like any other keybinding in
the shell.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
Currently keybindings are blocked while the compositor holds a grab; if
we want a keybinding to be available anyway, we use captured ClutterEvents
to determine the KeyBindingAction the event would have triggered and
run our own handlers (ugh).
Instead, provide a hook to allow the compositor to filter out keybindings
before processing them normally, regardless of whether the compositor
holds a grab or not.
https://bugzilla.gnome.org/show_bug.cgi?id=688202
Since GTK+ commit b1ad5c8abc2c, GtkSetting's CSS provider uses a
priority of GTK_STYLE_PROVIDER_PRIORITY_SETTINGS, which means it
will overwrite the ones we create ourselves.
Bump the priority to fix dark window decorations.
https://bugzilla.gnome.org/show_bug.cgi?id=688182
The X server sends a XkbNewKeyboardNotify event for each keyboard
device when a new keyboard description is loaded. These days a typical
computer has several keyboard devices, e.g. xinput on this laptop
lists 8. Since the work we do on these events is relatively expensive
and we are only really interested in changes to the virtual core
keyboard we can skip other devices' events to cut on needless work.
https://bugzilla.gnome.org/show_bug.cgi?id=674859
Using ClutterEffect is not pratical on MetaBackgroundActor, as the FBO
redirection has a noticeable performance impact. Instead, allow adding
GLSL code directly to the pipeline used to draw the background texture.
At the same time, port MetaBackgroundActor to modern Cogl API.
https://bugzilla.gnome.org/show_bug.cgi?id=669798
When support for multiple plugins was removed, the logic that was
supposed to send events to Clutter directly *only if there is no filter
function from a plugin* was broken, so events were being sent to
Clutter twice if Clutter didn't consume them the first time.
https://bugzilla.gnome.org/show_bug.cgi?id=686406
When using the show-desktop shortcut with no desktop window, unshowing
will focus the second-most-recently-used window. If we find a desktop
window, it will be focused explicitly and everything works as expected;
however without a desktop window, we end up hiding the focus window,
which will use focus_default_window() with the not_this_one parameter
to move focus away. We used to get away with this, as the not_this_one
parameter was ignored until commit e257580b94, now with bug 675982
fixed, we need to explicitly handle the show-desktop case.
https://bugzilla.gnome.org/show_bug.cgi?id=686928
On startup, workspaces are initialized according to the num-workspaces
preference. However when using dynamic workspaces, the actual number
of workspaces in use might be greater than the preference (when
replacing the window manager), forcing windows on those workspaces
to the first workspace.
To fix, ignore the preference completely when using dynamic workspaces
and try to restore the previous number of workspaces (as read from
_NET_NUMBER_OF_DESKTOPS).
https://bugzilla.gnome.org/show_bug.cgi?id=685439
Fixes bug #670396. Without this fix the guard window may not
extend over the whole area of the screen after a XRandR
reconfiguration. The effect being that mouse events are
delivered to invisible windows.
Moving focus immediately on crossing events as we currently do
in focus-follows-mouse mode may trigger a lot of unwanted focus
changes when moving over unrelated windows on the way to a target.
Those accidental focus changes prevent features like GNOME Shell's
application menu from working properly and are visually expensive
since we now use a very distinct style for unfocused windows.
Instead, delay the actual focus change until the pointer has stopped
moving.
https://bugzilla.gnome.org/show_bug.cgi?id=678169
Add a type annotation on the xevent_filter vfunc. This is sufficient
to remove the skip annotation on MetaPlugin and MetaPluginClass
without triggering scan errors.
https://bugzilla.gnome.org/show_bug.cgi?id=671098
If someone plugs in a new monitor, while all their regular windows
should move in absolute X coordinates to ensure they stay on the
same monitor, the desktop window should stay put.
https://bugzilla.gnome.org/show_bug.cgi?id=681159
Simplify the set of window-property functions to remove the
unused functions:
meta_window_reload_properties_from_xwindow()
meta_window_reload_properties()
And to make:
meta_window_reload_property()
static. The code is considerably simplified by removing the
plural variants.
https://bugzilla.gnome.org/show_bug.cgi?id=587255
Plenty of ugly here, but it works; revert when the zenity version
we depend on stops being bleeding-edge (or we can assume a zenity
version that does not error out on unknown options).
https://bugzilla.gnome.org/show_bug.cgi?id=684306
Quotes should definitively part of the translation, but we are in
string freeze now - revert this when we get a string freeze approval
or after the freeze ends.
https://bugzilla.gnome.org/show_bug.cgi?id=684306
As plugins can now define their own keyboard shortcuts via
meta_display_add_keybinding(), it makes sense for them to
expose those shortcuts to System Settings, so add some API
to set the properties gnome-control-center uses to pick up
wm keybinding settings.
https://bugzilla.gnome.org/show_bug.cgi?id=671010
meta_window_group_paint tries to carefully figure out which parts of the
scene it can avoid painting. One area it avoids painting is the region of
the screen occupied by an unredirected window (if there's one present).
When subtracting from the visible region, it gets the coordinate spaces
confused, and ends up subtracting the area at the wrong offset. Fix this
by translating the rectangle subtracted from the visible region.
https://bugzilla.gnome.org/show_bug.cgi?id=677116
When changing the overlay-key setting, the change only takes effect
on restart - there are actually two bugs involved:
(1) the test whether the key has changed is located in the
else part of a test for string settings (and overlay-key happens
to be a string settings ...)
(2) with (1) fixed, a change signal is emitted, which triggers a
reload of all keybindings - unfortunately, the actual value
of overlay-key is only read on startup, so the key is reloaded
using the old value
Fix both issues by replacing the custom handling of the overlay-key
with the regular handling of string preferences.
https://bugzilla.gnome.org/show_bug.cgi?id=681906
Instead of getting the x/y of the MetaBackgroundActor with respect to the
parent, use the same logic that we do for windows, fixing the case
where there is a more complex transformation involved.
https://bugzilla.gnome.org/show_bug.cgi?id=681221
Currently when the window group is moved, the visible region set
on the background actor no longer matches the actually visible
region, resulting in flickering around window actors.
Fix by translating the visible region with the window group.
https://bugzilla.gnome.org/show_bug.cgi?id=681221
When we consider tiling a special case of maximization, it makes
more sense to always unmaximize to the normal state rather than
restoring a previous tile state.
https://bugzilla.gnome.org/show_bug.cgi?id=677565
Currently we decide whether a modal dialog should be attached or not
when mapping it, i.e. we don't pick up preference changes that happen
while the dialog is up. It's not really a big deal given that modal
dialogs are usually transitory, but it's easy enough to add a bit of
extra polish ...
https://bugzilla.gnome.org/show_bug.cgi?id=679904
Side-by-side tiling is conceptually very close to maximization
("half-maximized"), so it makes sense to also hide the titlebar
in this state if requested by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=679290
There was a potential case where we were trying to use uninitialized memory,
in the case where the X server threw an error during XShapeGetRectangles.
In this case, we need to use the implicit shape for the window, which means
we need to rearrange code flow to make it work.
https://bugzilla.gnome.org/show_bug.cgi?id=677977
fixes 4595209346
We're supposed to return an index from here now, no longer a pointer
to the current monitor.
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
Similar to meta_screen_get_primary_monitor, this returns a monitor index.
The monitor that the pointer is on. The previous private implementation
has been renamed to meta_screen_get_current_monitor_info.
https://bugzilla.gnome.org/show_bug.cgi?id=642591
