| Age | Commit message (Collapse) | Author |
|---|
|
|
|
If a NULL xkb_rule_names pointer is passed to
xkb_keymap_new_from_names, libxkbcommon will default to reading
the XKB_* env variables. So there's no need to do it ourselves.
Also s/xkb_map_new_from_names/xkb_keymap_new_from_names/ since the
latter is more consistent with the returned struct name.
[1]: https://xkbcommon.org/doc/current/structxkb__rule__names.html
|
|
|
|
There's no reason to have duplicate enums
|
|
Previously, when dragging the left border of a window with the mouse in tinywl,
there was a bug where it snap the top level surface's geometry X coordinate
directly to the position of the mouse, as if you started the resize right on the
border. This also affected the other (right, top and bottom) borders.
I think that the previous resize code was hard to understand. Honestly I
have not spent a lot of time trying to understand why it didn't work and
I wrote another resize algorithm instead: now, instead of working directly
with widths and heights which are complicated, we work with the borders (left,
right, top, bottom). This is easier to understand IMO.
Note: I originally fixed this [in the waybox compositor](https://github.com/wizbright/waybox/pull/23) but
then I realized that the code was taken from tinywl and that it had the same
issues so I copied my fix for tinywl.
|
|
|
|
|
|
While trying out the tinywl code, I found that the resize mode was behaving
weirdly ... so I looked into code. Turns out the `begin_interactive` method
stores the cursor position plus the geo_box position; however,
`process_cursor_resize` wasn't taking this into account, causing windows to
jump down in size unexpectedly when resized and lose alignment with the cursor.
To fix this, I simply added a member to the `tinywl_server` struct that stores
the geo_box when the mouse enters grab mode, and I referenced that data in the
resize method. I considered polling for this data every time instead of storing
it in the server struct, but 1) since changes in this value are not relevant
and 2) it could potentially decrease performance (I don't know enough about
wlroots to know how much) I decided to just store it. I can change this if
desired.
|
|
|
|
While at it, choose the preferred mode instead of the last one.
|
|
The documentation for wayland-server.h says:
> Use of this header file is discouraged. Prefer including
> wayland-server-core.h instead, which does not include the server protocol
> header and as such only defines the library PI, excluding the deprecated API
> below.
Replacing wayland-server.h with wayland-server-core.h allows us to drop the
WL_HIDE_DEPRECATED declaration.
|
|
This is necessary for direct scan-out and other upcoming features. This patch
changes the output API to look like the wl_surface API.
Outputs now have some double-buffered state: the frame to be submitted
(currently only wlr_renderer frames are supported) and the damaged region.
To attach a pending frame, use wlr_output_attach_render. To set the pending
damaged region, use wlr_output_set_damage.
To submit the pending state, call wlr_output_commit. This will submit the
pending frame to the backend.
To migrate from the old API to the new one:
- Replace wlr_output_make_current calls by wlr_output_attach_render
- Replace wlr_output_swap_buffers calls by wlr_output_set_damage and
wlr_output_commit
|
|
Fixes https://github.com/swaywm/wlroots/issues/1544
|
|
clang consider error no enum handled,
in BSD and Linux
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This worked since it was the same value, but results in compile
warnings.
|
|
|
|
|
|
|
|
|
|
|
|
|
