[haiku-3rdparty-dev] Re: Window size becomes 'indecreasable'
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-3rdparty-dev@xxxxxxxxxxxxx
- Date: Mon, 2 Oct 2017 20:34:16 +0200
On 30.09.2017 18:52, Humdinger (Redacted sender humdingerb for DMARC) wrote:
A bit late now, seeing you already found a solution. But since I wrote
most of my reply earlier already ...
I'm working on BurnItNow in my branch "sizer" [1].
The BurnWindow sports a tab view with a bunch of Compilation*Views. In
those, I added a BStringView fSizeInfo and a custom BView fSizeBar to
show how much capacity is left on a medium as a string and a coloured
bar.
The problem:
* build and launch BurnItNow
* make the window a bit wider (up to now you can in/decrease window
size arbitrarily)
* click "Choose folder" and select any folder
-> the string "~ Empty project ~" in fSizeInfo gets exchanged with
what space is left on the medium
-> the bar fSizeBar is adjusted accordingly
=> The window jumps to become a bit wider (I suspect because of the
changed fSizeInfo string), but now you also can't make the window any
narrower.
What might be wrong?
Apparently the windows size limits don't allow the window to become
narrower. If the B_AUTO_UPDATE_SIZE_LIMITS flag is set, the window
inherits its size constraints from the root view, whose constraints are
calculated according to the rules for compound layouts/views from the
item it contains. This is how it should be. You neither want to unset
the flag nor override the window's size constraints, because doing that
will have the effect that resizing the window can cause situations where
the root view will not fit the window anymore or useless empty space
will appear.
As you already suspected, the BStringView is the cause of the issue. By
default it automatically updates its size constraints so that its text
is fully visible. The constraints are propagated up the view/layout
hierarchy as usual.
What you may want to do is override the BStringView's minimum width to a
value that is reasonable in your case. Obviously, if that width is
smaller than the width needed for the whole text, the text will be
truncated when the window is resized sufficiently small.
I experimented a bit with doing more
SetExplicitMaxSize(BSize(B_SIZE_UNLIMITED, B_SIZE_UNSET));
SetExplicitMinSize(BSize(B_SIZE_UNSET, B_SIZE_UNSET));
for the fSizeInfo etc., but that didn't do it.
B_SIZE_UNSET in this context means that you *don't* want to override the
automatically computed min/max width and/or height, so the second call
just sets the default. Something like
SetExplicitMinSize(BSize(100, B_SIZE_UNSET));
would work. Text wider than that width may be truncated when the user
resizes the window, though. If all the possible texts that can be set
are known beforehand, computing their maximum width and using that as an
explicit minimum width, would avoid the possible truncation. Wrapping
the view in a scroll view would work as well.
CU, Ingo
Other related posts:
