| Age | Commit message (Collapse) | Author |
|---|
|
See discussion in https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4555
|
|
The previous commit prioritized hotspots before bar bindings for press events,
which matches i3's behaviour. However, since hotspots don't need to do any
processing on release events, those were not handled, and simply fell through
to `bindsym --release` bar bindings (if any).
This is counter-intuitive, and doesn't match i3's behaviour. Instead in case
a hotspot handles the press event, it should also handle the release event,
doing nothing, but blocking the event from triggering a --release bar binding.
E.g., in Sway, without this commit, this config. shows a text on tray clicks:
bar {
# ...
bindsym --release button1 exec swaynag -m I_got_the_release_event.
}
But the same configuration in i3 (with i3-nagbar) doesn't show the text.
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
|
|
while the draw itself is a no-op, alignment must still be accounted
this requires more signalling about the blocks (border_set; was the
border set?)
|
|
24e8ba048aef4751c6fa1d5982ee634f921e6cf6 did not take scaling into account.
The hotspot size used pixel coordinates, the absolute coordinates were logical,
and the relative coordinates were completely wrong.
This commit makes all coordinates use logical values. If
`"float_event_coords":true` is sent in the handshake message, coordinates are
sent as floating-point values.
The "scale" field is an integer containing the scale value.
|
|
This is the first in a series of commits to refactor the color handling
in sway. This changes parse_color to return whether it was success and
no longer uses 0xFFFFFFFF as the fallback color. This also verifies that
the string actually contains a valid hexadecimal number along with
the length checks.
In the process of altering the calls to parse_color, I also took the
opportunity to heavily refactor swaybar's ipc_parse_colors function.
This allowed for several lines of duplicated code to be removed.
|
|
|
|
json-c.pc contains `Cflags: -I${includedir}/json-c`, so `<json-c/json.h>`
won't be found unless the parent directory is searched by default.
|
|
This commit mostly duplicates the wlr_log functions, although
with a sway_* prefix. (This is very similar to PR #2009.)
However, the logging function no longer needs to be replaceable,
so sway_log_init's second argument is used to set the exit
callback for sway_abort.
wlr_log_init is still invoked in sway/main.c
This commit makes it easier to remove the wlroots dependency for
the helper programs swaymsg, swaybg, swaybar, and swaynag.
|
|
This modifies `bar_cmd_tray_bindsym` to use `get_mouse_bindsym` for
parsing mouse buttons. This also introduces `bar_cmd_tray_bindcode`,
which will use `get_mouse_bindcode` for parsing mouse buttons. Like with
sway bindings, the two commands are encapsulated in a single file to
maximize shared code.
This also modifies tray bindings to work off of events codes rather than
x11 buttons, which allows for any mouse buttons to be used.
For `get_bar_config`, `event_code` has been added to the `tray_bindings`
section and will include to event code for the button. If the event code
can be mapped to a x11 button, `input_code` will still be the x11 button
number. Otherwise, `input_code` will be `0`.
|
|
This modifies `bar_cmd_bindsym` to use `get_mouse_bindsym` for parsing
mouse buttons. This also introduces `cmd_bar_bindcode`, which will use
`get_mouse_bindcode` for parsing mouse buttons. Like sway bindings, the
two commands are encapsulated in a single file with shared code.
This also modifies swaybar to operate off of event codes rather than x11
button numbers, which allows for any mouse button to be used.
This introduces two new IPC properties:
- For `get_bar_config`, `event_code` has been added to the `bindings`
section and will include to event code for the button. If the event code
can be mapped to a x11 button, `input_code` will still be the x11 button
number. Otherwise, `input_code` will be `0`.
- Likewise for `click_events`, `event` has been added and will include
the event code for the button clicked. If the event code can be mapped
to a x11 button, `button` will still be the x11 button number.
Otherwise, `button` will be `0`.
|
|
Compatibility with i3 commit 161db6f17d734ac9deb0a20e81b78d4b2a92ce68.
|
|
|
|
|
|
|
|
|
|
If the tokener parses incomplete json, it sets its error value to
json_tokener_continue. This means that extra json should be provided,
but the code was providing the entire object again. In the interest of
simplicity, the tokener is reset so that buffer_pos always points to the
start of the current object.
|
|
|
|
|
|
This now correctly handles an incoming json infinite array by shifting
most of the heavy listing to the json-c parser, as well as sending
multiple statuses at once. It also removes the struct
i3bar_protocol_state and moves its members into the status_line struct,
allowing the same buffer to be used for both protocols.
|
|
|
|
|
|
This prevents blocks from being destroyed before their hotspots are destroyed,
in case it is used for a pending click event that fires between the bar
receiving a new status, which destroys the block, and the bar rendering the new
status, which destroys the hotspot; this problem can be easily produced by
scrolling on a block that immediately causes a new status to be sent, with
multiple outputs
|
|
As well as ignoring scroll events on status elements when click_events
is enabled.
Previously, using the scroll wheel on a workspace button would switch to
that workspace instead of scrolling through them. Clicks and scrolling
on status elements would always be processed by swaybar, too. So in case
you were using scrolling as volume control on a status item, swaybar
would additionally scroll through your workspaces.
|
|
|
|
|
|
|
|
|
|
Code from @NilsBrause
Ref #1820
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
