Commit Graph

768 Commits

Author SHA1 Message Date
Tomeu Vizoso
9281a1c191 Escape a few < and > from the API docs
https://bugzilla.gnome.org/show_bug.cgi?id=676856
2013-03-14 17:56:36 -04:00
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
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
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
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
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
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
Ray Strode
de36d51b91 screen: fix meta_screen_get_monitor_for_rect for 0x0 rects
meta_screen_get_monitor_for_rect will return the monitor that
a given rect belongs in (choosing the "best" monitor based on
overlap, if there are overlapping monitors).

It doesn't work with 0x0 rects, though.

This commit fixes that.

https://bugzilla.gnome.org/show_bug.cgi?id=694725
2013-02-27 21:35:30 -05:00
Giovanni Campagna
e6d5e98c9d MetaWindow: fix annotation
caller-allocates makes sense only for structure, and gjs will complain
if used on anything else

https://bugzilla.gnome.org/show_bug.cgi?id=694801
2013-02-27 18:00:01 +01:00
Adel Gadllah
2a773e0c85 window: Add get_all_monitors
Add a method that returns the indices of the monitors a window
is on.

https://bugzilla.gnome.org/show_bug.cgi?id=646861
2013-02-25 22:05:42 +01:00
Ray Strode
2cafb8be2d window: fix meta_window_is_remote across hostname changes
meta_window_is_remote compares a cached copy of the system hostname
with the hostname of the client window
(as presented by the WM_CLIENT_MACHINE property).

Of course, the system hostname can change at any time, so caching
it is wrong. Also, the WM_CLIENT_MACHINE property won't necessarily
change when the system hostname changes, so comparing it with the
new system hostname is wrong, too.

This commit makes the code call gethostname() at the time
WM_CLIENT_MACHINE is set, check whether it's remote then, and cache
that value, rather than comparing potentially out of sync hostnames
later.

https://bugzilla.gnome.org/show_bug.cgi?id=688716
2013-02-20 16:02:10 -05:00
Ray Strode
64544fa0ed window: deduplicate is_remote logic
set_title_text does the equivalent of meta_window_is_remote on its
own.

This commit changes set_title_text to just use meta_window_is_remote.

https://bugzilla.gnome.org/show_bug.cgi?id=688716
2013-02-20 15:28:31 -05:00
Jasper St. Pierre
7e61ef0936 display: Don't put minimized windows at the back of alt-tab
Minimizing a window should not change its position in the alt-tab
list.

https://bugzilla.gnome.org/show_bug.cgi?id=693991
2013-02-18 13:11:55 -05:00
Adel Gadllah
e9709b7ff9 window: Add is_screen_sized method
Add a method that returns whether the window occupies
the whole screen (i.e all montiors).
2013-02-18 14:10:27 +01:00
Giovanni Campagna
027593faa5 Keybindings: reverse key combination read from settings
Window menus use the first key combination for a binding to show the
acceleration, so the list must be in the right configured order, which
is the opposite of what's built by g_slist_prepend()

https://bugzilla.gnome.org/show_bug.cgi?id=694045
2013-02-17 21:52:19 +01:00
Jasper St. Pierre
b0774d795c screen: Select for pointer events on the guard window
The guard window is effectively the background window, as it sits
in between live windows and minimized windows. This gives us a nice
easy place to allow users to allow users to right-click or long-press
on the wallpaper.

https://bugzilla.gnome.org/show_bug.cgi?id=681540
2013-02-17 15:43:38 -05:00
Adel Gadllah
a6a9d3f448 window: Add meta_window_is_monitor_sized
We duplicate this checks in multiple places so lets add this to
avoid code duplication.
2013-02-17 21:42:01 +01:00
Owen W. Taylor
d900d83522 MetaWindowActor: Go back to freezing affecting actor geometry
We do, in fact, need freezing to affect window geometry, so that
move-resize operations (such as an interactive resize from the
left, or a resize of a popup centered by the application) occur
atomically.

So to make map effects work properly, only exclude the initial
placement of a window from freezing. (In the future, we may want
to consider whether pure moves of a window being done in response
to a user drag should also be excluded from freezing.)

Rename meta_window_sync_actor_position() to
meta_window_sync_actor_geometry() for clarity.

https://bugzilla.gnome.org/show_bug.cgi?id=693922
2013-02-15 21:48:25 -05:00
Jasper St. Pierre
e8b0c11703 barrier: Add a time field to MetaBarrierEvent
This was used in gnome-shell, but last-minute changes and multiple
branch confusion on my part meant the field actually never got added.

https://bugzilla.gnome.org/show_bug.cgi?id=693854
2013-02-15 16:49:03 -05:00
Owen W. Taylor
3e38a48c40 meta_spew_xi2_event: fix crash-causing typo 2013-02-15 15:52:34 -05:00
Owen W. Taylor
5876f2e3e5 Fix corner cases where _NET_WM_FRAME_DRAWN might be missed
The WM spec requires _NET_WM_FRAME_DRAWN to *always* be sent when
there is an appropriate update to the sync counter value. We were
potentially missing _NET_WM_FRAME_DRAWN when an application did a
spontaneous update during an interactive resize and during effects.
Refactor the code to always send _NET_WM_FRAME_DRAWN, even when
a window is frozen.

https://bugzilla.gnome.org/show_bug.cgi?id=693833
2013-02-14 16:21:26 -05:00
Owen W. Taylor
aeb589c176 MetaWindow: fix detecting the response to an extended _NET_WM_SYNC_REQUEST
During resizing, An odd counter value (indicating the beginning of a frame)
shouldn't cause us to redraw and start a new frame, only an even counter
value. This was causing the frozen state for the window frame counter to
overlap the frozen state for the resize, causing the window not to be
updated.

https://bugzilla.gnome.org/show_bug.cgi?id=693833
2013-02-14 16:21:14 -05:00
Adel Gadllah
579bf2105e display: Pass timestamp to meta_display_end_grab_op
We need to pass the timestamp not the event detail to meta_display_end_grab_op

https://bugzilla.gnome.org/show_bug.cgi?id=690580
2013-02-13 18:32:57 +01:00
Owen W. Taylor
0503f6bb9a Consistently use meta_grab_op_is_resizing() for _NET_WM_SYNC_REQUEST
In different places we checked the grab op differently when determing
whether we are using _NET_WM_SYNC_REQUEST. This was somewhat covered
up previously by the fact that we only had a sync alarm when using
_NET_WM_SYNC_REQUEST, but that is no longer the case, so consistently
use meta_grab_op_is_resizing() everywhere.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:27 -05:00
Owen W. Taylor
87fe9685b5 Distinguish "no delay" frames from spontaneous drawing
When a client is drawing as hard as possible (without sleeping
between frames) we need to draw as soon possible, since sleeping
will decrease the effective frame rate shown to the user, and
can also result in the system never kicking out of power-saving
mode because it doesn't look fully utilized.

Use the amount the client increments the counter value by when
ending the frame to distinguish these cases:

 - Increment by 1: a no-delay frame
 - Increment by more than 1: a non-urgent frame, handle normally

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:27 -05:00
Owen W. Taylor
fcc178ee8c Use XSyncSetPriority()
Use XSyncSetPriority() to prioritize the compositor above applications
for X server priority. In practice, this makes little difference because
the Xorg "smart scheduler" will schedule in a single application for
time slices that exceed the frame drawing time, but it's theoretically
right and might make a difference if the X server scheduler is improved.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Owen W. Taylor
790bfcad9a MetaWindow: always resize the frame first when we have synchronization
Resizing the frame triggers creation of a new backing pixmap for the
window, so we should do that first before we resize the client window
and mess up the contents of the old backing pixmap.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Owen W. Taylor
fbfab93c63 Send _NET_WM_FRAME_DRAWN messages
When the application provides the extended second counter for
_NET_WM_SYNC_REQUEST, send a client message with completion
information after the next redraw after each counter update
by the application.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Owen W. Taylor
70c0d39fa7 Add support for an extended style of _NET_WM_SYNC_REQUEST_COUNTER
If an application provides two values in _NET_WM_SYNC_REQUEST_COUNTER,
use that as a signal that the applications wants an extended behavior
where it can update the counter as well as the window manager. If the
application updates the counter to an odd value, updates of the
window are frozen until the counter is updated again to an even value.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Owen W. Taylor
7d43bde019 Support properties with lists of XSyncCounter
Add META_PROP_VALUE_SYNC_COUNTER_LIST for a property that contains
multiple XSyncCounter values.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:26 -05:00
Owen W. Taylor
7743c70d47 Move sync alarms to be per-window and permanent
Instead of creating a new alarm each time we resize a window
interactively, create an alarm the first time we resize a window
and keep it around permanently until we unmanage the window.
Doing it this way will be useful when we allow the application to
spontaneously generate sync request updates to indicate
frames it is drawing.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:48:25 -05:00
Owen W. Taylor
c9343e3ee3 Implement freezing of updates during resize
Replace the unused meta_compositor_set_updates() with
a reversed-meaning meta_compositor_set_updates_frozen(), and use
it to implement freezing application window updates during
interactive resizing. This avoids drawing new areas of the window
with blank content before the application has a chance to repaint.

https://bugzilla.gnome.org/show_bug.cgi?id=685463
2013-02-13 09:40:07 -05:00
Adel Gadllah
2942b22ccf screen: Don't try to move / resize OR windows on montior change
meta_screen_resize calls meta_window_update_for_monitors_changed for all
windows including OR windows when the monitors change (or screen size).

This calls meta_window_move_between_rects for the window which attempts to
move the OR window by calling meta_window_move_resize.

meta_window_move_resize refuses to do anything on OR windows (just returns
for OR windows).

This causes a storm of assert messages when the screen
resolution changes while an OR window is visible.
(like the one gnome-control-center displays with the monitor name).

Fix that by not calling meta_window_update_for_monitors_changed for OR windows
and let the applications handle them by themselves.

https://bugzilla.gnome.org/show_bug.cgi?id=693540
2013-02-10 20:43:03 +01:00
Adel Gadllah
a362c08f4e Fix build error introduced by d482590c84 2013-02-09 17:02:36 +01:00
Rui Matos
380154af0a screen: Fix a potentially endless loop
We always need to move the list pointer forward.

https://bugzilla.gnome.org/show_bug.cgi?id=693475
2013-02-09 16:07:59 +01:00
Adel Gadllah
d482590c84 Fix button check in meta_window_client_message
Fixes a regression introduced in 3a3be74e37

https://bugzilla.gnome.org/show_bug.cgi?id=692718
2013-02-09 13:17:42 +01:00
Tim Lunn
b3c572b8e3 barrier: fix fallback for unsupported servers
add missing ifdef HAVE_XI23.

https://bugzilla.gnome.org/show_bug.cgi?id=677215
2013-02-09 11:27:22 +11:00
Jasper St. Pierre
c64eb94724 display: Remove an unused code path for enabling the compositor 2013-02-08 14:36:20 -05:00
Jasper St. Pierre
d8f569eaf5 display: Rename window_ids to xids
As the hash table no longer stores only window IDs, we should rename it so
that we make sure to check if something is actually a window before using it
as a window.

https://bugzilla.gnome.org/show_bug.cgi?id=677215
2013-02-08 14:23:38 -05:00
Jasper St. Pierre
57c31a56f4 barrier: Add support for new barrier features in XInput 2.3
XInput 2.3 adds support for "barrier events", which let us know when
a pointer barrier has been hit, and when the pointer has stopped
hitting the barrier, and lets us "release" the barrier, temporarily
letting the pointer pass through the barrier. These features can be
combined to allow for certain pointer gestures, such as "pushing"
against the bottom of the screen, or stopping the pointer on monitor
edges while dragging slowly for increased edge precision.

This commit should allow graceful fallback if servers with
XInput 2.3 aren't supported.

https://bugzilla.gnome.org/show_bug.cgi?id=677215
2013-02-08 14:23:38 -05:00
Jasper St. Pierre
8b21df92f0 barrier: Add a new Meta wrapper for pointer barriers
Currently, we have a few function wrappers in the shell for pointer
barriers. If we want to implement interactive features on barriers,
we need some sort of signal to be notified of the interactivity.
In that case, we need to make a more sophisticated object-based wrapper
for a pointer barrier. Add one, and stick it in mutter.

https://bugzilla.gnome.org/show_bug.cgi?id=677215
2013-02-08 14:23:38 -05:00
Adel Gadllah
a2a3188331 Fix compiler warnings 2013-02-08 00:22:54 +01:00
Jasper St. Pierre
453020c315 Make sure to include the old XI2 mask when selecting for events
Some windows may already have event masks on them that we've selected
for, especially if we're using GTK+ windows. In particular, this fixes
window menus in the XI2 port.

https://bugzilla.gnome.org/show_bug.cgi?id=690581
2013-02-07 18:13:40 -05:00
Jasper St. Pierre
d794db876a core: Add a helper function to grab the old event mask of a window
https://bugzilla.gnome.org/show_bug.cgi?id=690581
2013-02-07 17:53:53 -05:00
Jasper St. Pierre
a613a55658 Support _NET_WM_OPAQUE_REGION
This new hint allows compositors to know what portions of a window
will be obscured, as a region above them is opaque. For an RGB window,
possible to glean this information from the bounding shape region of
a client window, but not for an ARGB32 window. This new hint allows
clients that use ARGB32 windows to say which part of the window is
opaque, allowing this sort of optimization.

https://bugzilla.gnome.org/show_bug.cgi?id=679901
2013-02-06 00:08:04 -05:00
Jasper St. Pierre
32b7743735 screen: Add an introspectible wrapper for find_monitor_for_rect
Instead of returning a MonitorInfo, it returns a monitor index.

https://bugzilla.gnome.org/show_bug.cgi?id=692679
2013-02-06 00:04:15 -05:00
Jasper St. Pierre
093e101252 Make work_area calculation funcs public and introspectible
https://bugzilla.gnome.org/show_bug.cgi?id=692679
2013-02-06 00:03:47 -05:00