- Oct 23, 2015
-
-
Carlos Garnacho authored
As per the spec. wl_pointer.axis_source determines the current source of scroll events, wl_pointer.axis_stop determines when there's no further scroll events on any axis (Which Clutter sends as dx/dy=0 events). wl_pointer.axis_frame marks the end of a series of axis_* events. v2: Updated to v4 of the protocol spec by Peter Hutterer <peter.hutterer@who-t.net> v3: Update to use Clutter API
-
- Oct 17, 2015
-
-
Carlos Garnacho authored
Right now we just check the pointer serial, so the popup will be immediately dismissed if the client passes a serial corresponding to another input device. Abstract this a bit further and add a meta_wayland_seat_can_popup() call that will check the serial all input devices. This makes it possible to trigger menus through touch or keyboard devices. https://bugzilla.gnome.org/show_bug.cgi?id=756296
-
-
- Oct 16, 2015
-
-
Rui Matos authored
We might get modes in XRROutputInfos that aren't in the XRRScreenResources we get earlier. This always seems to be transient, i.e. when it happens, the X server will usually send us a follow up RRScreenChangeNotify where we then get a "stable" view of the world again. In any case, when these glitches happen, we end up with NULL pointers in the MetaOutput->modes array which makes us crash later on. This patch ensures that doesn't happen. https://bugzilla.gnome.org/show_bug.cgi?id=756660
-
Jonas Ådahl authored
If we immediately dismiss the popup, we still need to set the surface->xdg_popup pointer field in order for the destructor to properly clean up the state. Not doing this may cause a crash if the xdg_popup resource that was immediately dismissed is destoryed after wl_surface during client destruction. https://bugzilla.gnome.org/show_bug.cgi?id=756675
-
Florian Müllner authored
We have been ignoring those buttons since 3.16 after they had been broken in the default theme for a couple of versions. As nobody appears to miss them, it's time to remove them for good.
-
Florian Müllner authored
We use a single style context to draw titlebar buttons, updating its state according to each button's prelight state as necessary. This assumes that the original state is neither ACTIVE nor PRELIGHT, which means we need to reset the state after drawing to avoid propagating the state of the last-drawn button.
-
Florian Müllner authored
This is required to tell cairo to update its cached areas.
-
- Oct 15, 2015
-
-
Florian Müllner authored
Update NEWS.
-
Florian Müllner authored
XInput2 uses the raw sequence number for XIEvent serials[0], which only matches the serial number in XEvents up to 16 bits[1]. So in order to be able to make reliable comparisons with serials from other events or calls to XNextRequest(), always use the field from the original XEvent rather than the XIEvent serial (at least until we can get libXi fixed). This (partially) reverts commit 35dd1e64. [0] http://cgit.freedesktop.org/xorg/lib/libXi/commit?id=5d43d4914dcabb6d [1] http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/XlibInt.c#n265 https://bugzilla.gnome.org/show_bug.cgi?id=756649
-
Florian Müllner authored
Since commit 527c53a2, window->workspace is set to %NULL when the window is sticky (see comment[0]), so don't try to save the workspace index in that case. [0] https://git.gnome.org/browse/mutter/tree/src/core/window.c#n4307 https://bugzilla.gnome.org/show_bug.cgi?id=756642
-
- Oct 13, 2015
-
-
- Oct 12, 2015
-
-
Cosimo Cecchi authored
We were always passing the parameter for a maximize animation.
-
Owen W. Taylor authored
A change in the code made the windows list bottom-to-top instead of top-to-bottom, but the message printed out still said "Top to bottom."
-
Owen W. Taylor authored
Displaying all Wayland windows with the XID of 0x0 makes it hard to figure out what is going on ... use the recently-added window->stamp to show Wayland windows as W1/W2/W3...
-
Owen W. Taylor authored
If end_grab_op() is called when there's a "compositor grab" rather than a grab op is in effect, silently return. https://bugzilla.gnome.org/show_bug.cgi?id=745785
-
- Oct 07, 2015
-
-
Jasper St. Pierre authored
Some windows, like Chromium and Steam, are technically CSD in that they don't want a system titlebar and draw their own, but we should still provide them with a shadow.
-
Florian Müllner authored
As design patterns have evolved, dialogs that use CSD do use titlebar buttons, so it's time to re-enable them for SSD as well. https://bugzilla.gnome.org/show_bug.cgi?id=641630
-
- Oct 06, 2015
-
-
Rui Matos authored
Both Window and XSyncCounter are XIDs which on 64 bit X clients are 8 bytes wide. But the values on the wire are 32 bit so, for these types, we always copy 4 bytes into results->prop. As such copying them out with a cast such as *(Window *) means that we are actually reading 8 bytes which depending on whether the higher addressed 4 bytes are zero means that sometimes this works while others it gives us a bogus value. https://bugzilla.gnome.org/show_bug.cgi?id=756074
-
- Oct 04, 2015
-
-
Jonas Ådahl authored
We cannot use the XSETTINGS value for cursor theme size because gnome-settings-daemon already multiplies it by the primary monitor's scale. https://bugzilla.gnome.org/show_bug.cgi?id=755099
-
Jonas Ådahl authored
We don't have any way of knowing what the intended size of a XWayland cursor is supposed to be, so lets do what we do with regular XWayland surfaces and don't scale them. The result is that cursor sprites of HiDPI aware X11 clients will show correctly, but non-aware clients may have tiny cursor sprites. https://bugzilla.gnome.org/show_bug.cgi?id=755099
-
- Oct 02, 2015
-
-
Carlos Garnacho authored
Each keyboard focus change ends up calling the MetaWaylandDataDevice counterpart, we don't need though to notify the current selection again. In order to fix this, keep track of the current client, and only emit the relevant signals when the focus switches to another client. The situations where wl_data_device.selection were emitted during focus changes between surfaces of the same client was inocuous most of the times, although it's prone to inducing confusing behavior on context menu clipboard actions, as the closing menu triggers a focus change, which triggers a whole new wl_data_offer being created and given on wl_data_device.selection, at a time where there's already ongoing requests on the previous data offer. https://bugzilla.gnome.org/show_bug.cgi?id=754357
-
Carlos Garnacho authored
If the transfer is cancelled, the X11SelectionData will be cleared from the MetaSelectionBridge, although x11_data_write_cb() was invariably expecting it to be non-NULL. If the write was cancelled, all the actions done in x11_data_write_cb() are moot, so just return early. If there's other errors happening (eg. "connection closed" if the target client happens to crash), we should still attempt at clearing the data anyway. https://bugzilla.gnome.org/show_bug.cgi?id=754357
-
- Sep 29, 2015
-
-
Jonas Ådahl authored
When committing a toplevel surface we might no longer have a MetaWindow associated with it. The reason may vary but some are: a popup was dismissed, the client attached and committed a NULL buffer to a wl_surface with the wl_shell_surface role, the client committed a buffer to a wl_surface which previously had an toplevel window role which extension object was destroyed. https://bugzilla.gnome.org/show_bug.cgi?id=755490
-
- Sep 28, 2015
-
-
Carlos Garnacho authored
If the drag dest surface suddenly disappears, we may find ourselves processing an XdndPosition message that was sent before the X11 drag source had an opportunity to find out. In that case mutter does know, so double check before processing the messages.
-
Carlos Garnacho authored
We try to translate the atom with its corresponding mimetype both back and forth, which actually breaks if the X11 client chose to announce the mimetype atom. To do the translation properly, keep track on whether the source announced the UTF8_STRING atom, and reply back with this only if that happened.
-
Carlos Garnacho authored
We may get a NULL one here, and we're wrongly attempting to remove the old weak ref from the new data source object.
-
Carlos Garnacho authored
data_device_end_drag_grab() will destroy the MetaWaylandDragGrab struct, so we definitely must not use it after destruction.
-
- Sep 27, 2015
-
-
Colin Walters authored
This tripped a new g-i warning; see https://bugzilla.gnome.org/show_bug.cgi?id=752047
-
- Sep 25, 2015
-
-
Rui Matos authored
If the wayland surface isn't available yet when we process the WL_SURFACE_ID ClientMessage, we schedule a later function to try the association again after we get a chance to process wayland requests. This works fine except on cases where the MetaWindow already had a previous surface attached (i.e. when the xwindow is reparented) since we only break the existing association on the later function which means that when processing the old surface's destruction we destroy the MetaWindow and cancel the pending later function leaving us without a MetaWindow and an invisible surface. Fix this by detaching the old surface as soon as possible so that the MetaWindow survives. https://bugzilla.gnome.org/show_bug.cgi?id=743339
-
Rui Matos authored
This shouldn't fail but apparently sometimes it does and in that case having a possibly wrong idea of the keymap is still better than crashing. https://bugzilla.gnome.org/show_bug.cgi?id=754979
-
- Sep 24, 2015
-
-
Jonas Ådahl authored
The saved rect is used to restore a saved window size. We need to update this when the window is moved to a monitor with different scale, so that if we unmaximize a window which was moved to a different monitor while maximized (for example when unplugged) will restore to the correct size. https://bugzilla.gnome.org/show_bug.cgi?id=755097
-
Jonas Ådahl authored
When a window is moved across monitors with different scales, its rectangle is scaled accordingly. We also need to scale the unconstrained_rect rectangle, so that moving a window via meta_window_move_resize() which uses the unconstrained_rect. https://bugzilla.gnome.org/show_bug.cgi?id=755097
-
Florian Müllner authored
Storage class always goes first.
-
Florian Müllner authored
-
Florian Müllner authored
An unsigned number is never smaller than 0, so we don't have to check for it.
-
Florian Müllner authored
-
Florian Müllner authored
-
Florian Müllner authored
-
Florian Müllner authored
-