mirrors/labwc
1
0
Fork 0
mirror of https://github.com/labwc/labwc.git synced 2026-02-15 22:05:25 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions
labwc/src/common/edge.c

89 lines
2.1 KiB
C
Raw Normal View History

Add common/edge.c
2025-08-21 17:57:29 +09:00
// SPDX-License-Identifier: GPL-2.0-only
#include "common/edge.h"
common: flesh out enum lab_edge and prefer over wlr_edges/wlr_direction I like the new common/edge.h. I don't like how inconsistently we use it. Current situation: - enum wlr_edges and wlr_direction are designed to be used as bitset, and are defined compatibly - enum lab_edge is *also* designed to be used as bitset, but incompatible with the others (LEFT/RIGHT come before UP/DOWN) - we use an inconsistent mix of all three *AND* uint32_t (usually with the WLR_EDGE constants rather than the LAB_EDGE constants), and convert between them on an ad-hoc basis, sometimes implicitly Let's clean this up: - reorder enum lab_edge to be compatible with the two wlr enums (check this by static_assert) - use TOP/BOTTOM naming rather than UP/DOWN (matches wlr_edges) - add constants for the remaining possible combinations of the 4 edges - use lab_edge for all internal edge/direction fields, consistently - add lab_edge_is_cardinal() as a sanity check before casting to enum wlr_direction, and then eliminate all of direction.c/h Instead of "enum wlr_edges direction", we now have "enum lab_edge direction" which is not that much better. At least we are now clear that we're overloading one enum with two meanings.
2025-08-26 20:27:34 -04:00
#include <assert.h>
Add common/edge.c
2025-08-21 17:57:29 +09:00
#include <strings.h>
common: flesh out enum lab_edge and prefer over wlr_edges/wlr_direction I like the new common/edge.h. I don't like how inconsistently we use it. Current situation: - enum wlr_edges and wlr_direction are designed to be used as bitset, and are defined compatibly - enum lab_edge is *also* designed to be used as bitset, but incompatible with the others (LEFT/RIGHT come before UP/DOWN) - we use an inconsistent mix of all three *AND* uint32_t (usually with the WLR_EDGE constants rather than the LAB_EDGE constants), and convert between them on an ad-hoc basis, sometimes implicitly Let's clean this up: - reorder enum lab_edge to be compatible with the two wlr enums (check this by static_assert) - use TOP/BOTTOM naming rather than UP/DOWN (matches wlr_edges) - add constants for the remaining possible combinations of the 4 edges - use lab_edge for all internal edge/direction fields, consistently - add lab_edge_is_cardinal() as a sanity check before casting to enum wlr_direction, and then eliminate all of direction.c/h Instead of "enum wlr_edges direction", we now have "enum lab_edge direction" which is not that much better. At least we are now clear that we're overloading one enum with two meanings.
2025-08-26 20:27:34 -04:00
#include <wlr/util/edges.h>
#include <wlr/types/wlr_output_layout.h>
static_assert((int)LAB_EDGE_TOP == (int)WLR_EDGE_TOP
&& (int)LAB_EDGE_BOTTOM == (int)WLR_EDGE_BOTTOM
&& (int)LAB_EDGE_LEFT == (int)WLR_EDGE_LEFT
&& (int)LAB_EDGE_RIGHT == (int)WLR_EDGE_RIGHT,
"enum lab_edge does not match enum wlr_edges");
static_assert((int)LAB_EDGE_TOP == (int)WLR_DIRECTION_UP
&& (int)LAB_EDGE_BOTTOM == (int)WLR_DIRECTION_DOWN
&& (int)LAB_EDGE_LEFT == (int)WLR_DIRECTION_LEFT
&& (int)LAB_EDGE_RIGHT == (int)WLR_DIRECTION_RIGHT,
"enum lab_edge does not match enum wlr_direction");
Add common/edge.c
2025-08-21 17:57:29 +09:00
enum lab_edge
lab_edge_parse(const char *direction, bool tiled, bool any)
{
if (!direction) {
common: flesh out enum lab_edge and prefer over wlr_edges/wlr_direction I like the new common/edge.h. I don't like how inconsistently we use it. Current situation: - enum wlr_edges and wlr_direction are designed to be used as bitset, and are defined compatibly - enum lab_edge is *also* designed to be used as bitset, but incompatible with the others (LEFT/RIGHT come before UP/DOWN) - we use an inconsistent mix of all three *AND* uint32_t (usually with the WLR_EDGE constants rather than the LAB_EDGE constants), and convert between them on an ad-hoc basis, sometimes implicitly Let's clean this up: - reorder enum lab_edge to be compatible with the two wlr enums (check this by static_assert) - use TOP/BOTTOM naming rather than UP/DOWN (matches wlr_edges) - add constants for the remaining possible combinations of the 4 edges - use lab_edge for all internal edge/direction fields, consistently - add lab_edge_is_cardinal() as a sanity check before casting to enum wlr_direction, and then eliminate all of direction.c/h Instead of "enum wlr_edges direction", we now have "enum lab_edge direction" which is not that much better. At least we are now clear that we're overloading one enum with two meanings.
2025-08-26 20:27:34 -04:00
return LAB_EDGE_NONE;
Add common/edge.c
2025-08-21 17:57:29 +09:00
}
if (!strcasecmp(direction, "left")) {
return LAB_EDGE_LEFT;
} else if (!strcasecmp(direction, "up")) {
common: flesh out enum lab_edge and prefer over wlr_edges/wlr_direction I like the new common/edge.h. I don't like how inconsistently we use it. Current situation: - enum wlr_edges and wlr_direction are designed to be used as bitset, and are defined compatibly - enum lab_edge is *also* designed to be used as bitset, but incompatible with the others (LEFT/RIGHT come before UP/DOWN) - we use an inconsistent mix of all three *AND* uint32_t (usually with the WLR_EDGE constants rather than the LAB_EDGE constants), and convert between them on an ad-hoc basis, sometimes implicitly Let's clean this up: - reorder enum lab_edge to be compatible with the two wlr enums (check this by static_assert) - use TOP/BOTTOM naming rather than UP/DOWN (matches wlr_edges) - add constants for the remaining possible combinations of the 4 edges - use lab_edge for all internal edge/direction fields, consistently - add lab_edge_is_cardinal() as a sanity check before casting to enum wlr_direction, and then eliminate all of direction.c/h Instead of "enum wlr_edges direction", we now have "enum lab_edge direction" which is not that much better. At least we are now clear that we're overloading one enum with two meanings.
2025-08-26 20:27:34 -04:00
return LAB_EDGE_TOP;
Add common/edge.c
2025-08-21 17:57:29 +09:00
} else if (!strcasecmp(direction, "right")) {
return LAB_EDGE_RIGHT;
} else if (!strcasecmp(direction, "down")) {
common: flesh out enum lab_edge and prefer over wlr_edges/wlr_direction I like the new common/edge.h. I don't like how inconsistently we use it. Current situation: - enum wlr_edges and wlr_direction are designed to be used as bitset, and are defined compatibly - enum lab_edge is *also* designed to be used as bitset, but incompatible with the others (LEFT/RIGHT come before UP/DOWN) - we use an inconsistent mix of all three *AND* uint32_t (usually with the WLR_EDGE constants rather than the LAB_EDGE constants), and convert between them on an ad-hoc basis, sometimes implicitly Let's clean this up: - reorder enum lab_edge to be compatible with the two wlr enums (check this by static_assert) - use TOP/BOTTOM naming rather than UP/DOWN (matches wlr_edges) - add constants for the remaining possible combinations of the 4 edges - use lab_edge for all internal edge/direction fields, consistently - add lab_edge_is_cardinal() as a sanity check before casting to enum wlr_direction, and then eliminate all of direction.c/h Instead of "enum wlr_edges direction", we now have "enum lab_edge direction" which is not that much better. At least we are now clear that we're overloading one enum with two meanings.
2025-08-26 20:27:34 -04:00
return LAB_EDGE_BOTTOM;
Add common/edge.c
2025-08-21 17:57:29 +09:00
}
if (any) {
if (!strcasecmp(direction, "any")) {
return LAB_EDGE_ANY;
}
}
if (tiled) {
if (!strcasecmp(direction, "center")) {
return LAB_EDGE_CENTER;
} else if (!strcasecmp(direction, "up-left")) {
common: flesh out enum lab_edge and prefer over wlr_edges/wlr_direction I like the new common/edge.h. I don't like how inconsistently we use it. Current situation: - enum wlr_edges and wlr_direction are designed to be used as bitset, and are defined compatibly - enum lab_edge is *also* designed to be used as bitset, but incompatible with the others (LEFT/RIGHT come before UP/DOWN) - we use an inconsistent mix of all three *AND* uint32_t (usually with the WLR_EDGE constants rather than the LAB_EDGE constants), and convert between them on an ad-hoc basis, sometimes implicitly Let's clean this up: - reorder enum lab_edge to be compatible with the two wlr enums (check this by static_assert) - use TOP/BOTTOM naming rather than UP/DOWN (matches wlr_edges) - add constants for the remaining possible combinations of the 4 edges - use lab_edge for all internal edge/direction fields, consistently - add lab_edge_is_cardinal() as a sanity check before casting to enum wlr_direction, and then eliminate all of direction.c/h Instead of "enum wlr_edges direction", we now have "enum lab_edge direction" which is not that much better. At least we are now clear that we're overloading one enum with two meanings.
2025-08-26 20:27:34 -04:00
return LAB_EDGES_TOP_LEFT;
Add common/edge.c
2025-08-21 17:57:29 +09:00
} else if (!strcasecmp(direction, "up-right")) {
common: flesh out enum lab_edge and prefer over wlr_edges/wlr_direction I like the new common/edge.h. I don't like how inconsistently we use it. Current situation: - enum wlr_edges and wlr_direction are designed to be used as bitset, and are defined compatibly - enum lab_edge is *also* designed to be used as bitset, but incompatible with the others (LEFT/RIGHT come before UP/DOWN) - we use an inconsistent mix of all three *AND* uint32_t (usually with the WLR_EDGE constants rather than the LAB_EDGE constants), and convert between them on an ad-hoc basis, sometimes implicitly Let's clean this up: - reorder enum lab_edge to be compatible with the two wlr enums (check this by static_assert) - use TOP/BOTTOM naming rather than UP/DOWN (matches wlr_edges) - add constants for the remaining possible combinations of the 4 edges - use lab_edge for all internal edge/direction fields, consistently - add lab_edge_is_cardinal() as a sanity check before casting to enum wlr_direction, and then eliminate all of direction.c/h Instead of "enum wlr_edges direction", we now have "enum lab_edge direction" which is not that much better. At least we are now clear that we're overloading one enum with two meanings.
2025-08-26 20:27:34 -04:00
return LAB_EDGES_TOP_RIGHT;
Add common/edge.c
2025-08-21 17:57:29 +09:00
} else if (!strcasecmp(direction, "down-left")) {
common: flesh out enum lab_edge and prefer over wlr_edges/wlr_direction I like the new common/edge.h. I don't like how inconsistently we use it. Current situation: - enum wlr_edges and wlr_direction are designed to be used as bitset, and are defined compatibly - enum lab_edge is *also* designed to be used as bitset, but incompatible with the others (LEFT/RIGHT come before UP/DOWN) - we use an inconsistent mix of all three *AND* uint32_t (usually with the WLR_EDGE constants rather than the LAB_EDGE constants), and convert between them on an ad-hoc basis, sometimes implicitly Let's clean this up: - reorder enum lab_edge to be compatible with the two wlr enums (check this by static_assert) - use TOP/BOTTOM naming rather than UP/DOWN (matches wlr_edges) - add constants for the remaining possible combinations of the 4 edges - use lab_edge for all internal edge/direction fields, consistently - add lab_edge_is_cardinal() as a sanity check before casting to enum wlr_direction, and then eliminate all of direction.c/h Instead of "enum wlr_edges direction", we now have "enum lab_edge direction" which is not that much better. At least we are now clear that we're overloading one enum with two meanings.
2025-08-26 20:27:34 -04:00
return LAB_EDGES_BOTTOM_LEFT;
Add common/edge.c
2025-08-21 17:57:29 +09:00
} else if (!strcasecmp(direction, "down-right")) {
common: flesh out enum lab_edge and prefer over wlr_edges/wlr_direction I like the new common/edge.h. I don't like how inconsistently we use it. Current situation: - enum wlr_edges and wlr_direction are designed to be used as bitset, and are defined compatibly - enum lab_edge is *also* designed to be used as bitset, but incompatible with the others (LEFT/RIGHT come before UP/DOWN) - we use an inconsistent mix of all three *AND* uint32_t (usually with the WLR_EDGE constants rather than the LAB_EDGE constants), and convert between them on an ad-hoc basis, sometimes implicitly Let's clean this up: - reorder enum lab_edge to be compatible with the two wlr enums (check this by static_assert) - use TOP/BOTTOM naming rather than UP/DOWN (matches wlr_edges) - add constants for the remaining possible combinations of the 4 edges - use lab_edge for all internal edge/direction fields, consistently - add lab_edge_is_cardinal() as a sanity check before casting to enum wlr_direction, and then eliminate all of direction.c/h Instead of "enum wlr_edges direction", we now have "enum lab_edge direction" which is not that much better. At least we are now clear that we're overloading one enum with two meanings.
2025-08-26 20:27:34 -04:00
return LAB_EDGES_BOTTOM_RIGHT;
Add common/edge.c
2025-08-21 17:57:29 +09:00
}
}
common: flesh out enum lab_edge and prefer over wlr_edges/wlr_direction I like the new common/edge.h. I don't like how inconsistently we use it. Current situation: - enum wlr_edges and wlr_direction are designed to be used as bitset, and are defined compatibly - enum lab_edge is *also* designed to be used as bitset, but incompatible with the others (LEFT/RIGHT come before UP/DOWN) - we use an inconsistent mix of all three *AND* uint32_t (usually with the WLR_EDGE constants rather than the LAB_EDGE constants), and convert between them on an ad-hoc basis, sometimes implicitly Let's clean this up: - reorder enum lab_edge to be compatible with the two wlr enums (check this by static_assert) - use TOP/BOTTOM naming rather than UP/DOWN (matches wlr_edges) - add constants for the remaining possible combinations of the 4 edges - use lab_edge for all internal edge/direction fields, consistently - add lab_edge_is_cardinal() as a sanity check before casting to enum wlr_direction, and then eliminate all of direction.c/h Instead of "enum wlr_edges direction", we now have "enum lab_edge direction" which is not that much better. At least we are now clear that we're overloading one enum with two meanings.
2025-08-26 20:27:34 -04:00
return LAB_EDGE_NONE;
}
bool
lab_edge_is_cardinal(enum lab_edge edge)
{
switch (edge) {
case LAB_EDGE_TOP:
case LAB_EDGE_BOTTOM:
case LAB_EDGE_LEFT:
case LAB_EDGE_RIGHT:
return true;
default:
return false;
}
Add common/edge.c
2025-08-21 17:57:29 +09:00
}
enum lab_edge
lab_edge_invert(enum lab_edge edge)
{
switch (edge) {
case LAB_EDGE_LEFT:
return LAB_EDGE_RIGHT;
case LAB_EDGE_RIGHT:
return LAB_EDGE_LEFT;
common: flesh out enum lab_edge and prefer over wlr_edges/wlr_direction I like the new common/edge.h. I don't like how inconsistently we use it. Current situation: - enum wlr_edges and wlr_direction are designed to be used as bitset, and are defined compatibly - enum lab_edge is *also* designed to be used as bitset, but incompatible with the others (LEFT/RIGHT come before UP/DOWN) - we use an inconsistent mix of all three *AND* uint32_t (usually with the WLR_EDGE constants rather than the LAB_EDGE constants), and convert between them on an ad-hoc basis, sometimes implicitly Let's clean this up: - reorder enum lab_edge to be compatible with the two wlr enums (check this by static_assert) - use TOP/BOTTOM naming rather than UP/DOWN (matches wlr_edges) - add constants for the remaining possible combinations of the 4 edges - use lab_edge for all internal edge/direction fields, consistently - add lab_edge_is_cardinal() as a sanity check before casting to enum wlr_direction, and then eliminate all of direction.c/h Instead of "enum wlr_edges direction", we now have "enum lab_edge direction" which is not that much better. At least we are now clear that we're overloading one enum with two meanings.
2025-08-26 20:27:34 -04:00
case LAB_EDGE_TOP:
return LAB_EDGE_BOTTOM;
case LAB_EDGE_BOTTOM:
return LAB_EDGE_TOP;
Add common/edge.c
2025-08-21 17:57:29 +09:00
default:
common: flesh out enum lab_edge and prefer over wlr_edges/wlr_direction I like the new common/edge.h. I don't like how inconsistently we use it. Current situation: - enum wlr_edges and wlr_direction are designed to be used as bitset, and are defined compatibly - enum lab_edge is *also* designed to be used as bitset, but incompatible with the others (LEFT/RIGHT come before UP/DOWN) - we use an inconsistent mix of all three *AND* uint32_t (usually with the WLR_EDGE constants rather than the LAB_EDGE constants), and convert between them on an ad-hoc basis, sometimes implicitly Let's clean this up: - reorder enum lab_edge to be compatible with the two wlr enums (check this by static_assert) - use TOP/BOTTOM naming rather than UP/DOWN (matches wlr_edges) - add constants for the remaining possible combinations of the 4 edges - use lab_edge for all internal edge/direction fields, consistently - add lab_edge_is_cardinal() as a sanity check before casting to enum wlr_direction, and then eliminate all of direction.c/h Instead of "enum wlr_edges direction", we now have "enum lab_edge direction" which is not that much better. At least we are now clear that we're overloading one enum with two meanings.
2025-08-26 20:27:34 -04:00
return LAB_EDGE_NONE;
Add common/edge.c
2025-08-21 17:57:29 +09:00
}
}
Reference in a new issue Copy permalink