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
For some consumers it's significantly more convenient to be able
to directly connect to a signal on the Window to know when
Mutter is done with it, rather than having to connect to each
Workspace object (and handle workspace additions, etc.).
Similarly, add window-created which acts globally.
https://bugzilla.gnome.org/show_bug.cgi?id=598289
When we focus a window on a different desktop, and the calc_showing
idle that hides/shows the windows gets run before we get focus events
back from X, we think that we are hiding the window with the focus
so we focus a "random" window to avoid leaving the user with no focus.
Work around this temporarily by checking display->expected_focus_window;
this isn't a perfect fix because there are cases where
display->expected_focus_window corresponds to a window we tried to
focus in the past but failed, but it makes things work fairly well.
https://bugzilla.gnome.org/show_bug.cgi?id=597352
When we create the timeline dummy timeline to ensure that our later
functions that should be run during repaint get called called, pass in
G_MAXUINT to make the duration very long, not 0. (It will get reset
whenever there is no repaint later to run, so the fact that G_MAXUINT
is only ~40 days isn't a problem.)
This fixes a warning from Clutter, but also a real problem.
There was a problem where if, for example, a restack was triggered
out of a clutter event handler, then after Clutter processed the
events, it would proceed immmediately on to repaint the stage without
ever returning control to the GLib main loop. So even though we
had an idle handler installed with a higher priority than the
Clutter stage repainting the clutter stage repainting would happen
first and we'd get a wrong frame.
Fix this by introducing the idea of "later functions", which abstract
the idea of "doing something later" away from g_idle_add() and use
a combination of GLib idle functions and Clutter "repaint functions"
to get our callbacks triggered at the right time, even when they
are installed from a clutter event handler.
https://bugzilla.gnome.org/show_bug.cgi?id=596334
This also resolve a FIXME where MUTTER_PRIORITY_BEFORE_REDRAW
could starve stage repainting.
We need a way to indicate to gnome-control-center that we want the
keybindings capplet to show the Window Manager keybindings for Metacity;
do this through a _GNOME_WM_KEYBINDING property we put on the
_NET_SUPPORTING_WM_CHECK window and set to Mutter,Metacity.
See http://bugzilla.gnome.org/show_bug.cgi?id=594066 for the
gnome-control-center part of this.
http://bugzilla.gnome.org/show_bug.cgi?id=594067
