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
This patch removes the ability to disable compositing in mutter. As
clutter compositing was the reason for the fork from metacity, turning
compositing off does not make sense.
https://bugzilla.gnome.org/show_bug.cgi?id=626875
To deal with reentrancy from compositor plugins doing things like
moving windows between workspaces in an effect callback, update
the visible_to_compositor flag before calling into the compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=613124
When a compositor is present, we keep the visibility state of the
compositor windows in sync with window->visible_to_compositor. We need
to do the same when enabling the compositor.
https://bugzilla.gnome.org/show_bug.cgi?id=613124
* GL_TEXTURE_RECTANGLE_ARB not avaliable
* clutter_glx_texture_pixmap_using_extension / CLUTTER_GLX_TEXTURE_PIXMAP not avaliable
Signed-off-by: Andreas Mueller <schnitzeltony@gmx.de>
Commit 2c8c1c6df49 in gtk+ removed gdk_display_get_core_pointer().
The equivalent functionality can be achieved by using the
GdkDeviceManager to retrieve the client pointer device.
Maximized tiled windows end up with an inconsistent tile mode when
unmaximized by other means than dragging the window free (e.g.
using the unmaximize button or double clicking the title bar), so
reset the tile mode when unmaximizing.
This is not a problem for side-by-side tiling, as there are no
alternatives to dragging the window free.
When a tiled window is maximized (e.g. by clicking the title bar
button), unmaximizing the window restores the tiled state. While
this is reasonable for side-by-side tiling, it is confusing for
"maximize" tiled windows, as unmaximization has no visible effect.
Change unmaximize to only restore the tiled state of side-by-side
tiled windows.
The original patch triggered "maximize" when the window was dragged
to the top, so that the pointer was below or on the monitor edge and
above the work area's top.
If there's no chrome at the top of the monitor, so that monitor edge
and work area top fall together, the pointer cannot be moved above
the work area's top, so tiling was not triggered.
GTK is about to clean up its code and remove duplicate macros and
GdkDrawable usage. To prepare for that landing, we use the future-safe
versions of the same calls.
https://bugzilla.gnome.org/show_bug.cgi?id=636302
The old behavior of being able to shake loose a maximized window
overlaps with and is for the most part superceded by top edge tiling.
This commit changes the code to only enable shake loose behavior
when edge tiling is disabled.
https://bugzilla.gnome.org/show_bug.cgi?id=630548
In addition to the existing side-by-side tiling modes, this commit
adds a new "maximize" tiling mode. It allows the user to maximize
their windows (in other words, tile with the edge panels) by dragging
their window to the top edge of the monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=630548
The meta_window_handle_mouse_grab_op_event function ensures
the tile_mode variable is in a consistent state after a drag
op is finished.
The way this is current done is:
if (!window->maximized_vertically &&
window->tile_mode != META_TILE_NONE)
window->tile_mode = META_TILE_NONE;
While valid, it doesn't "read" as well as using the
META_WINDOW_TILED_SIDE_BY_SIDE macro, since the macro is specifically
about side-by-side tiling.
This commit just changes things to use the macro and to not bother
checking the tile mode (since if we just reset it anyway, then it doesn't
matter if the value is right or wrong to begin with).
https://bugzilla.gnome.org/show_bug.cgi?id=630548
Currently, the new tiling feature, supports side-by-side, horizontal
tiling when dragging windows to one of the vertical edges of a monitor.
Other types of tiling (on other monitor edges) are potentially useful,
though.
This commit renames the preference from side_by_side_tiling to
edge_tiling.
https://bugzilla.gnome.org/show_bug.cgi?id=630548
A direction parameter is passed to meta_compositor_switch_workspace(),
to indicate the direction of the switch depending on the workspace
layout.
In contrast to the switcher popup, this parameter does not take the
text direction of the locale into account. Change this, so that the
workspace switching animations move in the correct direction.
https://bugzilla.gnome.org/show_bug.cgi?id=636083
overlay_key_combo needs the same treatment as other keycodes on a
change - we should always recompute it if we have a keysym not
a keycode, and not only if the keycode hasn't already been
computed.
