mirror/sway
1
1
Fork 0
mirror of https://github.com/swaywm/sway synced 2024-12-04 19:08:18 +01:00
Code Issues
913a7679cb
sway/include/swaybar/i3bar.h

36 lines
870 B
C
Raw Normal View History

swaybar: move i3bar definitions into separate file
2018-09-24 22:56:35 +02:00
#ifndef _SWAYBAR_I3BAR_H
#define _SWAYBAR_I3BAR_H
swaybar: separate input code to new file
2018-10-17 21:21:27 +02:00
#include "input.h"
swaybar: move i3bar definitions into separate file
2018-09-24 22:56:35 +02:00
#include "status_line.h"
struct i3bar_block {
swaybar: annotate wl_list properties in definitions
2018-10-06 20:02:12 +02:00
struct wl_list link; // status_link::blocks
swaybar: move i3bar definitions into separate file
2018-09-24 22:56:35 +02:00
int ref_count;
Rebase #1636 against current master
2019-01-31 10:45:12 +01:00
char *full_text, *short_text, *align, *min_width_str;
swaybar: move i3bar definitions into separate file
2018-09-24 22:56:35 +02:00
bool urgent;
parse_color: return success + drop fallback color 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.
2019-12-28 05:33:55 +01:00
uint32_t color;
bool color_set;
swaybar: move i3bar definitions into separate file
2018-09-24 22:56:35 +02:00
int min_width;
char *name, *instance;
bool separator;
int separator_block_width;
bool markup;
// Airblader features
uint32_t background;
uint32_t border;
swaybar: properly draw blocks with transparent black border 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?)
2021-09-15 12:07:07 +02:00
bool border_set;
swaybar: move i3bar definitions into separate file
2018-09-24 22:56:35 +02:00
int border_top;
int border_bottom;
int border_left;
int border_right;
};
void i3bar_block_unref(struct i3bar_block *block);
bool i3bar_handle_readable(struct status_line *status);
enum hotspot_event_handling i3bar_block_send_click(struct status_line *status,
swaybar: fix i3bar relative coordinates when scaling is used 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.
2020-02-01 18:08:00 +01:00
struct i3bar_block *block, double x, double y, double rx, double ry,
swaybar: Make hotspots block bar release bindings 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>
2021-09-18 22:21:22 +02:00
double w, double h, int scale, uint32_t button, bool released);
swaybar: move i3bar definitions into separate file
2018-09-24 22:56:35 +02:00
#endif
Copy Permalink