I have a Panel containing a TextMeshPro (TMP) object and a few other (buttons for example) aligned vertically. I want the following behavior:
Panel size expands vertically as more text is added to the TMP or more elements are added (e.g. buttons and sub-images).
As more text is added to the TMP, we stop expanding the size of the Panel and instead use overflow (ellipses or whatever).
So it should look like this when the text is long, and this when the text is short.
My current setup has Vertical Layout Group and Content Size Fitter components in the Panel object.
The Vertical Layout Group has "Control Child Size" ticked but not "Use Child Scale" or "Force Child Expand".
The Content Size Fitter has "Preferred Size" for vertical fit.
The TMP object has a Layout Element component. If I set this component to a specific preferred size it gets fixed at that size and so handles overflow well but when the text content is short there is tons of extra space.
If I uncheck preferred size from the TMP, the TMP object shrinks to fit small amounts of text snugly (as I want). However, when I add lots of text it keeps growing without a cap, eventually taking over the entire screen and more.
Is there any way to achieve my desired behavior by tweaking the settings of the Layout Element/Content Size Fitter/Vertical Layout Group? Or do I have to write a new component that turns on preferred size to cap the height when text reaches a certain length?
Thanks!
The best solution I found is to add a new component to the parent object with the Content Size Fitter that enforces the maximum.
The new component needs to implement the interface ILayoutSelfController and implement the methods SetLayoutHorizontal and SetLayoutVertical. In these methods, check if the current X and Y dimensions are larger than Serialized maxes you set in the inspector.
The full solution, from a Unity user called Democide (aka Democritus) is available here https://forum.unity.com/threads/purpose-of-uibehaviour.289666/
Related
Hello, any advice how to make 'obj#2' move down or adjust when for example obj#1 has a childs?
for the mean time some child or the 1st child of Object#1 is overlapping with Obj#2.
goal is:
obj#1
child0
child1
child2
obj#2 <-----
my hierarchy setup is:
scroll_view <---scrollrect,mask
content <---vertical layout group, content size fitter
[[obj#1]]
sub_content<--- vertical layout group, content size fitter
[[obj#1 child0]]
[[obj#1 child1]]
[[obj#2]]
so on...
I've played around with the settings/options and searched for a video tutorial but most of the one I get are single elements list in scroll view only.
Thank you for reading. Regards.
You can use Content Size Fitter on obj#1 with Vertical fitting, but you should add Layout Element to you child’s(child0, child1, child2) and setup preferred height. But you setup must be identical, if you setup Min Height in Layout Element, use Vertical Fit - Minimum, or Preferred, when use Preferred Width
EDIT: oh, I see you use Content Size Fitter, but if you haven’t Layout Element component on childs, Content Size Fitter can works unpredictably. And, try to add Vertical Layout group on Scroll View, this may help to control vertical position of the elements according to the size
I have a vertical Scroll List. I have developed this app for resolution 768*1024. In this resolution my List is working fine. But when I run my app in higher resolution(1440*2960) it leave some space around all 4 direction.
I have also tried with changing Layout element min height dynamically, but Spacing issue is still exist.
Vertical and horizontal layout set element position in (screen width/height divided by a number of elements) * element number, in other words, they space out all elements evenly across canvas space. To achieve what you want you either have to enable child control size -> height option or write a script that aligns your elements in the center of the screen and one after another taking in consideration their height.
The Context
I often have situations where I want multiple NSTextViews in a single NSStackView. Naturally, Auto Layout is not pleased with this since this makes height ambiguous (assuming the stack view is not set to fill equally). Even after adding constraints to resolve these issues, macOS Interface Builder appears to have a bug where it refuses to actually update frames when asked.
For this reason and others, I'm attempting to create a TextBox class (subclassing NSView) to encapsulate an NSTextView (and associated scroll view) and include an intrinsic content size to avoid layout issues. The intrinsic content size would be calculated based on a user-specified min and max number of lines (to display without requiring scroll). In other words, up to a certain max number of lines, TextBox will resize itself so that scrolling is unnecessary.
The Problem
This would seem to require an intrinsicContentSize that is dependant on frame width.
But, intrinsicContentSize documentation states:
The intrinsic size you supply must be independent of the content frame, because there’s no way to dynamically communicate a changed width to the layout system based on a changed height.
However, Auto Layout Guide states:
A text view’s intrinsic content size varies depending on the content, on whether or not it has scrolling enabled, and on the other constraints applied to the view. For example, with scrolling enabled, the view does not have an intrinsic content size. With scrolling disabled, by default the view’s intrinsic content size is calculated based on the size of the text without any line wrapping. For example, if there are no returns in the text, it calculates the height and width needed to layout the content as a single line of text. If you add constraints to specify the view’s width, the intrinsic content size defines the height required to display the text given its width.
Given that when scrolling is disabled in a text view:
If you add constraints to specify the view’s width, the intrinsic content size defines the height required to display the text given its width.
Then it seems there is a way to do what I want by perhaps looking at existing constraints.
The Question
How can I define an intrinsic content size that calculates height based on otherwise specified width, as described in the last quoted sentence above?
The solution should produce the effect described in "The Context" and not produce errors or warnings when used inside a Stack View.
When we use Layout Groups components in Unity editor . it divide our Layouts in same sections.
But i want have different size for my UI's in vertical or horizontal Groups .
In this image i have 3 UI (red , white and green color) . as you see they have same height size .
Red section that its name is header must have smaller height and also footer
It must like following image :
If this is something you want:
Setup vertical layout group like this:
You can see there are 3 child objects of VerticalLayoutGroup object in hierarchy. Header, Content and Footer. Now on Content object, add LayoutElement component and set Preferred Height as desired:
Note: you don't need to add LayoutElement on other children if you don't want to give them extra space. They will use rest of space equally.
From Docs:
First minimum sizes are allocated.
If there is sufficient available space, preferred sizes are allocated.
If there is additional available space, flexible size is allocated.
I create a large TreeView within a GTK ScrolledWindow within a hpaned within a notebook within the toplevel window (and toplevel window has a limited default size).
When I create a ScrolledWindow with TreeView within, it gets allocated as much space as TreeView takes (which is greater than the screen size) and my toplevel window is resized to infinity. How do I limit ScrolledWindow's allocation or its Viewport size? What's the mechanism that determines its default size?
Question seems to be solved. The size requisition of ScrolledWindow depends on its POLICY (in the respective direction) and is equal to requisition of child widget (treeview) if POLICY_NEVER is set, see gtkscrolledwindow.c:
scrolled window policy and size requisition handling:
gtk size requisition works as follows:
a widget upon size-request reports the width and height that it finds to be best suited to isplay its contents, including children.
the width and/or height reported from a widget upon size requisition may be overidden by the user by specifying a width and/or
height other than 0 through gtk_widget_set_usize(). a scrolled
window needs (for imlementing all three policy types) to request its
width and height based on two different rationales.
1) the user wants the scrolled window to just fit into the space
that it gets allocated for a specifc dimension.
1.1) this does not apply if the user specified a concrete value value for that specific dimension by either specifying usize for the
scrolled window or for its child. 2) the user wants the scrolled
window to take as much space up as is desired by the child for a
specifc dimension (i.e. POLICY_NEVER).
also, kinda obvious:
3) a user would certainly not have choosen a scrolled window as a
container for the child, if the resulting allocation takes up more
space than the child would have allocated without the scrolled window.
conclusions:
A) from 1) follows: the scrolled window shouldn't request more space
for a specifc dimension than is required at minimum.
B) from 1.1) follows: the requisition may be overidden by usize of
the scrolled window (done automatically) or by usize of the child
(needs to be checked).
C) from 2) follows: for POLICY_NEVER, the scrolled window simply
reports the child's dimension.
D) from 3) follows: the scrolled window child's minimum width and
minimum height under A) at least correspond to the space taken up by
its scrollbars.
So, if you set POLICY_NEVER, the ScrolledWindow will request for itself all the place, required by its child (and possibly will bloat the screen, if its child is huge). Otherwise, it will request a minimum needed to draw scrollbars. Possibly more space will be allocated for it than was requested and it will get enlarged to a reasonable size within its parent.
Sometimes you might want to have 2 ScrolledWindows, sharing a single scrollbar. Unfortunately, it is impossible to just set POLICY_NEVER for one of them and have scrolled_window1.set_adjustment() = scrolled_window2.get_adjustment() due to the fact, that POLICIES influence the size requisition and scrolled_window1 will start to request unpredictable (possibly huge) amount of space.