If we handle a key event then passing it to GTK+ as well can only
cause confusion. Normally GTK+ would do nothing with a key event for
some window it doesn't know about, but plugins might be doing more
things with the GTK+ event queue.
https://bugzilla.gnome.org/show_bug.cgi?id=642426
If a plugin was explicitly specified, falling back to the default
silently is bad; a manager component like gnome-session can
do a better job of handling this scenario.
An example we've hit in gnome-shell is where SpiderMonkey changes
without gjs being rebuilt, and loading the plugin fails due to
unresolved symbols.
But there are obviously others, like the file being missing or
corrupt.
https://bugzilla.gnome.org/show_bug.cgi?id=641384
Similar to the recently added 'size-changed' signal, we may want to do
something in response to a window being repositioned without waiting for
notify::allocation. (Especially since what we can do in notify::allocation
is severely limited by Clutter forbidding queueing an allocation at that
point.)
https://bugzilla.gnome.org/show_bug.cgi?id=641310
If we are previewing hidden windows, we might be previewing them in a context
like a thumbnail view of a workspace where we care about positioning. So, instead
of waiting until the window is first actually shown to place it, if
live_hidden_previews is set, place the window window when we first compute its
visibility, even if we don't end up showing it.
https://bugzilla.gnome.org/show_bug.cgi?id=641309
A plugin that does workspace management on its on may want to set the
workspace layout without having to deal with putting a property
on the root window to be read back and parsed.
Add meta_screen_override_window_layout() that allows the same types
of layouts as _NET_DESKTOP_LAYOUT but without setting a property.
https://bugzilla.gnome.org/show_bug.cgi?id=640552
A logic bug was resulting in the bottom hidden window (hidden means means
minimized or on a different workspace) continually being stacked above
the other hidden windows.
https://bugzilla.gnome.org/show_bug.cgi?id=640679
When we delete a workspace before the active workspace, we need
to upate the _NET_CURRENT_DESKTOP since the active workspace index
changes. To do this workspace.c:set_active_space_hint() is moved
to screen.c:meta_screen_set_active_workspace_hint() so that it
can be shared.
https://bugzilla.gnome.org/show_bug.cgi?id=640581
Emit a signal when the window size changes. While it is already
possible to connect to notify::allocation (or width/height), the
new signal is emitted outside a clutter allocation cycle, which
makes it more convenient when adjusting an actor's size/position
in response.
On gcc-4.4 (void)<expr> doesn't suppress warnings from
__attribute__((warn_unused_result)), so use
G_GNUC_UNUSED (which expands to __attribute__((unused))) instead
of removing a dummy variable.
https://bugzilla.gnome.org/show_bug.cgi?id=640508
As the tile preview is shown or hidden when a window is dragged
around, it may stick around if the drag operation is cancelled.
Make sure that the preview is hidden in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=639988
Drag operations may be cancelled, in which case the dragged window
should be restored to the position/state it had when the drag was
initialized. In order to do this for tiled states, the original
state has to be saved during the operation.
https://bugzilla.gnome.org/show_bug.cgi?id=639988
The previous tiling state of a grabbed window should be restored
if the drag operation is cancelled (by hitting the Escape key).
This might involve to meta_window_tile(), so export the function
in window-private.h.
https://bugzilla.gnome.org/show_bug.cgi?id=639988
GtkStyle has been deprecated in favor of GtkStyleContext. A full
port would involve replacing GdkColor with GdkRGBA - leave this
out for the time being.
Bump the required version of GTK+.
https://bugzilla.gnome.org/show_bug.cgi?id=637761
We want switching between the windows of an application to be an easily
accessible operation. The convenient and memorable keybinding is the
key above the tab key - but the keysym for that key isn't consistent
across different keyboard layouts.
Add code that figures out the key from the XKB geometry and a magic
keysym name "Above_Tab" that refers to this key and switch
the default binding for cycle_group to <Alt>Above_Tab. (This will
have no effect for the normal case of getting the key binding from
GConf until this patch is applied to Metacity as well.)
https://bugzilla.gnome.org/show_bug.cgi?id=635569
It may be desirable for theme authors to treat side-by-side tiled
windows differently, for instance to give the edge-touching border
a width of 0, so add additional frame states for tiled windows.
https://bugzilla.gnome.org/show_bug.cgi?id=637330
With the existing background functions, single buttons can not be
styled separately - on the left side, the style of the left button
is picked, and the right button's style on the right side.
As theme authors may want to add rounded corners to button groups
as a whole, it makes sense to treat the case of a single button in
a group differently.
https://bugzilla.gnome.org/show_bug.cgi?id=635683
When validating button functions and frame styles, the required
format version of the features used in the theme was compared to
the major version number of the supported format, limiting additions
to major theme format bumps.
Use peek_required_version() instead, so the minor version number
of the supported theme format is taken into account.
https://bugzilla.gnome.org/show_bug.cgi?id=635683
While the configured layout is taken into account for positioning
the buttons, the mapping from button function states to button
position states just assumed the default button layout in LTR
locales.
Do a proper mapping depending on the actual layout instead.
https://bugzilla.gnome.org/show_bug.cgi?id=635686
