-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Let a Buffer
figure out its height
during set_size
#70
Comments
@hecrj could you provide some guidance on a desired API? |
@jackpot51 I'm not Hector, but perhaps I can help here, as I submitted #42 which I believe is more or less a duplicate of this issue (except it requests that the Buffer be able to figure out both dimensions, not just height). (you may also wish to read the comments on that issue, as there is more discussion than here). Background / MotivationI think the key thing to understand here is that UI layout algorithms may want to determine their layout based on the size of an unconstrained text layout, rather than giving the text box an explicit size ahead of time. An obvious case is laying out a vertical page within a scroll view, where you want a paragraph of text to take up however much vertical space it needs: it doesn't matter how much space that is so long as you can know how much space that ends up being. I believe it is possible to get this information out of cosmic-text currently by manually iterating of layout lines, but it's not particularly nice or easy. It would be nice if that height was calculated during layout and stored in an easy to access property. A less obvious, but currently more problematic case is if you want to leave the width unspecified. As documented in #42 (comment), you can kind of do this by setting the width to some large value, but this breaks alignment as alignment as the alignment will be based on that large size rather than the actual with of the text. It would be much better if that width could explicitly be set to "undefined" which would then cause alignment to use the computed width. This could be done by making An extra bonus for interop with CSS style layout.(Regarding users of cosmic-text: Bevy and Floem are both using Taffy which implements this style of layout) CSS-style layout modes actually have two separate "undefined" layout modes - "min-content" and "max-content". Specifically for horizontal text, these should be thought of as constraints on the width of the laid out text:
These sizes are used as hard bounds between which the layout algorithm can decide the final size of the text-containing box. Suggested APIAdd the following struct: struct SizeConstraint {
MinContent,
MaxContent,
Definite(u32),
}
If you wanted to do it in a slightly simpler way, then you could have the input dimensions be Extension: pass input dimensions to layout method(s)Perhaps this is going out of scope a little, but it might be nice if the "input dimensions" weren't stored on the |
Thank you @nicoburns for the description, I will look into this. |
I've seen cases in
|
I believe (1) would be partially covered by making the output dimension in each axis:
Then the UI layout can use the output width. I'm not 100% sure how that would interact with alignment though. If you want to customise whether the alignment was based on the specified width vs. the measured width then I guess you would need some kind of extra input (either a flag or a second size). |
I somewhat feel like needing to cover all these behaviors (with output size and alignment) is a motivation for having a separate measurement operation that doesn't interact with alignment at all. Thus, allowing the user to operate on the measured dimensions with any behavior desired to determine the final bounds that they pass to a function that does alignment. Although this might be a bit out of scope. And I guess the user can already do this by just performing full layout twice, so this could just be considered a future optimization. Also, it may not easily fit in the current |
@nicoburns described the use cases very well. I also like the design proposed.
In This is what prompted me to create this issue. The sizes we initially use for the |
Bump Is there any ongoing work here? |
Bump |
1 similar comment
Bump |
bump |
This should be fixed in #271, which allows a Buffer to be created without a defined width and size. |
While it is possible to use
i32::MAX
if there is no height limit for aBuffer
, the resultingBuffer
will usei32::MAX
as the final dimension. This means thatBuffer::visible_lines
will not be very useful.I think it'd be more useful to let layouting dictate the final
height
of aBuffer
.The text was updated successfully, but these errors were encountered: