Mark that the the third argument to meta_rectangle_union and
meta_rectangle_intersect is an (out) argument that should be created
by the language binding.
https://bugzilla.gnome.org/show_bug.cgi?id=645247
If dragging the title bar to the edge of the screen to side-tile,
it's easy to end up above the workarea and end up maximized instead.
Make the entire side of the screen act as edge-tiling.
https://bugzilla.gnome.org/show_bug.cgi?id=644961
In a performance or regression testing environment, we may want to
only manage windows from a particular test program, and ignore all
other windows. The MUTTER_WM_CLASS_FILTER environment variable is a
list of WM_CLASS values that should be managed; other windows will
be unmapped and ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=644252
gtk3 no longer has the --screen command-line argument, which mutter
was passing to zenity. Use --display (with an explicitly-specified
screen number) instead.
https://bugzilla.gnome.org/show_bug.cgi?id=643683
This made sense back in the day of stateless window managers,
but gnome-shell isn't. gnome-session will handle gnome-shell
crashing, since it's a required component.
https://bugzilla.gnome.org/show_bug.cgi?id=644529
This adds a preference that when enabled makes all windows not on
the primary monitor be visible on all workspaces (i.e. not part of the
workspace switching handling).
https://bugzilla.gnome.org/show_bug.cgi?id=609258
Sometimes on_all_workspaces is requested by the client/user, and sometimes
its calculated implicitly due to internal state. We split this up so that
we know when the user has explicitly asked for sticky window, when e.g.
setting wmspec properties or storing session info.
on_all_workspaces means this window is visible on all workspaces.
on_all_workspaces_requested, means the user explicitly made the window
sticky somehow (via imported session, _NET_WM_STATE from another wm,
toggled in the window menu, etc). It always implies on_all_workspaces is
TRUE.
Right now the only time we set on_all_workspaces is for override-redirect
windows, but later we can add a "windows on non-primary monitor are not
part of the workspace switching" feature.
https://bugzilla.gnome.org/show_bug.cgi?id=609258
Until the actor is destroyed, we need to have access to the
MetaWindow to access some fields used for painting. Keep a strong
reference to the window rather than just hoping the window will
not be freed.
https://bugzilla.gnome.org/show_bug.cgi?id=642787
We don't actually use the full xrandr to get the primary monitor, we
just rely on the xrandr xinerama compat code to return the primary
monitor first. This lets us avoid adding unnecessary xrandr code and
avoids issues with _NET_WM_FULLSCREEN_MONITORS monitor indexes being
defined wrt xinerama monitor index order.
https://bugzilla.gnome.org/show_bug.cgi?id=609258
The latter move method will place the window by the origin of the
enclosing window decoration/frame, while the former will place by the
origin of the inner window, itself.
(Also moved meta_window_showing_on_its_workspace comment into
gtk-doc)
https://bugzilla.gnome.org/show_bug.cgi?id=642355
When reload_net_wm_state() is called at startup to read the initial
value of _NET_WM_STATE, it was calling recalc_window_type(), but not
recalc_features(), which meant that, eg, meta->skip_taskbar would
never get initialized from meta->wm_state_skip_taskbar, which meant
that next time mutter went to update the window's _NET_WM_STATE, it
would overwrite the app-specified initial values. Fix that.
(In metacity, this bug is masked by the fact that recalc_features()
gets called when reading the intial value of WM_NORMAL_HINTS, which
comes after _NET_WM_STATE in metacity's prop_hooks_table. In mutter,
the table got reordered at some point, exposing the bug.)
https://bugzilla.gnome.org/show_bug.cgi?id=624360
