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.
This commit is contained in:
John Lindgren 2025-08-26 20:27:34 -04:00
parent 4d1be7eada
commit ef766d16f0
26 changed files with 294 additions and 320 deletions

View file

@ -167,7 +167,7 @@ resistance_resize_apply(struct view *view, struct wlr_box *new_geom)
edges_initialize(&next_edges);
/* Use a constrained, effective geometry for snapping if appropriate */
enum wlr_edges resize_edges = view->server->resize_edges;
enum lab_edge resize_edges = view->server->resize_edges;
struct wlr_box origin =
snap_constraints_effective(view, resize_edges, /* use_pending */ false);