In order to replace calls to deprecated GDK code, the current
development version of GTK+ is required. Add some basic compatibility
code to allow building mutter with GTK+ 2.18.
https://bugzilla.gnome.org/show_bug.cgi?id=587991
The current effect API passes an unnecessary list of windows to
switch_workspace() and forces a window to be passed in when killing
the switch_workspace() effect.
We can simplify the interface to correspond more closely to how
it is actually used and fix these problems:
Remove the actors parameter to plugin->switch_workspace
Remove the events parameter to plugin->kill_effect and rename it to kill_window_effects
Add plugin->kill_switch_workspace
Remove mutter_plugin_manager_kill_effect
Add mutter_plugin_manager_kill_window_effects
Add mutter_plugin_manager_kill_switch_workspace
Remove mutter_plugin_effect_completed
Add mutter_plugin_[minimize/map/destroy/maximize/unmaximize]_completed
https://bugzilla.gnome.org/show_bug.cgi?id=621082
A mismerge of the Metacity commit "4943d79 Prevent window self-maximisation"
caused the window's user set size and position to be saved *before*
actually resizing the window to the unmaximized position rather than after.
This meant that after unmaximization the window was in an inconsistent
state and anything that caused a resize to be queued (like a change in
window properties by the application) would cause it to pop back to
the maximized size and position.
https://bugzilla.gnome.org/show_bug.cgi?id=621413
It's useful for plugins to be able to easily detect whether
or not a window is from a remote host. Also, make use of this
in the window delete codepath, instead of looking up the hostname
each time.
https://bugzilla.gnome.org/show_bug.cgi?id=620585
While debugging a focus problem, I noticed that Mutter had exactly
the debug statements I wanted under the META_DEBUG_FOCUS topic.
However, calling meta_set_verbose (true) results in enormous amounts
of other messages, and it's inconvenient to filter after having
started mutter.
This patch allows one to call Meta.add_debug_topic(Meta.DebugTopic.FOCUS)
from a console, and get just what one wants.
https://bugzilla.gnome.org/show_bug.cgi?id=620359
In commit d34ae764769 I switched mutter-window to ask for Raw rectangles
from the X server. This avoided 2 non synchronous and 2 synchronous X
requests per window with damage, per frame; 2 (non-sync) to
create/destroy a temporary region to copy the damage region into, 1 to
request the server to copy the damage region into a our given region and
another to fetch that region back into the client. The problem with raw
events though is that it's possible to DOS the compositor with them.
Instead of receiving an event for every bit of damage this patch instead
asks the server to only report BoundingBox changes to the damage region.
https://bugzilla.gnome.org/show_bug.cgi?id=611838
This function returns xid of the WM leader window (as defined by the
_NET_SUPPORTING_WM_CHECK mechanism of EWMH). For use by plugins that wish to
attach custom properties to this window.
https://bugzilla.gnome.org/show_bug.cgi?id=613125
Changing the number of workspaces via an external pager relies on the gconf
key; if a plugin adds or removes workspaces on the fly, we can get into a
situation when the stale number stored by the preferences matches the new
number requested by the pager, in which case the pager request becomes a nop.
This commit ensures that when the meta_screen_append_new_workspace() or
meta_screen_remove_workspace() functions are called, the stored value is
updated accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=613127
A per-window _MUTTER_HINTS property allowing plugins to use custom hints. The
property holds a colon separated list of key=value pairs; plugin-specific keys
must be suitably namespaced, while 'mutter-' prefix is reserved for internal
Mutter use only.
This commit adds MetaWindow::mutter-hints property, and
meta_window_get_mutter_hints() accessor, as well as the internal machinery for
reading and updating of the hints.
https://bugzilla.gnome.org/show_bug.cgi?id=613123
To replace all calls to deprecated code, GTK+ 2.20 is required - add
some basic compatibility code, so that it is still possible to build
mutter with GTK+ 2.18 when not using -DGSEAL_ENABLE.
https://bugzilla.gnome.org/show_bug.cgi?id=595496
COGL bug http://bugzilla.openedhand.com/show_bug.cgi?id=2110 results
in pending drawing at the time of cogl_offscreen_new_to_texture() going
to the newly created framebuffer rather than the stage.
This would result in most windows being missing for the first frame
when a new window is mapped.
Work around this by calling cogl_flush() before
cogl_offscreen_new_to_texture().
https://bugzilla.gnome.org/show_bug.cgi?id=618138
The beginning maximization/unmaximization don't go through
start_effect_simple(), so we need to freeze the window
separately.
Change MutterWindow.freeze_count to a signed integer for
consistency with other counts, and so the logic for
checking for errors works properly.
https://bugzilla.gnome.org/show_bug.cgi?id=616546
This changes the way we handle Damage events so instead of getting an
event when the damage region of a pixmap becomes non-empty we now get
sent all damage rectangles and stream those all though to
ClutterX11TexturePixmap using clutter_x11_texture_pixmap_update_area()
For Clutter 1.2, ClutterGLXTexturePixmap was updated so that calls to
clutter_x11_texture_pixmap_update_area are now cheap (glXBindTexImageEXT
calls are now deferred until just before painting) and since
ClutterGLXTexturePixmap is now capable of queueing clipped redraws that
can result in only updating a sub-region of the stage during a repaint
cycle (and using glXCopySubBufferMESA to present the sub-region redraw
to the front buffer) this should improve performance and reduced power
consumption for a range of use cases. (For example viewing a website
that has animated adverts doesn't force the whole screen to be redrawn
for each frame of the advert)
Besides being able to take advantage of glXCopySubBuffer to only update
a small region of the stage the fact that this patch makes Mutter now
request RawRectangles from the X server means we no longer do a
synchronous X request for a complete Damage Region for every window
damaged each frame. This should also improve performance.
CLUTTER_PAINT=redraws can be used to visualize what parts of the stage
are redrawn and with this patch applied I can open a terminal and as I
type I see that only the damaged areas of the terminal are being
redrawn.
In the case where a mutter window is created for an X Window that is
already mapped then we weren't calling mutter_window_mark_for_repair and
so we weren't calling XCompositeNameWindowPixmap e.g. for menu windows.
This doesn't get noticed because as soon as some damage gets delivered
for such windows the pixmap will be named anyway, but if we were to
change how damage is handled this would result in broken menus.
We now call mutter_window_mark_for_repair in mutter_window_new when the
given Window is already mapped.
It's nice to indicate when a title is truncated with an ellipsis.
Because themes may draw a title multiple times to draw a shadow, or
may include the window icon within the title area, we can't determine
the proper ellipsization width automatically, so add an optional
attribute to the <title/> element "ellipsize_width" which, if set,
is the width to ellipsize at.
This is only enabled if a theme version of 3.1 is required.
When it's not set, we keep the old behavior of just letting the
title be clipped with a hard edge.
https://bugzilla.gnome.org/show_bug.cgi?id=591842
Sometimes you want to position something (usually the title) to be centered
with respect to the entire frame instead of centered with respect to the
individual piece currently being drawn.
This patch adds frame_x_center and frame_y_center variables that represent
the X/Y centers of the frame in the coordinate system of the piece being
drawn.
The theme version is bumped from 3.0 to 3.1 (3.0 is just the new version
system, 3.1 will have all the features we add for Mutter-2.28.)
position expressions
https://bugzilla.gnome.org/show_bug.cgi?id=591842
Although multi-screen support has not been tested and probably
doesn't fully work, the basic setup for multi-screen is that
we have the same list of plugins for all screens, but a different
instance of the plugins for each screen.
To allow plugins to do setup that is screen independent and needs
to occur early in the setup process, we identify a "default plugin
manager" and load (but not start) that plugin manager's plugins
immediately after we know our list of plugins.
That plugin manager is then reused for the first screen we open
and the plugins are started at that time. Separate plugin managers
are loaded and started for any other screens we open.
(A plugin could keep track of whether the screen-independent
setup has been done in a static variable, or it could do everything
in a way that is safe to do repeatedly.)
https://bugzilla.gnome.org/show_bug.cgi?id=615586
