mirrors/labwc
1
0
Fork 0
mirror of https://github.com/labwc/labwc.git synced 2025-10-29 05:40:24 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions
labwc/include/snap-constraints.h

21 lines
510 B
C
Raw Permalink Normal View History

snap: cache and ignore last-snapped edge when growing or shrinking When growing or shrinking a view by snapping to an edge, a client may ignore the requested size and instead keep its original size or substitute a different (possibly constrained) size. In this case, the view may not actually contact the snapped edge, and a subsequent snap attempt will just keep re-trying (and failing) to contact the same ege. To mitigate this, remember the last-snapped view, snapping direction and offset of the snapping edge in snap.c; when re-attempting a snap for the same view in the same direction, ignore the edge that was last "hit", to allow snapping to progress beyond the problematic edge.
2024-04-02 15:58:50 -04:00
/* SPDX-License-Identifier: GPL-2.0-only */
#ifndef LABWC_SNAP_CONSTRAINTS_H
#define LABWC_SNAP_CONSTRAINTS_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 "common/edge.h"
snap: cache and ignore last-snapped edge when growing or shrinking When growing or shrinking a view by snapping to an edge, a client may ignore the requested size and instead keep its original size or substitute a different (possibly constrained) size. In this case, the view may not actually contact the snapped edge, and a subsequent snap attempt will just keep re-trying (and failing) to contact the same ege. To mitigate this, remember the last-snapped view, snapping direction and offset of the snapping edge in snap.c; when re-attempting a snap for the same view in the same direction, ignore the edge that was last "hit", to allow snapping to progress beyond the problematic edge.
2024-04-02 15:58:50 -04: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
struct view;
snap: cache and ignore last-snapped edge when growing or shrinking When growing or shrinking a view by snapping to an edge, a client may ignore the requested size and instead keep its original size or substitute a different (possibly constrained) size. In this case, the view may not actually contact the snapped edge, and a subsequent snap attempt will just keep re-trying (and failing) to contact the same ege. To mitigate this, remember the last-snapped view, snapping direction and offset of the snapping edge in snap.c; when re-attempting a snap for the same view in the same direction, ignore the edge that was last "hit", to allow snapping to progress beyond the problematic edge.
2024-04-02 15:58:50 -04:00
struct wlr_box;
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
void snap_constraints_set(struct view *view, enum lab_edge direction,
struct wlr_box geom);
snap: cache and ignore last-snapped edge when growing or shrinking When growing or shrinking a view by snapping to an edge, a client may ignore the requested size and instead keep its original size or substitute a different (possibly constrained) size. In this case, the view may not actually contact the snapped edge, and a subsequent snap attempt will just keep re-trying (and failing) to contact the same ege. To mitigate this, remember the last-snapped view, snapping direction and offset of the snapping edge in snap.c; when re-attempting a snap for the same view in the same direction, ignore the edge that was last "hit", to allow snapping to progress beyond the problematic edge.
2024-04-02 15:58:50 -04:00
void snap_constraints_invalidate(struct view *view);
void snap_constraints_update(struct view *view);
struct wlr_box snap_constraints_effective(struct view *view,
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
enum lab_edge direction, bool use_pending);
snap: cache and ignore last-snapped edge when growing or shrinking When growing or shrinking a view by snapping to an edge, a client may ignore the requested size and instead keep its original size or substitute a different (possibly constrained) size. In this case, the view may not actually contact the snapped edge, and a subsequent snap attempt will just keep re-trying (and failing) to contact the same ege. To mitigate this, remember the last-snapped view, snapping direction and offset of the snapping edge in snap.c; when re-attempting a snap for the same view in the same direction, ignore the edge that was last "hit", to allow snapping to progress beyond the problematic edge.
2024-04-02 15:58:50 -04:00
#endif /* LABWC_SNAP_CONSTRAINTS_H */
Reference in a new issue Copy permalink