1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
//! **The two edges an operator can drag**, and the one line of egui that makes
//! either of them hold (DESIGN §4.39, bl-46e5).
//!
//! # Why the drag never worked, and it was not the design
//!
//! egui 0.30 stores a side panel's state as the rect its CONTENT took and
//! reads that back as the width on the next pass, and it floors that content
//! at the width RANGE's minimum and nothing else:
//!
//! ```text
//! ui.set_min_width((width_range.min - frame.inner_margin.sum().x).at_least(0.0));
//! ```
//!
//! (`containers/panel.rs`, `SidePanel::show_inside_dyn`). So a pane pulled
//! wider than its rows reported the rows' width and shrank to it on the next
//! frame. A pane whose body's FIRST act is `ui.set_min_width(ui.available_
//! width())` fills what it was given, the stored rect is the dragged one, and
//! the drag holds. `TopBottomPanel` does exactly that itself, one function
//! down in the same file, which is why the composer never had this half of the
//! defect.
//!
//! # What is the seat's, and what is still the policy's
//!
//! The panel's stored width is egui's memory and not this seat's fact. So a
//! width is taken as the operator's **only while they are dragging it**: on
//! every other frame the pane is handed the shown width EXACTLY
//! (`exact_width`, which is [`super::policy::shown`]'s answer clamped to the
//! window), and a width the policy imposed never comes back as a width the
//! operator set. That is the whole of *a narrower window clamps and never
//! overwrites*.
use cratepolicy;
/// **Where the pointer has `id`'s resize handle right now**, or nothing.
///
/// Read off the PREVIOUS frame's response, which is exactly where the panel
/// reads it (egui 0.30 `containers/panel.rs` takes the resize interaction from
/// `read_response` before laying anything out), so this answer and the panel's
/// are one answer rather than two that can disagree by a frame.
/// **A list pane on an edge that drags.** It is shown at `want`; it hands back
/// the width the operator dragged it to, and nothing while nobody is dragging.
pub
/// **The composer's top edge**, and the rows it sets.
///
/// `body` paints the panel and hands back one line of body type, which is the
/// unit the answer is in: the drag is answered in ROWS and never in points, so
/// the panel goes on being handed a height rather than reading one back off
/// its content (DESIGN §4.38). `rows` is what the field stood at this frame,
/// which is what makes the rest of the panel's height measurable.
pub