Age | Commit message (Collapse) | Author |
|
As touchpad touches are generally fully abstracted, a client cannot
currently know when a user is interacting with the touchpad without
moving. This is solved by hold gestures.
Hold gestures are notifications about one or more fingers being held
down on the touchpad without significant movement.
Hold gestures are primarily designed for two interactions:
- Hold to interact: where a hold gesture is active for some time a
menu could pop up, some object could be selected, etc.
- Hold to cancel: where e.g. kinetic scrolling is currently active,
the start of a hold gesture can be used to stop the scroll.
Unlike swipe and pinch, hold gestures, by definition, do not have
movement, so there is no need for an "update" stage in the gesture.
Create two structs, wlr_event_pointer_hold_begin and
wlr_event_pointer_hold_end, to represent hold gesture events and the
signals to emit them: wlr_pointer->pointer.hold_begin/hold_end.
|
|
|
|
Same logic as xdg-toplevel.
|
|
|
|
|
|
|
|
Same as wlr_box_empty, but for wlr_fbox.
|
|
This new scene-graph node displays a wlr_buffer.
Closes: https://github.com/swaywm/wlroots/issues/3161
|
|
|
|
Expose the panel orientation with wlr_drm_connector_get_panel_orientation.
Leave it to the compositor to consume this information and configure the
output accordingly.
Closes: https://github.com/swaywm/wlroots/issues/1581
|
|
|
|
|
|
|
|
Previously, `wlr_xdg_toplevel` didn't follow the usual "current state +
pending state" pattern and instead had confusingly named
`client_pending` and `server_pending`. This commit removes them, and
instead introduces `wlr_xdg_toplevel.scheduled` to store the properties
that are yet to be sent to a client, and `wlr_xdg_toplevel.requested`
to store the properties that a client has requested. They have different
types to emphasize that they aren't actual states.
|
|
|
|
A launchee notifies with a "remove"¹ message when done starting up.
Catch these and forward to the compositor. This allows the compositor to
end the startup sequence that might have been started by another
protocol like xdg-activation.
We don't handle other messages since we expect the launcher to use a
wayland protocol like xdg-activation.
While `_NET_STARTUP_ID` helps to associate toplevels with startup-ids
this signals the end of the startup sequence.
1) https://specifications.freedesktop.org/startup-notification-spec/startup-notification-latest.txt
|
|
This allows callers to specify the operations they'll perform on
the returned data pointer. The motivations for this are:
- The upcoming Linux MAP_NOSIGBUS flag may only be usable on
read-only mappings.
- gbm_bo_map with GBM_BO_TRANSFER_READ hurts performance.
|
|
This simplifies the implementation considerably.
|
|
This is a helper to integrate wlr_scene with wlr_output_layout.
|
|
|
|
|
|
|
|
These allow describing an output's viewport inside the scene-graph.
|
|
|
|
|
|
|
|
Instead, use wlr_surface_state.buffer only.
|
|
This is an internal struct.
|
|
|
|
We always return the same wlr_client_buffer as the one passed in,
so no need to return anything.
|
|
Instead of taking a wl_resource as argument, take a wlr_buffer.
|
|
|
|
Move the wlr_subsurface parent link to the subsurface state.
This is a dumb find/replace operation. This shouldn't result in
any behavior change.
|
|
Add a comment to explain the difference.
|
|
This exposes a read-only FD with the keymap.
|
|
With the addition of a non-surface node type, it was unclear how such
nodes should interact with scene_node_surface_at(). For example, if the
topmost node at the given point is a RECT, should the function treat
that node as transparent and continue searching, or as opaque and return
(probably) NULL?
Instead, replace the function with one returning a scene_node, which
will allow for more consistent behavior across different node types.
Compositors can downcast scene_surface nodes via the now-public
wlr_scene_surface_from_node() if they need access to the surface itself.
|
|
RECT is a solid-colored rectangle, useful for simple borders or other
decoration. This can be rendered directly using the wlr_renderer,
without needing to create a surface.
|
|
This will allow us to create node types which are rendered but not
surface-based, such as a solid color or image.
|
|
If nodes are arranged in a tree rather than at a single level, then it
makes sense that there should be a way to move them to a completely
different parent in addition to moving up or down among siblings.
|
|
|
|
This allows compositors to attach arbitrary data to the scene-graph
nodes.
|
|
This allows compositors to easily enable or disable a scene-graph node.
This can be used to show/hide a surface when the xdg_surface is
mapped/unmapped.
|
|
A new wlr_scene API has been added, following the design ideas from [1].
The new API contains the minimal set of features required to make the
API useful. The goal is to design a solid fundation and add more
features in the future.
[1]: https://github.com/swaywm/wlroots/issues/1826#issuecomment-564601757
|
|
A floating-point version of wlr_box_transform().
|
|
This is use for startup notifications per startup-notifiation spec
https://specifications.freedesktop.org/startup-notification-spec/startup-notification-latest.txt
|
|
The protocol specifies that all requests (aside from destroy) are
ignored after the compositor sends the closed event. Therefore,
destroying the wlroots object and rendering the resource inert
when sending the closed event keeps things simpler for wlroots and
compositors.
|
|
This allows wlr_buffer users to extend it with tjeir own state.
|
|
This wlr_surface_state field was a special case because we don't
want to save the whole current state: for instance, the wlr_buffer
must not be saved or else wouldn't get released soon enough.
Let's just inline the state fields we need instead.
|
|
This allows to have multiple addons of different types with the same
owner.
|
|
|