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
Add mutter.doap with the module description
Move the old MAINTAINERS to METACITY_MAINTAINERS
List Tomas and myself as the maintainers in MAINTAINERS and mutter.doap
If mutter_plugin_set_stage_input_region() and related methods are
called before the output window is available, save the set input
region and apply it to the output window later on.
compository-mutter.[ch]: Add mutter_set_stage_input_region() and
mutter_empty_stage_input_region(), move the input region handling
here and implement the delayed shape setting described
above.
mutter-plugin.c: Implement shape setting in terms of the new methods.
http://bugzilla.gnome.org/show_bug.cgi?id=580042
Build a XML gir file and binary typelib file for the interfaces that
we are installing for plugin use. They are installed into $(pkglibdir)
since they are private to the application.
http://bugzilla.gnome.org/show_bug.cgi?id=580041
Using G_MODULE_BIND_LOCAL causes problems for introspecting plugins,
since introspected symbols need to be globally available. And in
any case, trying to use linker features to prevent symbol conflicts
doesn't usually work out very well, it's better to just namespace
properly.
http://bugzilla.gnome.org/show_bug.cgi?id=580033
Add separate mutter_plugin_manager_load() and
mutter_plugin_manager_initialize() calls so that we can just
load the plugins without start them. This is useful for introspecting
a gnome-shell plugin at build time.
http://bugzilla.gnome.org/show_bug.cgi?id=580032
Always compile the default keybindings into Metacity, and if we
fail to retrieve the values from GConf, use the compiled-in
value. This makes things more robust especially in an environment
like JHBuild where GConf-schema-installation may not work
correctly.
Also use these values for the no-GConf case, rather than
having a separate arrray and code path.
http://bugzilla.gnome.org/show_bug.cgi?id=576127
This patch adds the concept of a special key for WM operations, and
the default is Super_L, which on extended PC hardware is the
"Windows key". What we do is handle the special case of a press
and release of this key (without any other intervening keys).
Super_L+<key> should still be passed to applications. In the future
we may want to also take some of these keybindings (e.g. Super+TAB)
though.
http://bugzilla.gnome.org/show_bug.cgi?id=563047
Add sigals to MetaWorkspace to allow tracking when windows are added
and removed. Note that on window creation that these signals are fired
before the window setup is totally complete, so they need to be used
with some care. (For example, the compositor, if present, has not
been notified of the new window.)
http://bugzilla.gnome.org/show_bug.cgi?id=580025
To guard against CompositeNameWindowPixmap failing, just use an
error trap. Previous code used:
GrabServer/GetWindowAttributes/CompositeNameWindowPixmap/UngrabServer
To prevent BadMatch errors from !viewable, but didn't check the
return value of GetWindowAttributes and didn't check if an error
occured during the error trap. This way is more correct and more
efficient.
http://bugzilla.gnome.org/show_bug.cgi?id=580023
When the window being hidden/mimimized has focus, is modal, but is not on the
currently active workspace (e.g., during workspace switch before the new
focus window is activated), we must prevent focus being passed to the modal
window ancestor (otherwise the ancestor ends up being forcefully moved onto
the active workspace).
Creating the gard window when constructing MetaScreen causes the screen to
go black for the duration of Metacity startup which is uggly. We do not
actually need that window until we are ready to manage windows on the screen.
