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
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.
Simplify the keymap loading logic by unifying the different
branches; in the reorganization this patch fixes a bug where when
we got a MappingKeyboard event we wouldn't update virtual modifiers
correctly.
Based on a patch by Thomas Thurman <tthurman@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=565540
* Select for XKB keyboard notification events explicitly; since GTK+
has selected for XKB events, delivery of old-school MappingNotify
events is disabled.
* Fix a bug where once a keycode was loaded for a key binding,
it would never be reassigned; we want to laod new keycodes for
all bindings that have a key symbol rather than a fixed
keycode.
[ With fixes from Owen W. Taylor <otaylor@fishsoup.net> ]
https://bugzilla.gnome.org/show_bug.cgi?id=565540
Protect against shape_region or bounding_region being NULL in check_needs_shadow.
This can happen for short lived windows and result into a crash.
https://bugzilla.gnome.org/show_bug.cgi?id=635421
Since we aren't depending on Clutter 1.5 or using the new
CoglPipeline name elsewhere, we need to stick to the old
COGL_MATERIAL_WRAP_MODE_* names, which are provided with
compatibility defines in Clutter 1.4.
Pointed out by Rico Tzschichholz
If we have repeats on for a full-sized image, then if the background
is displayed scaled (for example, in a desktop preview mode) then we
can get artifacts along the edge of the background where the repeat
of the opposite edge is blended in by bilinear scaling. So turn off
repeats when the screen and background image sizes match.
https://bugzilla.gnome.org/show_bug.cgi?id=634833
Add code to track and draw the root window background. The advantage of doing
it here as compared to in a plugin is that we can use the visiblity smarts
of MetaWindowGroup to optimize out drawing the background when obscured.
If handling other than tracking the _XROOTPMAP_ID property is desired in the
future, more functionality like setting the background from a file or doing
cross-fades can be added.
The new background actor is exposed to plugins via meta_plugin_get_background_actor()
similar to other exposed actors to allow cloning the background for use in
other displays. The actual class is not installed for public consumption at
the moment since it has no useful methods.
https://bugzilla.gnome.org/show_bug.cgi?id=634833
Create new cogl-utils.[ch] and move a helper function from
MetaShadowFactory there as meta_create_texture_material(); this
allows us to create single-layer materials from different parts of
Mutter and have them share the same template material.
Also expose a function for creating a 1x1 texture of a given
color meta_create_color_texture_4ub().
https://bugzilla.gnome.org/show_bug.cgi?id=634833
When in a partial stage paint, we can combine that with the visibility
information in MetaWindowGroup to further eliminate unneeded drawing.
Since there is no current Clutter API to access the current clip,
drop to using GL directly.
https://bugzilla.gnome.org/show_bug.cgi?id=634779
This is just a microptimization, as we pretty much always use
TFP (and do the check every time we set a pixmap),
we can let gcc generate better code here.
https://bugzilla.gnome.org/show_bug.cgi?id=633002
For various reasons (mostly the stack tracker correctly predicting the
stacking order before getting events, but also because of the processing
that the compositor does to get the actor stacking order) the compositor
can be told to sync the stack when it has nothing to do. Detect this
at the last moment before actually telling Clutter to restack to avoid
triggering unnecessary redraws.
https://bugzilla.gnome.org/show_bug.cgi?id=634771
Since we can't distinguish a ConfigureEvent that indicates a raise
from a ConfigureEvent that indicates a move, we get lots of
STACK_OP_RAISE_ABOVE events for windows that are already in the
right place in the stacking order. Avoid queueing a restack in that
case.
https://bugzilla.gnome.org/show_bug.cgi?id=634771
Fullscreen and maximized windows never have visible shadows - the only
case where we would ever see them is if they bleed onto an adjacent
monitor and that looks bad.
It's small performance win to avoid computing them, and this also avoids
painting the top shadow for all maximized windows in GNOME Shell - since
the top panel isn't a X window, it doesn't factor into the computation
of what parts of windows are visible and maximized windows are computed
as having a top shadow.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
These functions duplicate existing properties; they are added for
convenience and to avoid the GObject property code on some
performance critical painting paths.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
Instead of making optimizing obscured shadows an all-or-none operation,
pass the clip region to meta_shadow_paint() and only paint the 9-slices
that are at least partially visible.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
Instead of setting shadow parameters on individual windows, add the
idea of a "shadow class". Windows have default shadow classes based
on their frame and window type, which can be overriden by setting
the shadow-class property.
Each shadow class has separably configurable parameters for the
focused and unfocused state. New shadow classes can be defined with
arbitrary names.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
Frame types will form the bases of shadow classes, which are strings,
so export the to-string function so that we can do the conversion
uniformly.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
The basic MetaShadowFactory type is moved to a public header, while
the functions to fetch and paint shadows are kept private.
The public object will be used for configuration of shadows by
plugins.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
For attached modal dialogs, we want the shadow to fade out at the top
as if the window was glued to the parent at the top. Add a
shadow-top-fade property to MetaWindowActor and the corresponding
parameter to meta_shadow_factory_get_shadow().
The internal implementation of MetaShadow is adjusted to work
in terms of an "inner border" and "outer border" instead of doing
the calculations in terms of an aggregate border and the spread
of the shadow. The old way of doing things gets clumsy when the
top_fade distance is added in as well.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
Add a new frame type META_FRAME_TYPE_ATTACHED which is used for
attached modal dialogs.
The theme format version is bumped to 3.2, and attached windows
can have borders defined in a metacity-theme-3.xml as:
<window version=">= 3.2" type="attached" style_set="[name]"/>
If no style is defined for "attached", drawing will fall back
to the "border" type.
https://bugzilla.gnome.org/show_bug.cgi?id=592382
The current shadow code just uses a single fixed texture (the Gaussian
blur of a rectangle with a fixed blur radius) for drawing all window
shadows. This patch adds the ability
* Implement efficient blurring of arbitrary regions by approximating
a Gaussian blur with multiple box blurs.
* Detect when multiple windows can use the same shadow texture by
converting their shape into a size-invariant MetaWindowShape.
* Add properties shadow-radius, shadow-x-offset, shadow-y-offset,
shadow-opacity to allow the shadow for a window to be configured.
* Add meta_window_actor_paint() and draw the shadow directly
from there rather than using a child actor.
* Remove TidyTextureFrame, which is no longer used
https://bugzilla.gnome.org/show_bug.cgi?id=592382
The size_request vfunc is going to be dropped in GTK3; replace
the usage in MetaAccelLabel and MetaPreview with
get_preferred_width/get_preferred_height vfuncs.
https://bugzilla.gnome.org/show_bug.cgi?id=633352
In GTK+ 3, it's mandatory to have a GdkDevice in a synthesized event,
so fill in the pointer device for the events we synthesize and forward
to GTK+. Since gdk_event_set_device() only works for allocated events,
we need to switch to gdk_event_new() rather than using stack allocated
events.
https://bugzilla.gnome.org/show_bug.cgi?id=633401
Now that we create MetaWindow objects for override-redirect windows, we need
to check all key press events to see if they are on GTK+ widgets, not just
events that don't match a MetaWindow. This fixes a problem with alt-Tab stealing
grabs away from the window menu.
https://bugzilla.gnome.org/show_bug.cgi?id=633398
With client side windows, mixing GDK event delivery with explicit calls
to XUngrabPointer() can result in GDK losing button release events
it expects to get. This means that GDK thinks there is an implicit
grab in effect when there is none and send events to the wrong window.
Avoid this by bypassing GDK's event handling for most mouse events.
We do a simplified conversion of the X event into a GdkEvent and send
it to directly to libgtk for delivery.
We make an exception when a GDK grab is already in effect - this is
needed for the correct operation of menus.
http://bugzilla.gnome.org/show_bug.cgi?id=599181
While the Meego developers agreed to switching mutter to GTK+-3.0
unconditionally a while ago, Canonical used a GTK+-2.0 build for their
Unity project. As Canonical now announced a switch to compiz as their
window manager, there is no longer a reason to maintain GTK+-2.0
compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=633133
meta_display_process_key_event() always looks up events based on the
"default" keysym for the keycode, so we should do the same here. This
fixes, eg, the lookup of Shift-Alt-Tab (which would otherwise be
unrecognized because the keysym would be XK_ISO_Left_Tab rather than
XK_Tab).
https://bugzilla.gnome.org/show_bug.cgi?id=632155
In ui/fixedtip.c, use g_signal_connect instead of g_signal_connect_swapped
since we're not using the data pointer (and for clarity).
At the same time, ensure that both the GTK2 and the GTK3 code paths
have the correct signature for the handler.
https://bugzilla.gnome.org/show_bug.cgi?id=633051
The code for defining a color as a constant had broken logic: it
would try to parse the color first as an double, then as an integer;
the second attempt would produce an error about overwriting the
already-set-GError. Then it would clear the error and store the constant
as a color.
Use the fact that colors have to start with a letter or #, divide the
space of constants into:
- Integers
- Doubles
- Colors
so we get good error messages. Based on a patch by
William Jon McCann <jmccann@redhat.com>.
Note that this breaks the ability to specify an integer constant as
identical to another integer constant (the same didn't work for doubles.)
I think this was an accidental side effect of the code and not something
that was intentional or people were relying on
https://bugzilla.gnome.org/show_bug.cgi?id=632116
Remove --allow-unprefixed option to the scanner, and fix resulting
problems:
* theme.h and boxes.h are split into a main -header and a private
header that includes stuff that is not generally useful and
hard to introspect. Merge theme-parser.h into theme.h.
* meta_display_get_atom() and meta_window_get_window_type_atom()
are marked as (skip)
* Fix annotation: (element-type Strut) => (element-type Meta.Strut)
https://bugzilla.gnome.org/show_bug.cgi?id=632494
Move all objects and functions namespaced with Mutter into the Meta namespace
to get a single consistent namespace. Changes that aren't simply changing mutter
to meta:
MutterWindow => MetaWindowActor
mutter_get_windows => meta_get_window_actors
mutter_plugin_get_windows => meta_plugin_get_window_actors
https://bugzilla.gnome.org/show_bug.cgi?id=628520
In many places, MetaRegion was being used entirely internally, rather
than for gtk2/gtk3 compatibility. In these cases, it's simpler to just
depend on cairo-1.10 (for both gtk2 and gtk3) and use cairo_region_t.
The few places where we did need GDK compatibility (GdkEvent.region and
gdk_window_shape_combine_mask) are replaced with a combination of
converting GdkRegion to cairo_region_t and conditional code.
https://bugzilla.gnome.org/show_bug.cgi?id=632474
Simplify the code by noting that when we have square end-caps, the
results of generic line path give the right pixel-aligned rectangle
for horizontal/vertical lines.
Add comments and remove some extra braces.
https://bugzilla.gnome.org/show_bug.cgi?id=630426
Currently mutter-window has its own type field, even though the same
information is already present in meta_window.
And while at it get rid of MetaCompWindowType, it is equally redundant.
https://bugzilla.gnome.org/show_bug.cgi?id=630363
