Commit Graph

7916 Commits

Author SHA1 Message Date
Florian Müllner
4e14bb9df3 window: Fix corner case in set_demands_attention()
We only grant requests to set the demands-attention hint if the window
is at least partially obscured; so for non-minimized windows on the
active workspace, we check if any other window on the same workspace
that is higher in the stack overlaps.
However in the case of a sticky window, window->workspace is NULL, so
we end up considering any non-sticky window on a different workspace.

At this point we have already established that the window is showing
on the active workspace, so use that to filter for windows that may
overlap.
2014-09-27 06:43:16 +02:00
Florian Müllner
df90545258 window: Fix crash when mapping sticky window
Since the introduction of set_workspace_state(), window->workspace
will always be NULL when on_all_workspaces is set - passing that
to a workspace function that does not validate its input will then
result in a crash.
Use the get_workspace() function instead, which will always return
a valid workspace.
2014-09-27 06:41:35 +02:00
Florian Müllner
c954f9cc24 workspace: Fix typo in META_IS_WORKSPACE macro 2014-09-27 06:37:38 +02:00
Florian Müllner
d06b39d13c window: Fix another case of uninitialized workspace state
Since commit 2eec11b445, windows without a __NET_WM_DESKTOP property
that should be on all workspaces are not added to the active workspace;
this is correct, however not adding them to any workspace is not ...
2014-09-26 11:48:11 +01:00
Jasper St. Pierre
f3595ebd08 monitor-manager: Make sure to emit PropertiesChanged for PowerSaveMode
We overrode the property for PowerSaveMode, which meant that gdbus's
auto-generated PropertiesChanged code wasn't being run.

This really confused gnome-rr and gnome-settings-daemon's power plugin
about the current DPMS state of the display, since they used their
cached PowerSaveMode properties, and never saw a PropertiesChanged being
emitted.

If a display was on, they set it to off, and then set it back on, the
setting back on would never fire, since they thought the display was
already off.

To fix this, remove our custom property override and just respond to
notifications on the object.

Namely, this fixes the DPMS management when receiving notifications so
that it now properly times out.
2014-09-25 20:17:53 -06:00
Florian Müllner
1e1ca47ec1 window: Always set workspace state while constructing
set_workspace_state () returns early when the desired sticky state
and workspace match the current property values, assuming that the
corresponding MRU lists are already correct in that case.
However that might not be the case when we are setting the initial
state, so don't take the shortcut in that case.

https://bugzilla.gnome.org/show_bug.cgi?id=737178
2014-09-25 15:16:09 +01:00
Florian Müllner
2eec11b445 window: Be more careful when setting initial workspace state
A window may either be sticky because it has been requested as such,
or because it is placed on a non-primary monitor (and the corresponding
preference is set). While we do take the latter into account, we
currently override the sticky state later during initialization;
be a bit more careful there to get the initial state right.

https://bugzilla.gnome.org/show_bug.cgi?id=737178
2014-09-25 15:16:09 +01:00
Saibal Ray
8ff4597201 Updated Bengali (India) translation 2014-09-25 08:26:38 +00:00
Alexander Shopov
d5f2468d88 Updated Bulgarian translation 2014-09-25 06:28:04 +03:00
Jasper St. Pierre
488dd0b402 Support for hardware cursor sizes other than 64x64 on wayland
Use the new DRM capabilities to figure out the correct cursor size, and
make sure that matches instead of hardcoding 64x64. This fixes incorrect
rendering on some newer AMD cards that support 256x256 cursors.

Based heavily on a patch by:
Alvaro Fernando García <alvarofernandogarcia@gmail.com>
2014-09-24 15:42:17 -06:00
Jasper St. Pierre
6565bca210 wayland: Send accurate capabilities
mutter now knows whether the app menu should be shown, so expose this
properly under Wayland as well.
2014-09-24 15:42:17 -06:00
Rui Matos
60c22b6236 keybindings: Do a breadth first search in our keysym to keycode code
Commit 1af0033368 made a subtle change
regarding how XKeysymToKeycode behaves. It does a depth first search
while XKeysymToKeycode is documented to do a breadth first search:

"this function looks in each column of the core keyboard mapping in
turn and returns the lowest numbered key that matches in the lowest
numbered group" - from the XKB library documentation

Looping over all keycodes for each layout and level index makes us go
back to the previous behavior.

https://bugzilla.gnome.org/show_bug.cgi?id=737134
2014-09-24 23:20:42 +02:00
Owen W. Taylor
d3111a9f07 Fix stacking of the guard window
With the change to how hidden windows are stacked, the position
of the guard window with respect to the hidden windows got flipped
and the guard window was at the bottom of everything; fix it to
be on top of the hidden windows.

https://bugzilla.gnome.org/show_bug.cgi?id=737233
2014-09-24 16:51:20 -04:00
Owen W. Taylor
cdfb301200 Add a test for stacking vs. minimization
Test that the guard window is in the right place.

https://bugzilla.gnome.org/show_bug.cgi?id=737233
2014-09-24 16:51:20 -04:00
Owen W. Taylor
371560c2b6 tests: Add minimize/unminimize commands
Add commands to request the client to minimize or unminimize the window;
unminimize doesn't currently work for GTK+ because it expects XMapRequest
to be received by the window manager, but the window is already mapped.

https://bugzilla.gnome.org/show_bug.cgi?id=737233
2014-09-24 16:26:17 -04:00
Owen W. Taylor
7616881afa test-runner: represent the guard window as '|' for assert_stacking
Allow putting '|' into the list of windows for assert_stacking to
represent the position of the guard window. Not present is the same
as at the beginning (bottom) of the list.

https://bugzilla.gnome.org/show_bug.cgi?id=737233
2014-09-24 16:26:17 -04:00
Owen W. Taylor
74c37d49c4 test-runner: make test_case_wait() wait for queued-work
Sometimes (for example with minimization) a request from the client
causes queued work rather than immediate work; so make the test client
'wait' command wait for a full frame cycle.

https://bugzilla.gnome.org/show_bug.cgi?id=737233
2014-09-24 16:26:17 -04:00
Мирослав Николић
d3142b92f0 Updated Serbian translation 2014-09-24 11:10:30 +02:00
Krishnababu Krothapalli
ae2afa7c5e Updated Telugu translation 2014-09-23 14:48:16 +00:00
Florian Müllner
4a71621fbc keybindings: Fix indentation 2014-09-22 22:01:37 +02:00
Florian Müllner
565b9d73d5 keybindings: Do not depend on linux headers for above-tab key
Commit 2f229c3928 removed the code to compute the above-tab
keycode and replaced it with a simple constant from linux/input.h.
We obviously cannot depend on linux headers on non-linux systems,
so provide a fallback definition in that case (which is expected
to work assuming the system is using the Xorg xf86-input-keyboard
driver).

https://bugzilla.gnome.org/show_bug.cgi?id=737135
2014-09-22 21:54:48 +02:00
Florian Müllner
90bd02ff4d constraints: Fix update_onscreen_requirements()
Another missing translation into screen coordinates ...

https://bugzilla.gnome.org/show_bug.cgi?id=736915
2014-09-22 20:12:08 +02:00
Florian Müllner
73ca0efaeb window: Fix titlebar_is_onscreen() test
The titlebar rect is in window coordinates, while screen regions are
obviously not. Fix by translating into screen coordinates before
testing for overlaps.

https://bugzilla.gnome.org/show_bug.cgi?id=736915
2014-09-22 20:12:08 +02:00
Florian Müllner
790269db95 Bump version to 3.14.0
Update NEWS.
2014-09-22 20:12:08 +02:00
Rajesh Ranjan
cb82bd8afa Updated Hindi translation 2014-09-22 13:23:07 +00:00
Petr Kovar
b1e06ed110 Update Czech translation 2014-09-22 15:02:04 +02:00
Shankar Prasad
fabe66e65f Updated Kannada translation 2014-09-22 05:14:51 +00:00
Bernd Homuth
4a965a37d1 Updated German translation 2014-09-21 19:20:16 +00:00
YunQiang Su
302ff7b95a update zh_CN translation 2014-09-21 10:15:01 +08:00
Ask H. Larsen
e2e241340c Updated Danish translation 2014-09-20 17:22:51 +02:00
Jasper St. Pierre
461aea47dd window: Adjust the frame rect when _GTK_FRAME_EXTENTS is set on map 2014-09-19 17:35:38 -06:00
Jasper St. Pierre
d87093fe29 window: Don't queue move/resizes if the extents are the same
GTK+ sets the frame extents on every allocation, so don't bother doing
any extra work if things are the same.
2014-09-19 17:35:38 -06:00
Jasper St. Pierre
0cde7879d6 window: Move set_custom_frame_extents to be X11-only
Wayland doesn't use custom frame extents anymore -- it uses a full
geometry description.
2014-09-19 17:35:38 -06:00
Owen W. Taylor
89ffcee7ca Fix computation of window positions for StaticGravity
When adjust_for_gravity() was simplified (01b6445708), the correct
handling of StaticGravity dropped out - fix adjust_for_gravity() to do
nothing in that case.

https://bugzilla.gnome.org/show_bug.cgi?id=736719
2014-09-19 15:41:22 -04:00
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