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
Allow a plugin to redirect preferences from one GConf location
to another GConf location. This is useful for keys that need to be
set differently in a plugin-managed environment (like GNOME Shell)
as compared to in standalone Metacity.
Overriding is implemented by overwriting the keys in the arrays
of preferences; a list of the current overrides is stored to allow
proper memory management when an override is itself overriden.
(we need to know whether to free the old keys or not)
This patch cleans up the comments in prefs.c a bit as well; some ideas
about less-exciting potential improvements were removed to make the
comments explaining the structure easier to figure out.
https://bugzilla.gnome.org/show_bug.cgi?id=615586
Rather than using the plugin objects constructed() method for doing
setup that requires the MetaScreen, add an explicit start() method
that is called after the screen is set.
The reason for this is that this allows plugin objects to be created
early before the bulk of Metacity setup, which then allows plugins
to affect how the setup happens. (For example, to change the way
that preferences are loaded.)
This is an incompatible change, since 'screen' is now not set in the
constructed method, so the plugin API version is bumped.
https://bugzilla.gnome.org/show_bug.cgi?id=615586
The current mechanism of metacity-theme-1.xml and metacity-theme-2.xml
is not flexible for allowing small-scale additions. With this patch
we bump the major version version once more to metacity-theme-3.xml
and add a single feature:
Any element in the DTD can have an attribute:
version="[<|<=|=>|>] MAJOR.MINOR"
And it will be ignored unless the predicate is met. (< and > should
be to be entity escaped as < and >)
This allows having alternate sections of the theme file for older and
newer version.
* Required GLib version is bumped to 2.14 so we can parse versions
with a regular expression.
* We switch internal version numbers to be "1000 * major + minor"
* We keep a stack of the maximum required version for the current portion
the XML tree so that the "cannot use versions you don't require" stricture
of the old code can be made local to a subpart of the tree.
* A version on the top metacity_theme element causes the entire file to
be ignored; this allows having one metacity-theme-3.xml for version 3.2
and newer (say) and a metacity-1.xml for everything old.
Actual new features will be added starting with 3.1 - 3.0 is just the
version="" feature.
http://bugzilla.gnome.org/show_bug.cgi?id=592503
Simplify code to find the right theme to load and loading it by moving
all the loading code into a load_theme() helper function, and making
meta_load_theme() use that as it searches through the directories.
Look for old-version themes even when loading relative to the working
in debug mode.
Don't unnecessarily duplicate and then free info->theme_file and
info->theme_dir.
http://bugzilla.gnome.org/show_bug.cgi?id=592503
The change to using gconf_client_all_entries() in commit 2d57b1b4
meant that workspaces without a GConf key for their name were not
getting a name at all. Fix this by doing a post-processing loop
to set workspace names that were not otherwise set.
Alternate to patch from Tomas Frydrych
https://bugzilla.gnome.org/show_bug.cgi?id=613136
Since all windows are now MetaWindows as well as compositor
windows, there's no reason to keep a compositor-specific hash table
mapping from XID to MutterWindow.
This reduces complexity and removes a call to XQueryTree that could
potentially produce a BadWindow error if not error-trapped.
https://bugzilla.gnome.org/show_bug.cgi?id=613398
meta_compositor_process_event uses meta_error_trap_push/pop for
every event processed by meta_compositor_process_event which isn't needed
and can cause performance problems.
https://bugzilla.gnome.org/show_bug.cgi?id=613398
- Specify a minimum version of Clutter-1.2.0
- Remove conditionalizatin and always use Clutter-1.1 framebuffer
API rather than raw GL fbos
- Replace deprecated cogl_material/texture_unref() with
cogl_handle_unref()
https://bugzilla.gnome.org/show_bug.cgi?id=610862
The change to reduce GConf trips by using
gconf_client_all_entries() broke the fallback to builtin values
because update_binding() was no longer called for bindings not
found in GConf. Fix this by keeping track of the bindings we
find from GConf in a hash table, then looping through and setting
all the bindings at the end.
This also improves efficiency by avoiding a linear scan for each
binding in GConf.
https://bugzilla.gnome.org/show_bug.cgi?id=609710
When we are reading bindings initially, update_list_binding() needs
to be passed the correct "string list type" since we are calling
it with a list of strings instead of a list of GConfValue.
https://bugzilla.gnome.org/show_bug.cgi?id=609101
The older code relied on Clutter providing default texture coords for any
layers for which texture coords were not specified, which does not work as
of Clutter 1.1.6 (due to commit 8b950bdc87).
https://bugzilla.gnome.org/show_bug.cgi?id=609657
Treat the empty string the same as "disabled" for GConf keybinding
keys. gnome-keybinding-properties was changed to write disabled
keys as the empty string a year or so ago.
https://bugzilla.gnome.org/show_bug.cgi?id=559816
Whether Metacity honors a raise request from an application should
not be affected by the raise_on_click setting; remove a check that
seems to have been added in error.
https://bugzilla.gnome.org/show_bug.cgi?id=445447
When we are moving a window with a modal dialog to a different
workspace, meta_workspace_focus_default_window() can be called
with 'not_this_one' being the focused modal dialog.
Since the ancestor of that window is also being moved, we must
not focus it as an alternative to the current window; this will
cause windows to be moved back and Metacity to get into an
inconsistent confused state.
https://bugzilla.redhat.com/show_bug.cgi?id=237158https://bugzilla.gnome.org/show_bug.cgi?id=598995
We currently allow XRaiseWindow when the same application (defined
by the window group) is focused, but the kind of old applications
that XRaiseWindow are frequently not setting the window group.
Expand the check to allow the same X client (defined by the looking
at client ID) to raise windows above the focus window.
https://bugzilla.gnome.org/show_bug.cgi?id=567528
When started without session related command line parameters (e.g. from
gnome-session), metacity picks up client_id from the DESKTOP_AUTOSTART_ID
environment variable. Unfortunately, there is no way to distinguish if this was
passed from a config file, representing old saved session, or generated by
gnome-session, therefore load_state is attempted in each case. If the client_id
is generated, there will be no session file, and metacity will report a
warning.
Just remove the warning so that users won't always find a warning at the
start of their .xsession-errors.
https://bugzilla.gnome.org/show_bug.cgi?id=577576
The atk-bridge GTK+ module opens its own display; if we get an
XIOError on that display, we shouldn't abort with a meta_bug()
but just exit normally. Also fix a segfault if we got an XError
for that display.
https://bugzilla.gnome.org/show_bug.cgi?id=604319
Merge all relevant changes from Metacity as of Feb 10, 2010
For future merger's reference, the best way to merge changes from
Metacity is to add the Metacity git repository as a remote, then
cherry-pick the desired changes - this will exploit the shared
history of the two repositories when merging in the changes.
Then when finished, use 'git merge -s ours <head commit of metacity>'
to record the merge, and 'git commit --amend' to fix up the
commit message.
Add a configure switch:
--with-libcanberra=[yes/no/auto]
(defaulting to auto); if libcanberra is not found or explicitly
disabled, then the default system bell will be used for the bell
sound and no switch workspace sound is played.
https://bugzilla.gnome.org/show_bug.cgi?id=609585
