- Sep 28, 2015
-
-
Carlos Garnacho authored
We now additionally send: - wl_data_offer.source_actions - wl_data_source.action - wl_data_offer.action - wl_data_source.drop_performed - wl_data_source.drag_finished The protocol changes allow for compositors to implement different policies when chosing the action, mutter uses this to reimplement the same behavior that GTK+ traditionally had: - Alt/Control/Shift modifiers change the chosen action to ask/copy/move respectively - Drags with middle button start out as "ask" by default As mutter now also grabs the keyboard and unsets the window focus for these purposes, the window focus is restored after the drag operation has finished.
-
Carlos Garnacho authored
This will be useful during DnD, where mutter is expected to consume keyboard events for either allowing changes in the selected DnD action, or misc a11y features like keyboard-driven DnD. Currently, the vtable contains 2 functions, key() will be used on every key event we get from Clutter, modifiers() will notify of changes in the keyboard modifiers (mouse buttons will never be set in the modifier mask)
-
Carlos Garnacho authored
This will be useful when an update is due but no motion event is to be sent/received (eg. modifier changes during DnD).
-
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
-
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
-
Jonas Ådahl authored
It is not a callback on a parameter signal, and get no GParamSpec passed to it. This fixes a crash when a surface is on a destroyed output. https://bugzilla.gnome.org/show_bug.cgi?id=755096
-
- Sep 21, 2015
-
-
Florian Müllner authored
Update NEWS.
-
- Sep 20, 2015
-
-
Rūdolfs Mazurs authored
-
Rūdolfs Mazurs authored
-
- Sep 17, 2015
-
-
Jonas Ådahl authored
Signals are sent to a specific ID, so we can't use "self" here. After this revert, VT switching works again. This reverts commit 8e22bf5b. https://bugzilla.gnome.org/show_bug.cgi?id=753434
-
- Sep 16, 2015
-
-
Florian Müllner authored
We know the variable only contains one or another string literal, but keep compilers happy as well.
-
Florian Müllner authored
Update NEWS.
-
- Sep 13, 2015
-
-
Jonas Ådahl authored
Calling queue_redraw() in _force_update() is not needed because update_cursor() will do this when needed, i.e. when switching between hardware cursor and texture cursor, or when drawing with texture cursor. There is also no need to force _native_force_update() because update_cursor() will cover this as well when needed. When not changing cursor but only the gbm_bo, the "dirty" boolean on the gbm_bo will trigger a redraw. https://bugzilla.gnome.org/show_bug.cgi?id=744932
-
Jonas Ådahl authored
Support notifying clients about what outputs their cursor surfaces are on so that they can attach appropriately scaled buffers to them. https://bugzilla.gnome.org/show_bug.cgi?id=744932
-
Jonas Ådahl authored
This commits refactors cursor handling code and plugs in logic so that cursor sprites changes appearance as it moves across the screen. Renderers are adapted to handle the necessary functionality. The logic for changing the cursor sprite appearance is done outside of MetaCursorSprite, and actually where depends on what type of cursor it is. In mutter we now have two types of cursors that may have their appearance changed: - Themed cursors (aka root cursors) - wl_surface cursors Themed cursors are created by MetaScreen and when created, when applicable(*), it will extend the cursor via connecting to a signal which is emitted everytime the cursor is moved. The signal handler will calculate the expected scale given the monitor it is on and reload the theme in a correct size when needed. wl_surface cursors are created when a wl_surface is assigned the "cursor" role, i.e. when a client calls wl_pointer.set_cursor. A cursor role object is created which is connected to the cursor object by the position signal, and will set a correct texture scale given what monitor the cursor is on and what scale the wl_surface's active buffer is in. It will also push new buffers to the same to the cursor object when new ones are committed to the surface. This commit also makes texture loading lazy, since the renderer doesn't calculate a rectangle when the cursor position changes. The native backend is refactored to be triple-buffered; see the comment in meta-cursor-renderer-native.c for further explanations. * when we are running as a Wayland compositor https://bugzilla.gnome.org/show_bug.cgi?id=744932
-
Jonas Ådahl authored
The wl_pointer assigns a role to a wl_surface, so it makes sense to put the related logic there. https://bugzilla.gnome.org/show_bug.cgi?id=744932
-
Jonas Ådahl authored
It fills little purpose on separating into a MetaCursorImage struct, so lets squash in the three fields into the MetaCursorSprite object. https://bugzilla.gnome.org/show_bug.cgi?id=744932
-
Jonas Ådahl authored
Use a specialized cursor renderer when running as a nested Wayand compositor. This new renderer sets an empty X11 cursor and draws the cursor as part of the stage using the generic cursor renderer drawing path. https://bugzilla.gnome.org/show_bug.cgi?id=744932
-
Jonas Ådahl authored
Make a surface roles into objects with vfuncs for things where there before was a big switch statement. The declaration and definition boilerplate is hidden behind C macros. https://bugzilla.gnome.org/show_bug.cgi?id=744932
-
Jonas Ådahl authored
If a surface doesn't have a role, the compositor will not know how, if or when it will be painted. By adding it to the compositor frame callback list, the compositor will respond to the client that the surface has been drawn already which might not be true. Instead, queue the frame callback in a list that is then processed when the surface gets a role assigned. The compositor may then, given the role the surface got, queue the frame callback accordingly. https://bugzilla.gnome.org/show_bug.cgi?id=744932
-
Jonas Ådahl authored
Being a "XWayland window" should be considered equivalent to a role, even though it is not part of any protocol anywhere. The commit doesn't have any functional difference, but just makes it clear that an wl_surface managed by XWayland have the same type of special casing as surface roles as defined by the Wayland protocol. As the semantics are more explicit given the role is defined, a comment explaining why the semantics need to be how they are was added. https://bugzilla.gnome.org/show_bug.cgi?id=744932
-
- Sep 09, 2015
-
-
Olivier Fourdan authored
If a queued event is being processed after the surface is destroyed, trying to access the window associated with the surface will lead to a segmentation fault. This patch avoids the crash by first checking if the surface is not null. https://bugzilla.gnome.org/show_bug.cgi?id=754715
-
- Sep 07, 2015
-
-
Ting-Wei Lan authored
This fixes build error caused by commit 614d6bd0. We can simply remove the usage of meta-wayland.c functions in non-wayland build because META_BACKEND_X11_MODE_NESTED is only used in wayland. https://bugzilla.gnome.org/show_bug.cgi?id=753948
-
-