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
If a window has its BoundingRegion shaped, we shouldn't unredirect it,
as it expects the rest of the windows from being shown under it. This
prevents applications like the Skype screen recorder or gtkRecordMyDesktop
which want to show a "border" around the recorded area from being
unredirected, giving the appearance of making the desktop freeze.
https://bugzilla.gnome.org/show_bug.cgi?id=677657
The "multiple plugins loaded at once" strategy was always a big fiction:
while it may be viable if you're super careful, it's fragile and requires
a bit of infrastructure that we would be better off without.
Note that for simplicity, we're keeping the MetaPluginManager, but it only
manages one plugin. A possible future cleanup would be to remove it entirely.
https://bugzilla.gnome.org/show_bug.cgi?id=676855
We already check that the plugin has the appropriate vfunc in the klass
structure, so we shouldn't need to check for the same data again with
a "features" long.
https://bugzilla.gnome.org/show_bug.cgi?id=676855
We may not show the backtrace, but it's prohibitly expensive to generate,
so don't. If someone wants a backtrace they can use the appropriate G_DEBUG
environment variable plus GDB.
https://bugzilla.gnome.org/show_bug.cgi?id=676855
It is impossible to switch to other windows when keep-on-top is set
for maximized windows; given that keep-on-top is only ever useful
to keep a window visible while focusing a different window, the
current behavior is pointless. So ignore keep-on-top while a window
is maximized.
https://bugzilla.gnome.org/show_bug.cgi?id=673581
This effectively makes MetaShapedTexture not a MetaShapedTexture, but a simple
and dumb MetaMaskedTexture, with an optimization for clipped regions.
We're doing this as the mask may need to be more complicated than made of
a cairo path -- we eventually want GTK+ to draw the entire frame background,
which we'll then scan.
https://bugzilla.gnome.org/show_bug.cgi?id=676052
As we want GTK+ to paint the mask on an A8, we can't simply use a cairo
path. A later commit will make this into a simple masked texture, and
meta-window-actor will be in control of the mask.
https://bugzilla.gnome.org/show_bug.cgi?id=676052
The concept of a clip region doesn't make sense now that we have anti-aliased
corners and a full alpha channel. Once the theme transition is complete,
creating a preview image with an alpha channel will be possible by passing
an ARGB surface to gtk_widget_draw(preview_widget, ...);
https://bugzilla.gnome.org/show_bug.cgi?id=676052
These queued redraws, which is a problem when we want to know exactly
what changed when we redraw, so we do minimal effort. We're eventually
going to replace the queue_redraw API with something a lot better, so
let's just get these out of the way now.
https://bugzilla.gnome.org/show_bug.cgi?id=676052
Since we now cache windows in the X server, we don't really need to cache
them here. Since we are redirecting windows in most cases, we're not gaining
anything except added memory usage. Additionally, remove the clip to screen
optimization - if a window is partially off-screen, we still need to draw
the entire thing as redirection means we won't get an expose event for it.
Additionally, when introducing invisible borders, something accidentally
slipped through: we were getting expose events on the invisible borders,
and they weren't in the cached pixels rect, so we were painting the theme
for them, even if we didn't actually paint anything with cairo. Make sure
to clip out the invisible borders instead of just the client rect so that
we don't draw if our expose event is on the invisible borders.
https://bugzilla.gnome.org/show_bug.cgi?id=675111
The EXPORT_PACKAGES variable to the GIR makefile should be the
packages needed to use this gir. It's also unnecessary to set PACKAGES
(which is just used for CFLAGS at scan-time) since CFLAGS is already
pulls in all necessary CFLAGS.
https://bugzilla.gnome.org/show_bug.cgi?id=671092
==31043== 7 bytes in 1 blocks are definitely lost in loss record 213 of 6,861
==31043== at 0x402B018: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==31043== by 0x417789A: ??? (in /usr/lib/libglib-2.0.so.0.3122.0)
==31043== by 0x4177C42: g_malloc (in /usr/lib/libglib-2.0.so.0.3122.0)
==31043== by 0x418DC3A: g_strdup (in /usr/lib/libglib-2.0.so.0.3122.0)
==31043== by 0x408C470: meta_display_open (display.c:475)
==31043== by 0x40A4D42: meta_run (main.c:552)
==31043== by 0x8048A74: main (mutter.c:96)
https://bugzilla.gnome.org/show_bug.cgi?id=672640
If we explicitly check for a NULL pointer, clang will assume
that the pointer may be NULL at some point. We clearly rely
on the pointer being non-NULL earlier, so fix this guy up.
https://bugzilla.gnome.org/show_bug.cgi?id=674876
meta_window_actor_has_shadow() is called for every paint for every
window, verbosely logging in it makes the output of MUTTER_VERBOSE
pretty much useless.
All animations use the constants directly, so this is just declaring
a bunch of local variables and then doing nothing with it.
Another clang warning.
https://bugzilla.gnome.org/show_bug.cgi?id=674876
Require the headers for "XFree86" Xinerama to be present at compile
time. The older "Solaris" Xinerama is only needed for versions of
Solaris where Mutter is unlikely to work. Solaris 10 and 11 include
the XFree86 Xinerama libraries, and apparently that's the only version
that will actually work for Solaris 11, which uses Xorg.
https://bugzilla.gnome.org/show_bug.cgi?id=674727
Cogl now has public experimental API to create a rectangle texture
which we can use instead of creating a foreign texture with GL. This
avoids Mutter depending on Cogl including a GL header from its public
headers which it might not do in future.
https://bugzilla.gnome.org/show_bug.cgi?id=672711
Since Cogl doesn't support multi-texturing with sliced textures and the
shape texture is combined with the texture-from-pixmap texture we need
to make sure we never construct a sliced mask texture. This patch simply
passes the COGL_TEXTURE_NO_SLICE flag to cogl_texture_from_data when
creating the shape mask texture.
https://bugzilla.gnome.org/show_bug.cgi?id=674731
It seems that the only usage of the "widget" parameter throughout
the entire call chain was to pass between two function calls as
mutual recursion.
https://bugzilla.gnome.org/show_bug.cgi?id=671104
Currently pressing the overlay key only triggers the overview if
no other key is pressed between KeyPress and KeyRelease. Extend
this logic to pointer events, so that KeyPress + ButtonPress actions
are treated explicitly different from "pure" overlay key presses.
In particular, this change allows to re-use the overlay key as mouse
button modifier.
https://bugzilla.gnome.org/show_bug.cgi?id=662476
If we want to support keybindings from extensions installed in the user's
directory, we can't take a schema, as the GSettings object needs to have
a special GSettingsSchemaSource.
https://bugzilla.gnome.org/show_bug.cgi?id=673014
Starting the auto-maximize process on a window like a
META_WINDOW_DESKTOP window that is not maximizable gets placement into
a confused state and eventually results in the window being positioned
at the wrong position (the position that an auto-maximized window would
be restored to.)
https://bugzilla.gnome.org/show_bug.cgi?id=673566
When mutter recognizes a full-screen window, it tries to raise it to the top
of the stack. Unfortunately, a recent rewrite of the stack code didn't do
well with raising a window to the top of the stack if the stack wasn't in
a consistent state -- it would crash. Ensure that the stack is in a consistent
state at the top of meta_stack_raise/meta_stack_lower.
https://bugzilla.redhat.com/show_bug.cgi?id=806437https://bugzilla.gnome.org/show_bug.cgi?id=672797
Commit 2fc880db switched from focusing the topmost window as the default
window to focusing the MRU window. This was done in alignment with the
introduction of per-workspace MRU lists to avoid problems where the window
stack was inadvertently changed when focusing windows during window switches.
Now that focusing windows don't have as big an impact on the stacking order,
we can revert back to focusing the top window, which is less confusing to the
user.
For now, leave per-workspace MRU lists, as they're a pretty good approximation
of a global MRU list, and it works well enough.
https://bugzilla.gnome.org/show_bug.cgi?id=620744
This is a new value, not associated with any keybindings, useful
when the WM needs to order the applications by last-interaction,
taking into account all windows.
https://bugzilla.gnome.org/show_bug.cgi?id=667552
"warning: 'match_tile_mode' may be used uninitialized in this function", it
complains. It thinks it's not unused because of other values of
window->tile_mode, but other complex logic ensures that it can't be
META_TILE_MAXIMIZED, so this is a safe commit.
Windows that have minimum widths larger than the screen can't be maximized,
even though we put them in a maximized state and allow users to do so:
the window just won't change size and position. Fix this by simply not giving
the option to maximize, like what happens for non-resizable windows.
https://bugzilla.gnome.org/show_bug.cgi?id=643606
A lot of code did something similar to:
MetaFrameBorders borders;
if (window->frame)
meta_frame_calc_borders (window->frame, &borders);
else
meta_frame_borders_clear (&borders);
Sometimes, the else part was omitted and we were unknowingly using
uninitalized values for OR windows. Clean this up by just testing
for a NULL frame in meta_frame_calc_borders and clearing for the
caller if so.
https://bugzilla.gnome.org/show_bug.cgi?id=643606
Since we're going to be evaluating the work area at startup now, we need
to make sure that we don't iterate over workspaces before they're assigned.
The easiest way to do this is to make sure that meta_window_get_workspaces
doesn't crash.
https://bugzilla.gnome.org/show_bug.cgi?id=643606
Returns the matching tiled window. This is the topmost tiled window in a
complementary tile mode that is:
- on the same monitor;
- on the same workspace;
- spanning the remaining monitor width;
- there is no 3rd window stacked between both tiled windows that's
partially visible in the common edge.
https://bugzilla.gnome.org/show_bug.cgi?id=643075
After the changes in style handling in GTK+, mutter's tooltips no
longer match the tooltip style used in applications. Given that
all buttons in the default layout are well-known, killing tooltips
altogether rather than fixing the styling issues looks like a valid
approach.
https://bugzilla.gnome.org/show_bug.cgi?id=645101
Windows that start up in a size that is almost as big as the workarea create
extra work for the user (resizing or maximizing) so save the user's time by
detecting such windows and automaximize them.
https://bugzilla.gnome.org/show_bug.cgi?id=671677
Basically we don't really want to create windows that are almost maximized in
size but not actually maximized. This creates work for the user and makes it
very difficult to use and resize manually.
So set the newly unmaximized window size to the previously used size or 80% of the
size of the current workarea (attempting to retain natural aspect ratio if
possible), whichever is smaller.
https://bugzilla.gnome.org/show_bug.cgi?id=671677
Some modifiers like NumLock and ScrollLock don't make sense in
keybindings, which is why we ignore them when matching keybindings
to events. We should do the same in Javascript, so add an accessor
function.
https://bugzilla.gnome.org/show_bug.cgi?id=665215
The move-to-corner keybindings weren't treated as user actions, which
resulted in them not affecting the saved position - they weren't
always being treated as sticky. Marking them as a user action revealed
bugs in the positioning logic that were hidden by the constraint
code applied to automated moves. Fix those as well. Bug tracked
down by Mariusz Libera.
https://bugzilla.gnome.org/show_bug.cgi?id=661256
We currently sync the number of workspaces with the corresponding
preference. This is not really useful with GNOME Shell's dynamic
handling of workspaces, not least as the setting is effectively
ignored. Worse, it will trigger writes to dconf on login, slowing
down startup, so add a setting to indicate that workspaces are managed
dynamically and really ignore the num-workspaces setting when set.
https://bugzilla.gnome.org/show_bug.cgi?id=671568
We were relying on GTK+ emitting GtkWidget::style-updated during
widget initialization to create the GtkStyleContexts used for
window decorations. A recent GTK+ update broke this assumption,
so do the necessary initialization ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=671796
Mutter originally started out with the idea that only a subset of the total
API was exposed to plugins, so some APIs are duplicated on MutterPlugin.
We've long since abandoned that idea; remove these wrappers.
https://bugzilla.gnome.org/show_bug.cgi?id=671103
After _unmanage the object is semantically dead even if technically it's not,
so remove the prefs listener here to prevent it being called for a dead
object.
In particular this fixes a crash when starting up gnome-shell with at least
one gimp utility window opened which causes mutter to create a MetaWindow for
it only to immediately get an UnmapNotify afterwards which causes mutter to
unmanage the MetaWindow. Afterwards prefs_changed_callback is called for this
dead MetaWindow and tries to dereference the window->monitor pointer which is
already NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=671087
The experimental Cogl api cogl_texture_pixmap_new() was recently changed
so it now expects an explicit CoglContext argument and it can also
return exceptions now via a GError. This patch updates mutters use of
the api accordingly.
This was preventing Clutter from running its dispose, preventing
it from being destroyed correctly. While a major bug and possibly
big memory leak, the most obvious effect was the message that Clutter
spat out:
Clutter-CRITICAL **: clutter_actor_iter_next: assertion `ri->age == ri->root->priv->age' failed
Since we never disposed the actor correctly, it was never removed
from its parent, and the age wasn't updated correctly.
When we were shaping the window with a cairo region, there was an easy
optimization to restrict painting only to the pixels we were going to
actually draw. With rounded corners, the amount of work we have to do
figure out what pixels isn't worth the small savings of not drawing the
completely transparent parts of the corners, so remove this optimization,
and the supporting meta_shaped_texture_get_visible_pixels_region()
https://bugzilla.gnome.org/show_bug.cgi?id=657639
ClutterTexture has many features that we simply don't use and don't make
sense for a subclass with custom drawing. Deriving directly from ClutterActor
simplifies our code by avoiding workarounds and makes things more robust.
Additionally, make it public. GNOME Shell was already assuming that any
MetaShapedTexture was also a ClutterTexture, and we need to replace these
bits with new API for GNOME Shell to use.
https://bugzilla.gnome.org/show_bug.cgi?id=660941
When meta_display_unmanage_window_for_screen() is called, it gets a list
of windows and iterates over them and unmanages them, but unmanaging a
window with attached modal dialogs also unmanages those attached modal
dialogs (in the normal case, temporarily), so we need to guard against
such cases by ref'ing the windows in the list and checking if they have
already been unmanaged.
https://bugzilla.gnome.org/show_bug.cgi?id=668299https://bugzilla.redhat.com/show_bug.cgi?id=760918
If we get two configure events on the root window in close
sequence, then we could get the sequence:
ConfigureNotify on the root window w1xh1
Processed by Mutter
clutter_actor_set_size(stage, w1, h1)
<relayout happens, stage window resized by clutter>
ConfigureNotify on the root window, w2xh2
Processed by Mutter
clutter_actor_set_size(stage, w2, h2)
ConfigureNotify on the stage window, w1, h1)
Processed by Clutter
clutter_actor_set_size(stage, w1, h1)
<relayout happens, stage window resized by clutter>
Leaving the stage at the wrong size. To avoid fighting with Clutter,
switch to resizing the stage with XResizeWindow(), similar to how a
toplevel window is handled by a window manager.
For maximized windows, titlebars cannot be used to reposition or
scale the window, so if an application does not use it to convey
useful information (other than the application name), the screen
space occupied by titlebars could be put to better use.
To account for this use case, a setting for requesting that windows'
titlebars should be hidden during maximization has been added to
GTK+, add support for this in the window manager.
https://bugzilla.gnome.org/show_bug.cgi?id=665617
Using an external application using libwnck an external application
can create a new workspace by moving a window into it. In this case we
are currently missing a "workspace-added" signal emission.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=666015
The current code requires windows to be resizable to be considered
for tiling, which excludes all maximized/tiled windows. While this
restriction concurs with the desired behavior for edge-tiling, it
feels overly restrictive for keybindings.
As the edge-tiling code in update_move() already ensures the above
restriction, it seems save to remove it from the can_tile_maximized()
function, assuming that windows that are not meant to be tiled or
maximized won't provide a maximize function.
https://bugzilla.gnome.org/show_bug.cgi?id=648700
Usually tiling involves a size change and the frame is redrawn
automatically, however this is not the case when switching directly
between left- and right-tiled.
Ensure that a redraw happens in that case as well.
https://bugzilla.gnome.org/show_bug.cgi?id=648700
Rather than defining keybindings in static arrays generated at compile
time, store them in a hash table initialized in meta_display_init_keys()
and filled in init_builtin_keybindings().
This is a prerequisite for allowing to add/remove keybindings at runtime.
https://bugzilla.gnome.org/show_bug.cgi?id=663428
Commit d0910da036 merged the visual-bell/visual-bell-type options,
but the change turned out too disruptive for gnome-control-center /
gnome-shell, so gsettings-desktop-schemas commit a5819b2a4e9 re-added
the separate option.
Move preferences to GSettings, using mainly shared schemas from
gsettings-desktop-schemas.
Unlike GConf, GSettings support is not optional, as Gio is already
a hard dependency of GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=635378
The code here was always incorrect - we were processing damage events for
windows without having a texture. Before, this didn't matter, as
cogl_texture_get_width silently returned 0 for invalid handles. Cogl commit
4c3dadd35e changed this.
The fix here involves two strategies. First, we try to guard MetaTextureTower
from invalid textures. Second, we try not to go down the path that eventually
calls meta_shaped_texture_update_area by not handling damage events if we
don't have a texture for the window.
https://bugzilla.gnome.org/show_bug.cgi?id=660941
meta_window_move_resize_frame operates much like
meta_window_move_resize, but ensures the window
and its frame (if present) will fit within the
specified dimensions.
https://bugzilla.gnome.org/show_bug.cgi?id=651899
