Over the weekend, I spent some unintended quality time with the layout API for my simple markdown enabled text editor SENity, a trojan horse simple entry point to edit linked notes with SEN (more on that later).
However, even after hours of struggling, reading the API docs, looking at sample code from Haiku’s own apps and searching the forum, I still could not get it right.
The editor-in-progress is available on Github here (it’s not yet functional beyond loading and rendering text, and full of debugging output, just sharing for the UI code):
The main issue is the TextView. At first, everything is laid out correctly, but as soon as I set a text that exceeds the bottom, the TextView’s TextRect grows and pushes down the scrollbars or exploding the ScrollView, and even with my best effort, I could only get it to show scrollbars but the TextView then swims in the middle…
Curious enough, the symptoms are a little different for different file sizes, but that may just be some weird effect.
Is there some kind of FixedLayout where I can make sure that a certain part stays where it is and the rest grows around it?
I even used SetExplicitMin/MaxSize but that only got me half way there.
Welcome to the club, @grexe There`s been numerous times where I nearly lost what is left of my mental sanity to fighting with the layout API But then again I generally tend to not get along with layout API’s, not only the one from Haiku but QT, wxWidgets, MacOs, CSS. I guess I’m not much of a layout guy.
My number one go-to address for all Haiku API layout questions is @humdinger . Not only does he know the little details to make the layouts behave nicely but is a general treasure with all things UI and usability. None of my Haiku apps would look halfway decent without him.
That said, I’m still going to download your app and see if I can help.
Thanks for the hint. Sadly this didn’t help, the vertical scrollbar at least stays in place and the view doesn’t blow up, but it doesn’t change a bit, although proportion, range and steps are set to sane values.
In the newsletter link you posted, it even states that:
BTextviews pretty much take care of themselves, after they’re all configured. All of the scroll bar handling is done for you by the BTextView. Views containing images are much more interresting, as you need to create that view and handle the scroll bar on your own.
Anything else wouldn’t be worthy of the Be/Haiku API actually - why should I have to care about this when the TextView knows exactly what to do? It has a pointer to the parent ScrollView and knows its size, so do your job TextView.
I guess it has something to do with the Layout API. I am a bit unhappy how it is integrated as you can easily pick the wrong constructor and suddenly set up a non-layout-aware control, but I guess it is easier to maintain compatibility. Maybe the non-layout stuff should be deprecated or #pragma mark’ed or whatever as soon as the Layout API is stable.
Maybe I should use the non-layout variant to TextView after rall.
Oh man do I hate UI programming (but I love UX design…).
This should be handled by the BScrollView() c’tor already, as you pass in the view to scroll, and the wiring is done at construction.
Just for kicks I tried this but got the same result. Still thanks for the suggestion, but I read through all the docs already and still am not any wiser.
Can’t believe it but it’s finally working now, it was as easy as:
BSize min = fScrollView->MinSize();
BSize max = fScrollView->MaxSize();
fScrollView->SetExplicitMinSize(min);
fScrollView->SetExplicitMaxSize(max);
This even works when resizing the window without manual intervention in any of the hook methods, since the resize action will trigger an automatic relayout and update the min/max dimensions accordingly, so I guess.
Sorry to be late to the party. You can look in FileTypes app the long description field uses a BTextView in a BScrollBar. It seems like you got it now though.
I agree. It’s more painful than it should be.
Having a scrolling container inside a fixed container is no special case, and an API should make things easy and apply sensible defaults.
I see a lot of confusion and trickery even in Haikus own apps and this thread has shown that it also confuses other devs.
Is this a bug in the application of the API or in the API design, or in BScrollView?
There`s been numerous times where I nearly lost what is left of my mental sanity to fighting with the layout API 
But then again I generally tend to not get along with layout API’s, not only the one from Haiku but QT, wxWidgets, MacOs, CSS. I guess I’m not much of a layout guy.