Commit Graph

7832 Commits

Author SHA1 Message Date
Owen W. Taylor
1250afef7b Revert "window-x11: Fix the coordinates we use in the synthetic ConfigureNotify"
The coordinates in ConfigureNotify *should* be the coordinates of the
client window; using the coordinates of the frame window compensated for
a problem with the interpretation of StaticGravity for some clients but
broke other clients.

This reverts commit f4f70afe31.

https://bugzilla.gnome.org/show_bug.cgi?id=736719
2014-09-19 15:41:22 -04:00
Christian Kirbach
3a577edaa7 Updated German translation 2014-09-18 21:55:42 +00:00
Jasper St. Pierre
48dfde2073 keyboard/pointer: Calculate the serial once per event
Some applications, like totem, create keyboard/pointer objects from the
same client, and expect it to work. We made this work a while ago, but
due to an oversight in the code, we increment the serial on button press
for every resource that we need to send events to.

Since operations like move/resize use the grab serial of the devices to
determine whether the operation is exact, we need to make sure the same
serial goes to all devices.

Restructure the code so that all that's in the resource loop is the
sending of the event -- all the calculation that's needed happens
outside.

This fixes moving / resizing the Totem window not working sometimes.

https://bugzilla.gnome.org/show_bug.cgi?id=736840
2014-09-18 09:15:13 -06:00
Jasper St. Pierre
4a41d415f8 wayland: Fix the placement of popup windows
The fix in d61dde1 regressed the position of popup windows, since the
size was 0x0 when we wanted to do a sole move. Only fizzle out in the
path where we actually *do* resize.

https://bugzilla.gnome.org/show_bug.cgi?id=736812
2014-09-17 17:42:37 +02:00
Manoj Kumar Giri
1fb7ca398d Updated Oriya translation 2014-09-17 11:27:43 +00:00
Dušan Kazik
2b79935fd8 Updated Slovak translation 2014-09-17 09:10:51 +00:00
Saibal Ray
e3c915350e Updated Bengali (India) translation 2014-09-17 06:30:41 +00:00
Florian Müllner
2e06a6765c Bump version to 3.13.92
Update NEWS.
2014-09-17 06:14:24 +02:00
Florian Müllner
b63291069d docs: Allow building without wayland 2014-09-17 05:37:54 +02:00
Florian Müllner
f10cb02cbf prefs: Show fallback app menu based on XSetting
Going through GSD's settings was done in context of patches that
did not land; it is simpler and more consistent with GTK+ to use
the corresponding XSetting instead.
2014-09-17 05:37:53 +02:00
Jasper St. Pierre
276df8f18d keyboard/pointer: Make sure to move focused resources into the list
We only broadcast input to the focus_resource_list, so we need to make
sure it's put in the proper list on startup.

This fixes input not working for windows when they first appear.

Argh. There's always more stuff to fix with keyboard/pointer. Every
single time I think I've fixed it, more stuff pops up.
2014-09-16 21:25:26 -06:00
Jasper St. Pierre
d61dde12cb window-wayland: Don't send 1x1 sizes to GTK+ windows
GTK+ requests get_xdg_surface before attaching a buffer, and since it
might take a long time for GTK+ to get around to attaching a buffer and
committing it, our idle for MOVE_RESIZE will kick in beforehand.

And our idle will try to resize the 0x0 window that currently exists,
constrain it to 1x1, which will send a configure event of 1x1 to the
window while it boots up, causing it to awkwardly resize to the minimum
size of the window.

Make sure that in this case, our idle doesn't cause any problems, and
that we fizzle out any idles like this.

The "proper" way to do this would be to delay the creation of the
MetaWindow until a surface is committed, but that's difficult for a
variety of reasons, and might cause unintended issues with focus.
2014-09-16 21:14:19 -06:00
Jasper St. Pierre
c8cc4344f2 events: Only process Enter/Leave events when in the normal route
This prevents issues from happening when processing Enter/Leave events
while in another kind of grab op like a Wayland popup or resizing a
window.

This can't ever really happen except outside of a race condition,
with the X server, since we won't ever pass input events to the
X server in any of these cases, but it can't hurt to be more correct
about what the intended operation is.
2014-09-16 20:31:13 -06:00
Jasper St. Pierre
ae292c856b events: Ignore normal FocusIn events on the root window
GTK+ focuses its own windows with RevertToParent, which means that when
a GTK+ CSD window is destroyed, the X server will set the focus back to
the root window. The event stream that we is an UnmapNotify followed by
a FocusOut event. Our own UnmapNotify-handling code unmanages the window
and forcibly changes the focus to the next default window in the stack.

Since UnmapNotify events don't come with timestamps, we query for one,
and set the window focus using that.

But there's *still* a FocusOut event in the stack, with an older
timestamp and serial than our own focusing. We see this, throw it out
since it's older than the most recent focus, but then our own code that
notices the root has been focused kicks in and tries to focus the
default window... using a timestamp older than our most recent focusing.

meta_display_sanity_check_timestamps notices this, and (rightly so)
puts a warning in our face, telling something is awry.

Only let our workarounds kick in when the event is new enough, otherwise
our code will get confused over old events.

This stops the:

Window manager warning: last_focus_time (367917173) is greater than comparison timestamp (367917170).  This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW.  Trying to work around...

warning spam when closing a CSD window.
2014-09-16 20:25:51 -06:00
Jasper St. Pierre
35dd1e644d events: Remove our workarounds for broken libXi versions
We now depend on a recent enough libXi that fixes broken locking in
XIGrabTouchBegin, so we don't need to carry this around anymore.
2014-09-16 20:10:59 -06:00
Jasper St. Pierre
be85ead2f8 events: Fix a typo preventing the None detection from working properly
XINotifyDetailNone is a value for detail, not for mode.
2014-09-16 19:53:33 -06:00
Jasper St. Pierre
5c40345128 window-wayland: Don't bother checking if anything changed
This is a small fixup. We don't need the check here, since we don't do
anything extra if it actually changed.
2014-09-16 19:16:38 -06:00
Jasper St. Pierre
43b3573c51 window-wayland: Always update the last_sent size
The last_sent size is effectively what size we should send in configure
requests where the size hasn't changed. Thus, if an app commits a new
size, we need to make sure we respect it and don't reconfigure it with
a size it wasn't expecting when the state changes.

This fixes apps being sent a configure event with 0, 0 on startup,
which was confusing Clutter into displaying a 0x0 viewport.
2014-09-16 19:11:56 -06:00
Jasper St. Pierre
ac6ec168da pointer: Make coding style similar to keyboard 2014-09-16 18:55:49 -06:00
Jasper St. Pierre
dbb7b9e85b events: Remove an overzealous ifdef 2014-09-16 18:55:46 -06:00
Jasper St. Pierre
1de740955f wayland: Don't leak the existing texture if we already have one
We were missing a check in ensure_buffer_texture that checked if we
already had a CoglTexture bound for the buffer.
2014-09-16 12:12:21 -06:00
Owen W. Taylor
21f123c69f Don't restack windows while we are unmanaging them
Restacking the frame for a window while unmanaging the window is
harmless, but for undecorated (in particular, client-side-decorated)
windows, this causes problems because the window is typically
destroyed by the client immediately after withredrawing the window.

Skip windows flagged as being unmanaged when assembling the new
stack and when comparing the old order to the new stack.

Add a stacking test for this.
2014-09-16 13:44:42 -04:00
Owen W. Taylor
d6624b0a75 Cleanup xwayland/wayland window association from the "unmanage" signal
Windows can be freed at some point after they are unmanaged - because
there is an effect in progress, because a language binding is holding
a reference. Therefore, we need to clean up the later to associate
the xwayland and wayland windows deterministically in an "unamanaged"
handler.

https://bugzilla.gnome.org/show_bug.cgi?id=736694
2014-09-16 10:59:45 -04:00
Owen W. Taylor
9c465a2d5a Do xwayland/wayland window association in a later, not an idle
g_idle_add() makes no guarantee about when it will be run - if Mutter
is busy drawing and blocking glXSwapBuffers() it could happen only
minutes later.  Use meta_later_add (META_LATER_BEFORE_REDRAW) instead -
this will deterministically be run after the Wayland socket is read
from but before the next frame is painted.

https://bugzilla.gnome.org/show_bug.cgi?id=736694
2014-09-16 10:59:45 -04:00
Owen W. Taylor
e53456d87c mutter-test-runner: Make criticals and warnings failures
Tests should not be counted as successful if Mutter is spewing
warnings - hook to the log handler so that we can catch that.
2014-09-16 10:59:45 -04:00
Owen W. Taylor
5716fc4b90 test-runner: Add 'csd' keyword for window creation
Allow specifying 'csd' when creating a window to make the client
create a client-side-decorated window.
2014-09-16 10:59:45 -04:00
Mattias Eriksson
e926ebafdb Updated Swedish translation 2014-09-15 15:34:10 +00:00
Jasper St. Pierre
7125b801f2 Makefile-tests: Our test framework requires Wayland 2014-09-15 09:11:38 -06:00
Jasper St. Pierre
d20dae3553 prefs: Don't listen to the cursor-size key
It will only confuse the code if somebody changes
it. gnome-settings-daemon already listens to this, so just use that.
2014-09-14 23:26:06 -06:00
Carles Ferrando
73a47cec2a [l10n] Updated Catalan (Valencian) translation 2014-09-14 22:15:28 +02:00
Gil Forcada
514d3b4bde [l10n] Update Catalan translation 2014-09-14 22:15:28 +02:00
Shantha kumar
6910ab5389 Updated Tamil translation 2014-09-14 19:53:05 +00:00
Sandeep Sheshrao Shedmake
4052b0f048 Updated Marathi translations 2014-09-14 21:17:19 +05:30
Adel Gadllah
493c0f71d2 prefs: Update cursor size based on xsettings
We shouldn't scale the cursor size in mutter we g-s-d exports
the correct size on hidpi so use gtk-cursor-theme-size.

This way we also catch changes on resolution updates.

https://bugzilla.gnome.org/show_bug.cgi?id=729337
2014-09-14 10:21:46 +02:00
Adel Gadllah
ab40dfdd51 Revert "prefs: Scale the root window cursor by the scale factor"
This reverts commit 4fe66ce0a9.

This is wrong ... we should not scale the cursor size but read
the cursor xsettings that gets exported by gsd. Also this won't update on
resolution changes.

https://bugzilla.gnome.org/show_bug.cgi?id=729337
2014-09-14 10:21:46 +02:00
A S Alam
52678c39e6 update Punjabi Translation - back for 3.14 2014-09-13 21:58:41 -05:00
Jasper St. Pierre
a676249c0c stack-tracker: Fix an off-by-one error in restack_managed
When restacking the last window alone, we would trigger this off-by-one
error. This would throw us off the end of the array, causing lower_below
warnings for nonsensical values.

Since the last window already is lowered below everything else, we
shouldn't need to lower it.
2014-09-12 17:10:34 -06:00
Jasper St. Pierre
2833c702c6 stack-tracker: Make lower_below / raise_above internal as well
These are unused elsewhere.
2014-09-12 16:56:27 -06:00
Owen W. Taylor
611f6741c2 windows-x11.c: Fix leaked error trap
The merge of the commit af46ef3b 'meta_window_new: clean up error handling'
to the wayland branch accidentally added an extra call to meta_error_trap_push(),
meaning that we leaked one level of error traps for each new window.

Fixes warning:
  Gdk-WARNING **: XSetErrorHandler() called with a GDK error trap pushed.

https://bugzilla.gnome.org/show_bug.cgi?id=736589
2014-09-12 17:28:53 -04:00
Owen W. Taylor
df2587a61c Don't pass configure events on the composite overlay window to MetaStackTracker
When the screen resizes, we get a configure event for the composite overlay
window - don't pass that to MetaStackTracker, since the COW isn't in the
stack.

Fixes warning:
 mutter-WARNING **: STACK_OP_RAISE_ABOVE: window 0x65 not in stack
2014-09-12 16:37:20 -04:00
Owen W. Taylor
30e7044746 display: Refix return value of set_alarm_filter 2014-09-12 15:12:09 -04:00
Owen W. Taylor
458953268b MetaBackground: fix getting stuck in a bad state after monitor changes
After the ::monitors-changed signal, set the dirty flag on each new
monitor information struct so the per-monitor resources will be
recreated.
2014-09-12 14:59:20 -04:00
Jasper St. Pierre
1c227baf81 display: Fix return value of set_alarm_filter 2014-09-12 12:55:07 -06:00
Jasper St. Pierre
892699da73 edid: Remove unused declarations 2014-09-12 11:55:08 -06:00
Owen W. Taylor
f163a15b13 MetaStackTracker: optimize out unnecessary X restacking
We have a quite accurate view of the X stack, so there's no good reason to ask
the X server to do restacking that has no effect. (Restackings that have no
effect on either X windows or Wayland windows were generally optimized out in
the synchronization code, but in other cases like moving an X window that is
only beneath Wayland windows to the top of the stack we would make such
requests.)

Removing such requests:
 - Is a small efficiency win in itself
 - Allows us to immediately go ahead and apply Wayland changes to the verified stack
 - Prevents queued Wayland changes piling up waiting for an X event that will never
   be received, since the X server will not send confirmation of no-op restacks.

Since such operations may still have an effect on the relative stacking of X
and Wayland windows, we need to continue applying them to the local stack.

https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-12 13:42:56 -04:00
Owen W. Taylor
87779ed34e MetaStackTracker: make functions used only internally static
Now that all actual stack shuffle is handled inside stack-tracker.c, we can make
meta_stack_tracker_record_[raise_above/lower_below] internal to that file and
remove the unused meta_stack_tracker_record_lower().

https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-12 13:42:56 -04:00
Owen W. Taylor
04bc846ef3 Move logic for syncing the stack to the X server into MetaStackTracker
stack.c:sync_stack_to_xserver had both code for assembling the desired stack, and
code for enforcing the desired stack on the actual stack of X and Wayland windows;
the latter part is properly the domain of stack-tracker.c; moving the code to
apply the stack there both simplifies it and keeps stack.c more manageable.

https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-12 13:42:56 -04:00
Owen W. Taylor
301acac163 stack.c: remove obsolete handling of override-redirect windows
There was still code in stack.c to handle skipping override-redirect windows,
but since quite a while ago, meta_stack_add() is not called for OR windows
since they are outside our stacking control. Add an assertion and remove
unnecessary code.

https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-12 13:42:56 -04:00
Owen W. Taylor
9401196e88 Remove cache of last stacking order in stack.c
stack.c kept it's own record of the last stacking it requested, so that
restacking could be done with minimal moves, but we already have a better
view of the stacking order with the stack tracker, so use that instead.

This allows eliminating the special case for the first restack.

https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-12 13:42:56 -04:00
Owen W. Taylor
3457366066 Move manipulation of the X stack to MetaStackTracker
Since MetaStackTracker is the code that knows about the current X stacking order
and the relationship between X windows and Wayland windows, it's cleaner to
encapsulate stack manipulation in MetaStackTracker rather than have the calling
code make the X calls and only call into MetaStackTracker to inform it about
the changes.

https://bugzilla.gnome.org/show_bug.cgi?id=736559
2014-09-12 13:42:56 -04:00