LivelyKernel / lively.next

lively.next is a personal programming kit. It emphasizes liveness, directness, and interactivity.
https://lively-next.org
MIT License
65 stars 16 forks source link

"Shrink"-extent-mode for `Text` #1559

Open linusha opened 3 months ago

linusha commented 3 months ago

Currently, Textmorphs inside of an Autolayout provide three sizing modes: They can have a fixed extent, hug their content or fill the morph. We noticed, that there might be a fourth value that one would like to have for Text which we called "shrink":

When setting the width mode of a Text to "shrink", its extent will never grow beyond the extent that would result from "hug", i.e., the morph gets at most exactly as wide as is necessary to display all its text content. However, the width of the morph would then respond to changes in the width of its container, similar to how it would respond with a width mode of "fill". This would only take effect when the resulting width becomes smaller than the value determined by the "hug" width mode. "Shrink" would also enable text wrapping by default or might even enforce it.

The reason for wanting this are cases where one would like to use the "positioning" capabilities of the layout, for example centering the text morph, while still wanting the fill behavior so that the text morph shrinks when the container is very small to break the text accordingly.

merryman commented 3 months ago

I suggest we implement this by introducing a new property for the text morph, which I would call boundedWidth and boundedHeight. If set to false (which is the default), fixedWidth and fixedHeight behave as usual. If we set boundedWidth to true, fixedWidth = true will block the further extension of the text horizontally once the document width is exceeded. Meanwhile fixedWidth = false behaves exactly the same as usual. The same applies to boundedHeight, which will not allow the text to grow beyond the total height of the document.

In conjunction with auto layouts and constraint layouts, we will utilize the max-width css property for rendering.

linusha commented 3 months ago

This would mean we end up in a situation where fixedWidth is not interpretable as expected alone, right? As fixedWidth will allow the morph to become smaller, dependent on the value of boundedWidth? Just checking in if I understood your proposal correctly.

I tend to think this makes understanding what is happening harder, but it might be the case that we cannot choose to not make it harder, but just decide where we introduce complexity... Might be a classical case of "one needs to die one death". Will think about this some more, just wanted to make sure that we understood each other correctly.