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
We never destroy the later list that's added by meta_later_add.
==4289== 16 bytes in 1 blocks are definitely lost in loss record 1,632 of 7,258
==4289== at 0x4C2640D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4289== by 0x5178D9F: standard_malloc (gmem.c:88)
==4289== by 0x5178E37: g_malloc (gmem.c:164)
==4289== by 0x51924B5: g_slice_alloc (gslice.c:842)
==4289== by 0x5194521: g_slist_insert_sorted_real (gslist.c:900)
==4289== by 0x519465A: g_slist_insert_sorted (gslist.c:957)
==4289== by 0x4EA609A: meta_later_add (util.c:876)
==4289== by 0x4E9C330: meta_screen_queue_workarea_recalc (screen.c:2640)
==4289== by 0x4E9A360: update_num_workspaces (screen.c:1646)
==4289== by 0x4E99026: meta_screen_new (screen.c:924)
==4289== by 0x4E7AB51: meta_display_open (display.c:803)
==4289== by 0x4E9168E: meta_run (main.c:552)
https://bugzilla.gnome.org/show_bug.cgi?id=642652
If we are moving in snap mode (shift pressed) we don't want to tile. We must
also cancel any pending tiling if snap mode is activated during the move drag.
https://bugzilla.gnome.org/show_bug.cgi?id=662270
When we reparent a window to the root when we're exiting, we need to offset
the position by the invisible borders, otherwise windows will creep up and
to the left.
https://bugzilla.gnome.org/show_bug.cgi?id=660848
meta_window_get_current_tile_area() computes the area where the tiled window
should be based on the current pointer position but that's only meaningful
when the user is actually dragging the window.
When running the tiling constrain the pointer might be on other monitor and at
that point the window jumps to this other monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=642580
When using more than one monitor, tiled maximization can be triggered with the
pointer in one monitor while most of the window area remains in another. This
means that the maximization constraint would maximize the window into the wrong
monitor as it uses the work area size/position as target.
Fix this by using the current tile area as target size/position.
https://bugzilla.gnome.org/show_bug.cgi?id=657519
Since the frame window size that meta_window_move_resize() uses depends
on whether the window has horizontal/vertical resize functionality, we
need to update this flag before we resize the window.
https://bugzilla.gnome.org/show_bug.cgi?id=659854
If a window had a type hint intended for override-redirect windows
like NOTIFICATION, we ended up with a window that was decorated but
with a frame type of FRAME_TYPE_LAST, causing assertion failures.
Fix this by making recalc_window_features() just call
meta_window_get_frame_type().
https://bugzilla.gnome.org/show_bug.cgi?id=599988
The theme state used to use GtkStateType, but was ported over to GtkStateFlags,
leaving behind a broken assertion that fails when using certain Metacity
themes, for example Nodoka.
https://bugzilla.gnome.org/show_bug.cgi?id=661286
_NET_FRAME_EXTENTS should contain the difference between where a window asked
to be placed, and where it is. Ideally, this should be the same as the visible
extents.
https://bugzilla.gnome.org/show_bug.cgi?id=659848
A window can specify geometry that it is placed at. We need to exclude invisible
borders when calculating where to place the window, otherwise the window will have
a strange offset.
https://bugzilla.gnome.org/show_bug.cgi?id=659848
When a window loses its frame we must unset any overlay path previously set on
the shaped texture.
Not doing so would cause rendering glitches near the window corners in
e.g. chrome/chromium by changing the Appearance preference "Use system title
bar and borders" → "Hide system title bar and use compact borders".
https://bugzilla.gnome.org/show_bug.cgi?id=659477
Shaded windows are assumed to be reduced to the titlebar: the
current code enforces a visible bottom border of 0 and only takes
the size of the title bar (+ invisible top border) into account
when resizing the frame. However, we still add an invisible border
at the bottom, which is than subtracted from the title bar, resulting
in shaded windows being cut off.
Fix by forcing both visible and invisible bottom borders to 0.
https://bugzilla.gnome.org/show_bug.cgi?id=659266
XFixesCreateRegionFromWindow does not take the window's position into account,
which results into setting a wrong shape for windows not located on the
leftmost monitor.
Fix that by creating the region from the window's MetaRectangle.
https://bugzilla.gnome.org/show_bug.cgi?id=657869
If we do this, then there will be invisible borders around the top of attached
modal dialogs, which is unnecessary -- they can't be resized from the top
border and just interfere with the parent dialog.
This requires changing a bit of API to help identify the type of dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=657795
