Commit Graph

6220 Commits

Author SHA1 Message Date
Owen W. Taylor
97a4cc8c9b Make handling of windows that don't respond to _NET_WM_SYNC_REQUEST reliable
Previously, we were handling failure to respond to _NET_WM_SYNC_REQUEST
in the code path for throttling motion events. But this meant that
if a window didn't respond to _NET_WM_SYNC_REQUEST and there were no
motion events - for a keyboard resize, or after the end of the grab
operation - it would end up in a stuck state.

Use a separate per-window timeout to reliably catch the failure to respond
to _NET_WM_SYNC_REQUEST.

https://bugzilla.gnome.org/show_bug.cgi?id=694046
2013-03-14 08:01:28 -04:00
Owen W. Taylor
592374bc62 Fix freezing of windows with keyboard resizing
During resizing we froze window updates when configuring the
window, and unfroze the window updates when processing the
next resize. This wasn't absolutely reliable, because we might
not have a next resize. Instead tie window freezing more
directly to the current sync request value - a window is
frozen until it catches up with the last value we sent it
in _NET_WM_SYNC_REQUEST.

Testing with unresponsive clients showed that there was a bug
where window->disable_sync once set, would not actually disable
sync, but it *would* disable noticing that the client was
unresponsive for the next resize. Fix that by checking for
->disable_sync before sending _NET_WM_SYNC_REQUEST.

https://bugzilla.gnome.org/show_bug.cgi?id=694046
2013-03-14 07:59:57 -04:00
Sweta Kothari
2e0f979613 Updated gujarati file 2013-03-14 13:41:57 +05:30
Mattias Põldaru
6d365a700c [l10n] Updated Estonian translation 2013-03-13 13:04:47 +02:00
Carles Ferrando
72a9eb6a3e [l10n] Updated Catalan (Valencian) translation 2013-03-12 22:58:27 +01:00
Gil Forcada
ae3cfe6c01 [l10n] Updated Catalan translation 2013-03-12 22:58:01 +01:00
Changwoo Ryu
da557cb712 Updated Korean translation 2013-03-13 03:53:18 +09:00
Milo Casagrande
c1e41d558f [l10n] Updated Italian translation. 2013-03-12 18:35:52 +01:00
Giovanni Campagna
889844b004 Compositor: sync stacking of window actors even if they're not parented to the window groups
Window actors might be temporarily parented to intermediate actors during
effect, but we should not require that the plugin keeps track of stacking.
Rather, assume that the intermediate groups holds a whole stack, and
applying position within it.

https://bugzilla.gnome.org/show_bug.cgi?id=695711
2013-03-12 17:58:00 +01:00
Sweta Kothari
6311a3ebc1 Updated gujarati file 2013-03-12 16:08:20 +05:30
Duarte Loreto
0f6c1db2ba Updated Portuguese translation and converted to New Spelling (Novo AO) 2013-03-12 00:22:32 +00:00
Мирослав Николић
e6ec1abbfa Updated Serbian translation 2013-03-11 11:42:33 +01:00
Khaled Hosny
42621c960e Update Arabic translation 2013-03-09 22:48:51 +02:00
Jan Kyselica
8e9ae2eb50 Updated Slovak translation 2013-03-09 18:00:00 +00:00
Dimitris Spingos
ca7843372c Updated Greek translation 2013-03-09 09:03:20 +02:00
Matej Urbančič
1202714428 Updated Slovenian translation 2013-03-07 17:17:09 +01:00
Nilamdyuti Goswami
45addabe5d Assamese translation updated for gnome 3.8 2013-03-07 19:34:39 +05:30
Ihar Hrachyshka
31abad0ea5 Updated Belarusian translation. 2013-03-07 16:24:11 +03:00
Rafael Ferreira
c169d29836 Updated Brazilian Portuguese translation 2013-03-07 01:30:45 -03:00
Chao-Hsiung Liao
df8ad83cec Updated Traditional Chinese translation(Hong Kong and Taiwan) 2013-03-06 19:12:21 +08:00
Adel Gadllah
381a9c2650 core: Remove the eventqueue
It is unused.

https://bugzilla.gnome.org/show_bug.cgi?id=695269
2013-03-06 09:17:12 +01:00
Florian Müllner
dc3529d98a Bump version to 3.7.91
Update NEWS.
2013-03-04 22:29:13 +01:00
Ray Strode
e15bc37225 compositor: map overlay window before redirecting windows
When windows get redirected off screen, all that gets left behind
is black. We don't want to flicker black at startup, though.

This commit maps the overlay window early, before redirecting
toplevels, so they end up getting snapshotted onto the background
pixmap of the overlay window when the overlay window is mapped.

https://bugzilla.gnome.org/show_bug.cgi?id=694321
2013-03-04 16:16:56 -05:00
Ray Strode
160150d127 compositor: don't show stage right away
We don't want the stage shown until gnome-shell is ready for it.
This commit ensures the stage isn't shown implicitly.

https://bugzilla.gnome.org/show_bug.cgi?id=694321
2013-03-04 16:16:56 -05:00
Owen W. Taylor
6e02fb80c4 Always send _NET_WM_FRAME_DRAWN for newly created windows
Send a _NET_WM_FRAME_DRAWN for each newly created window, as required
by the specification. This avoids a race where a window might be created
frozen but already unfrozen by the time we first see fetch the
counter value.

Remove a duplicate call to meta_compositor_set_updates_frozen() which
was called before the MetaWindowActor is created and hence did nothing.

https://bugzilla.gnome.org/show_bug.cgi?id=694771
2013-03-04 15:36:13 -05:00
Pavel Vasin
98b0a37442 Free memory allocated by XIQueryPointer()
https://bugzilla.gnome.org/show_bug.cgi?id=695135
2013-03-04 19:07:23 +01:00
Pavel Vasin
4d437e32e0 window-actor: Fix leaked frame list
https://bugzilla.gnome.org/show_bug.cgi?id=695135
2013-03-04 19:07:23 +01:00
Pavel Vasin
7db236b2a4 window-actor: Fix leaked opaque_region
https://bugzilla.gnome.org/show_bug.cgi?id=695135
2013-03-04 19:07:23 +01:00
Ray Strode
377e2ed8a5 keybindings: filter overlay key even when not-modal
mutter currently only filters the overlay key through the shell
when there is a grab operation and that grab operation belongs to the
shell (because the shell is pushModal'd). This means the shell can't
filter out overlay key press events events at startup (since the shell
isn't normally modal).

This commit changes the code to always run the shell filtering code,
even when the shell is not modal.

https://bugzilla.gnome.org/show_bug.cgi?id=694837
2013-03-04 11:57:17 -05:00
Kjartan Maraas
99cfbac473 Updated Norwegian bokmål translation 2013-03-04 14:57:49 +01:00
Daniel Mustieles
34f06ee9e5 Updated Spanish translation 2013-03-04 14:53:05 +01:00
Fran Diéguez
f212723e71 Updated Galician translations 2013-03-04 14:20:30 +01:00
Rui Matos
660eceb61a compositor: Fix ClutterTimeline usage
Use the correct 'stopped' signal name and callback signature.

https://bugzilla.gnome.org/show_bug.cgi?id=695093
2013-03-04 00:25:19 +01:00
Jasper St. Pierre
d395d75e26 Fix up for latest Clutter deprecations
https://bugzilla.gnome.org/show_bug.cgi?id=678917
2013-03-03 16:23:32 -05:00
Mario Blättermann
2aea49a8d0 [l10n] Updated German translation 2013-03-03 16:31:28 +01:00
Adel Gadllah
c996dde5cb meta-window-group: Report a paint volume
We never paint outside of the allocation so we can simply use
clutter_paint_volume_set_from_allocation.

https://bugzilla.gnome.org/show_bug.cgi?id=694988
2013-03-03 11:46:06 +01:00
A S Alam
4bdd985faf Punjabi: Translation updated (aalam) 2013-03-03 07:11:00 +05:30
Ray Strode
6e831c88a6 compositor: fix background vignette for non-stretched styles
The background vignette currently fits itself to the painted
texture, instead of the monitor.  This causes some very
wrong looking drawing for backgrounds that don't fill the screen.

This commit reworks the vignette shader code to be clearer, more
correct, and parameterized so that it knows how to scale and
position the vignette.

https://bugzilla.gnome.org/show_bug.cgi?id=694393
2013-03-02 17:31:43 -05:00
Ray Strode
0e3d164117 compositor: when tiling background, center on screen
The WALLPAPER style of background painting currently
draws starting in the upper left corner of each monitor.

This isn't really correct, it means the seam between
monitors doesn't match up and edges look unbalanced if
the tile isn't a multipe of monitor size.

Really, the tiles should be centered in the middle of
the screen.  (Just like when tiling a bathroom floor,
tiles should start in the center of the room.)

This commit reworks the math to make that happen.

https://bugzilla.gnome.org/show_bug.cgi?id=694393
2013-03-02 17:30:32 -05:00
Aurimas Černius
ec6460382c Updated Lithuanian translation 2013-03-02 22:57:48 +02:00
Adel Gadllah
436d3ff8a9 compositor: Make sure we always call the post_paint handlers
Commit 4f2bb583bf started to use a clutter_threads_add_repaint_func_full
callback instead of connecting to the stage's paint signal.

The callback has to return TRUE if it wants to be called again, so fix that
as we want to call it for every frame (otherwise apps supporting the WM SYNC
protocol will stop drawing).

https://bugzilla.gnome.org/show_bug.cgi?id=695006
2013-03-02 18:24:31 +01:00
Adel Gadllah
e4269002ce meta-background-group: Report a paint volume
We never paint outside of the allocation so we can simply use
clutter_paint_volume_set_from_allocation.

https://bugzilla.gnome.org/show_bug.cgi?id=694988
2013-03-02 15:31:10 +01:00
Adel Gadllah
4f2bb583bf compositor: Don't connect to the stage's paint signal
Doing so causes useless full stage redraws and breaks culling
as clutter cannot know how the signal handler affects painting.

So use clutter_threads_add_repaint_func_full with the
CLUTTER_REPAINT_FLAGS_POST_PAINT flag instead.

https://bugzilla.gnome.org/show_bug.cgi?id=694988
2013-03-02 14:42:06 +01:00
Nguyễn Thái Ngọc Duy
702f3fc691 Updated Vietnamese translation 2013-03-02 18:04:34 +07:00
Nguyễn Thái Ngọc Duy
4cad9513b4 po/vi: import from Damned Lies 2013-03-02 18:00:15 +07:00
Piotr Drąg
24974816a6 Updated Polish translation 2013-03-02 01:53:43 +01:00
Ray Strode
773ae8dc65 core: make session registration an explicit step
gnome-shell shouldn't announce to the session manager it's
"ready" until it's fully initialized.  It currently tells
the session manager it's ready as soon as it hits the main
loop. This causes nautilus in classic mode to start before
we have workspaces initialized.

https://bugzilla.gnome.org/show_bug.cgi?id=694876
2013-03-01 11:30:07 -05:00
Florian Müllner
7f14298126 prefs: Use an unsigned value for META_KEYBINDING_ACTION_NONE
Keybinding actions are unsigned, so it is a tad bit odd to use a
negative value for NONE and rely on implicit casting.
Use 0 instead.

https://bugzilla.gnome.org/show_bug.cgi?id=643111
2013-03-01 16:11:44 +01:00
Florian Müllner
a39cabfadb keybindings: Add external grab API
During compositor grabs, all global keybindings that don't go
through mutter's keybinding system are blocked. To allow other
processes to make use of it, gnome-shell will expose a simple
grab API on DBus; for this, add API to grab key combos directly
instead of parsing accelerators stored in GSettings.

https://bugzilla.gnome.org/show_bug.cgi?id=643111
2013-03-01 16:11:43 +01:00
Florian Müllner
4df3e987c6 keybindings: Generalize mechanism to generate dynamic keybinding actions
https://bugzilla.gnome.org/show_bug.cgi?id=643111
2013-03-01 16:11:42 +01:00