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
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
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
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
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
These sounds are good candidates for caching in the sound server, to
save a bit of CPU and make reaction faster. Hence, tell libcanberra to
cache them.
https://bugzilla.gnome.org/show_bug.cgi?id=609585
Right now metacity issues only 1 bell event per second. This is
feels buggy when triggering multiple alarm sounds in a terminal.
This patch simple increases the limit to 1/100ms. 100ms is probably a
good choice since the HIG recommends that all user reaction should
happen within 100ms. With this applied pressing 'Left' in gnome-terminal
feels much more responsive.
https://bugzilla.redhat.com/show_bug.cgi?id=498608https://bugzilla.gnome.org/show_bug.cgi?id=609585
* src/core/bell.c: Don't force CA_PROP_CANBERRA_ENABLE to 1.
That was a misunderstanding on my part, and makes it impossible
to get rid of the bell.
svn path=/trunk/; revision=4165
https://bugzilla.gnome.org/show_bug.cgi?id=609585
* src/core/bell.c (meta_bell_set_audible): Now that we are
using libcanberra, don't tell the X server to play the system
bell internally.
svn path=/trunk/; revision=4141
https://bugzilla.gnome.org/show_bug.cgi?id=609585
metacity tries to do the right thing, by preloading all the relevant
directories before getting the keys one-by-one, but GConfClient isn't actually
smart enough to avoid server roundtrips in this case. That should certainly be
fixed in GConf.
In the meantime, here is a patch that reworks the metacity prefs initialization
to avoid roundtrips for individual keys anyway, by using
gconf_client_all_keys().
https://bugzilla.gnome.org/show_bug.cgi?id=574121https://bugzilla.gnome.org/show_bug.cgi?id=607746
The ICE connection is opened by libSM; we can't just close it when
we get an IOError on the ICE connection; instead call SmcCloseConnection()
and mark the connection as closed. This will prevent a segfault if we
exit out of the metacity main loop and get to meta_finalize().
https://bugzilla.gnome.org/show_bug.cgi?id=604867
Windows demanding attention should never appear in the alt-tab list
unless they're of a type which might have appeared there anyway. This
solves a problem under AWN where docks which were marked as demanding
attention appeared in all alt-tab lists; they were irrelevant and it
was impossible to remove them from the lists.
svn path=/trunk/; revision=4123
(This is inspired by Metacity commit 45cbaa2 by Thomas Thurman, but
much simpler - the use of g_date_strftime("%Y") ended up being just
%d for all 90+ current translations)
meta_workspace_set_builtin_struts() is slightly expensive; it involves
discarding all our cached computed information about the layout of the
workspace. So catch calls to set_builtin_struts() that don't change
anything.
https://bugzilla.gnome.org/show_bug.cgi?id=609546
Since meta_workspace_invalidate_work_area() frees the edges
workspace->screen_edges and workspace->monitor_edges, we must clean up
our cached edge resistance data when the invalidate_work_area() is
called on the active workspace, or when the workspace changes.
Make the computation of the edge resistance data lazy so that it
will be recomputed the next time we try to access it.
meta_display_compute_resistance_and_snapping_edges() is made
private to edge-resistance.c
Invaliding the data when active workspace changes also will improve
correctness for edge resistance when the current workspace changes
during a grab operation. (Even with this fix we still don't try to
handle window positions changing during a grab operation; that can't
cause a crash since, unlike screen and monitor edges, the window edges
are freshly allocated, it will just cause slight oddness in that
corner case.)
Root cause tracked down due to much effort by Jon Nettleton.
https://bugzilla.gnome.org/show_bug.cgi?id=608800
When putting 32-bit properties into longs on 64-bit architectures,
XGetWindowProperty assumes the values are supposed to be signed, and
so it sign-extends values greater than 0x7fffffff. So if they *aren't*
supposed to be signed, we need to chop off the high bits ourselves.
(Most CARDINAL-valued properties only end up using small values
anyway, so it doesn't matter, but _NET_WM_WINDOW_OPACITY uses the full
range, and so was previously failing on 64-bit machines.)
https://bugzilla.gnome.org/show_bug.cgi?id=605678
The commit that removed metacity-dialog added a global SIGCHLD handler
that caused problems by (a) calling waitpid(-1) and thus breaking
g_child_watch for everyone else, and (b) doing too much from a signal
handler and sometimes causing deadlocks (bug 596200).
This removes the global handler and has each zenity user create its
own child watch to watch for exit. (It also fixes the window class of
the zenity dialogs, so that meta_window_present_delete_dialog() will
work again.)
Having a MetaDisplay::window-demands-attention signal allows to deal with
windows demanding attention in a cetralized fashion.
The signal is emitted when a window is created with initial demands-attention
state and/or when the state changes later on.
Based on original patch by Jon Nettleton.
https://bugzilla.gnome.org/show_bug.cgi?id=597052
With the change from bug 582639, we no longer call the reload
functions for properties that are not initially set, so the
initialization of fields in window.c has to match what
window-props.c would set for a missing property.
There was only one discrepancy, window->input, which needs
to be set to TRUE by default (or a window missing a WM_HINTS
property won't get focus); we also add explicit initializers
for a couple of fields that were getting 0-initialized
to the correct default value of FALSE for consistency with
the explicit intialization of the rest of the fields.
Bug reported by Dominique Leuenberger
https://bugzilla.gnome.org/show_bug.cgi?id=601228
