Since the stack passed to the compositor now accurately reflects
the X stacking order, we need to treat hidden windows (which are
at the bottom of the X stacking order) specially - when the
compositor stacking order is synced, try to keep animating hidden
actors in their old positions in the stack.
http://bugzilla.gnome.org/show_bug.cgi?id=585984
With MetaStackTracker, it's no longer necessary to XQueryTree to
get a reasonably-up-to-date view of the server stacking order.
Add some comments explaining unclear aspects of
raise_window_relative_to_managed_windows() and with future possible
improvements.
http://bugzilla.gnome.org/show_bug.cgi?id=585984
Don't add override-redirect windows to MetaStack; we shouldn't
be restacking them.
Since we *aren't* stacking the override-redirect windows, we need to
be careful that to ignore them when looking for the top managed
window.
http://bugzilla.gnome.org/show_bug.cgi?id=585984
In order to properly track the stacking order for override-redirect
windows, move meta_compositor_sync_stack() call into MetaStackTracker.
In the new location, we sync the stack as a before-redraw idle function,
rather then using the freeze-thaw facilities of MetaStack. This is
simpler, and also properly compresses multiple stack changes on
notifications received from the X server.
http://bugzilla.gnome.org/show_bug.cgi?id=585984
Wedging override-redirect windows into the constraint code in stack.c
results in Mutter getting confused about the stacking order of
these windows with respect to other windows, and may also in some
cases cause Mutter to restack override-redirect windows.
core/stack-tracker.c core/stack-tracker.h: MetaStackTracker - combine
events received from the X server with local changes we have made
to come up with the best possible idea of what the stacking order
is at any one point in time.
core/screen.c core/screen-private.h: Create a MetaStackTracker for
the screen.
core/display.c: Feed relevant events to MetaStackTracker
core/frame.c core/screen.c core/stack.c: When we make changes to the
stacking order or add windows, record those changes immediatley
in MetaStackTracker so we have the information without waiting
for a round-trip.
include/ui.h ui/ui.c: meta_ui_create_frame_window add a return value
for the X request serial used to create the window.
http://bugzilla.gnome.org/show_bug.cgi?id=585984
Override-redirect windows should not be moved or resized by the
window manager.
- Mark override-redirect windows as already placed to avoid
placing them when first shown.
- Don't move-resize newly created override-redirect MetaWindow
- Don't queue a resize on override-redirect windows when reading
their WM_TRANSIENT_FOR hint.
- Add g_return_if_fail (!window->override_redirect) to catch
unexpected code paths that might result in override-redirect
windows being moved or resized.
http://bugzilla.gnome.org/show_bug.cgi?id=582639
Normally a window that is "on all workspaces", is also on a particular
workspace (to deal with being unstuck.) This is pointless for
override-redirect windows.
http://bugzilla.gnome.org/show_bug.cgi?id=582639
Don't include override-redirect windows when iterating the windows
in the screen. We don't need them for any of the current uses:
- Queueing redraws and resizes on managed windows
- Checking which windows should be added to a new workspace
http://bugzilla.gnome.org/show_bug.cgi?id=582639
Don't include override-redirect windows in the list return by
meta_display_list_windows(), since we almost never want to handle
them when considering "all window" for the display. Add a separate
meta_display_list_all_windows() that includes override-redirect
windows.
http://bugzilla.gnome.org/show_bug.cgi?id=582639
Skipping handling of properties for override redirect windows has
two advantages: first it reduces the amount of work needed to get
an override-redirect window (menu, tooltip, drag icon) onto the
screen. But more importantly, it reduces the number of code-paths
for an override-redirect to get into some code portion where it
isn't expected.
* Integrate the list of properties we load initially with the
list of property hooks; this avoids having two separate lists
that we have to keep in sync.
* Add a flag to MetaWindowPropHooks to indicate whether the
property should be handled for override-redirect windows;
currently we load a) properties that identify the window -
useful for debugging purposes b) WM_TRANSIENT_FOR (could be
used to associate menus with toplevels.)
* For properties that aren't always loaded through window-props.c,
add !window->override checks to places that trigger loading,
and add g_return_if_fail(!window->override) to the load
functions as a double-check.
http://bugzilla.gnome.org/show_bug.cgi?id=582639
Add g_return_if_fail() to check that window-management functions like
meta_window_maximize() aren't called on override-redirect windows.
This reveals that were were "unminimizing" override-redirect windows
when adding them; avoid doing that.
http://bugzilla.gnome.org/show_bug.cgi?id=582639
If a property has a reload function, but the standard property-fetching
mechanism isn't used (hooks->type == META_PROP_VALUE_INVALID), then the
a logic error (introduced in January) caused the hook to never be run.
This meant that changes to struts and icons weren't noticed.
Same as: http://bugzilla.gnome.org/show_bug.cgi?id=572573
The fix here is different in detail from that applied to Metacity, but
similar in spirit.
http://bugzilla.gnome.org/show_bug.cgi?id=585980
On subsequent changes, if there is a NET_WM_USER_TIME_WINDOW, then
read the property from that rather than from the main window.
(Fix an accidental regression: the right Window was being computed
but no longer passed in.)
http://bugzilla.gnome.org/show_bug.cgi?id=585979
Since --with-clutter and --with-introspection refer to use of external
libraries, they should in fact be --with and not --enable. Fix accidental
change that got committed as part of the big metacity => mutter change.
http://bugzilla.gnome.org/show_bug.cgi?id=586821
This reverts commit 16d49695ad.
If we want an actor to go away deterministically, we should call
clutter_actor_destroy(); using unparent instead a) may result
leaks through cyclic ref counts, and b) will delay the deallocation
of the window texture in a garbage collected environment until
the next garbage collection, causing much greater transient use
of memory.
http://bugzilla.gnome.org/show_bug.cgi?id=580520
info->pending_input_region needed to be destroyed in
mutter_set_stage_input_region() before it was set to something
else or before it was reset to be full screen (region == None).
Set the initial input area to an empty region by
setting info->pending_input_region to an empty region by default
and setting it to None or a new region if a new input region is
specified.
Remove show_overlay_window() function that was used to set an empty
input region on start-up, and uses a call to do_set_stage_input_region()
with info->pending_input_region as an argument instead.
When we add a window and it gets hidden as the first thing, we need
to show not just the frame window, but also the window itself.
Otherwise when the window subsequently becomes visible, it will
just be an empty frame.
Add helper functions to reduce current code duplication and avoid
adding more.
http://bugzilla.gnome.org/show_bug.cgi?id=586309
Code:
All references in the code not related to themes, keybindings, or
GConf were changed from 'metacity' to 'mutter'. This includes, among other
things, strings, comments, the atoms used in the message protocol, and
the envvars used for debugging. The GConf schema file was reduced to
the 3 settings new to mutter.
The overall version was brought up to 2.27 to match current gnome.
Structure:
All files named '*metacity*' were renamed '*mutter*' with appropriate
changes in the automake system. Files removed are
doc/creating_themes, src/themes, doc/metacity-theme.dtd,
metacity.doap. These files will eventually end up in an external
gnome-wm-data module.
Installation location:
On the filesystem the mutter-plugindir was change from
$(libdir)/metacity/plugins/clutter to just $(libdir)/mutter/plugins.
The mutter-plugins.pc.in reflects these changes.
Note:
mutter.desktop.in and mutter-wm.desktop both continue to have
X-GNOME-WMSettingsModule=metacity set. This allows
gnome-control-center to continue using libmetacity.so for
configuration. This is fine since most the general keybindings and wm
settings are being read from /apps/metacity/* in gconf.
Change #define _XOPEN_SOURCE 500 to 600 in compositor-xrender.c to
avoid a bad interaction with -xc99 on Solaris.
Remove unneeded #define in compositor-mutter.c.
Based on a patch by Brian Cameron
http://bugzilla.gnome.org/show_bug.cgi?id=580662
Cogl's default blend function has been switched to expect premultiplied
alpha. Change the combine function and the colors we use to
modulate alpha to match.
http://bugzilla.gnome.org/show_bug.cgi?id=585480
It doesn't make sense to allow the window texture to be sliced,
but not allow the mask texture to be sliced. So, we should either
set 'disable-slicing' for the texture actor or not pass NO_SLICING when
creating the mask texture.
While slicing currently results in only the first layer being shown,
disabling slicing entirely would break windows larger than the texture
size limit. It would be straightforward to support multitexturing of
sliced textures in Cogl when all the textures are identically sized
and sliced identically, if it became a priority.
http://bugzilla.gnome.org/show_bug.cgi?id=585151
- Use float instead of ClutterUnit
- clutter_actor_get_size/position() return floats (remove some
stray usage of these functions in the default plugin as well.)
- Adapt to cogl_texture_new_from_data() changes
- Use blend strings to set up multitexturing
- Remove CLUTTER_UNITS_TO_FLOAT() usage
http://bugzilla.gnome.org/show_bug.cgi?id=585016
If the input region has been shaped, then clutter needs to
receive EnterNotify/LeaveNotify events in order to properly
send enter and leave events to actors when the pointer crosses
the boundary of the stage.
http://bugzilla.gnome.org/show_bug.cgi?id=578250
Also, use MetaWindows as the tab_popup keys rather than using (X) Windows
and then having to map back and forth everywhere, which is silly since
we never actually want the X Window.
http://bugzilla.gnome.org/show_bug.cgi?id=580917
Rather than trying to reverse-engineer what kind of tab/workspace
popup to create from within meta_display_begin_grab_op(), just create
the popup directly from do_choose_window()/handle_workspace_switch()
after completing the grab, since they already know which kind they
want.
Also add meta_screen_destroy_tab_popup()/_destroy_workspace_popup()
rather than having meta_display_end_grab_op() poke into MetaScreen's
internals itself.
http://bugzilla.gnome.org/show_bug.cgi?id=580917
