Scrollable Component

[PaulBGD]

Currently we have no way to make a scrollable view. I'd suggest making either Grid or VerticalBox/HorizontalBox scrollable.

[rawsh]

@andlabs is it possible to bump priority for this? When developing my own app I found this was really necessary.

[andlabs]

Do you mean a scrollable drawing area or a scrollable container?

[rawsh]

@andlabs scrollable container. A box I guess

[NoraCodes]

Just wanted to voice my support for this as well. Being able to indefinitely expand a control's size (say, a vertical box showing a list of labels) without expanding the window is important for a lot of applications.

[NoraCodes]

Just wanted to chime in here again since libui-rs is getting requests for this again. Looks like GTK's ScrolledWindow, Cocoa's Scroll View collection, and Win32API's WS_HSCROLL and WS_VSCROLL window style flags make this behaviour available. It's critical for a lot of applications and I think it's worth having a basic implementation soon even if it has to be deprecated and replaced later.

My instinct would be to add a new container control, ScrolledWindow or something of the like, that represents a GTK ScrolledWindow, a collection of all relevant Cocoa controls, and a Windows child window with WS_HSCROLL and/or WS_VSCROLL.

[franko]

Second this request and I confirm the need is essentially the same of my request

#441

For me the lack of this issue is a real show-stopper and I don't understand why no priority is not given to its implementation.

I can provide my best effort collaboration to provide an implementation, I can code and test on Linux and on Windows.

[chenshuiluke]

I also want to voice my need for a feature like this, as it's important for something I'm working on. I'll have to look into a different UI toolkit for now, it seems 😭

[andlabs]

Yes, this is definitely on the shortlist of things to add. However, the stuff I want to do this year for Alpha 5 will make adding this a lot easier and a lot more stable, and adding it now before I do the stuff for Alpha 5 will just make that other stuff more complicated. So while I do plan on doing this, the cleanup will still have to come first.

I know I've been doing a bad job of doing actual stuff lately; I need to fix that.

[chenshuiluke]

@andlabs Thanks for letting us know what's up. What you say makes sense

[franko]

@andlabs ok, now it is more clear, thank you.

I am wondering if it still make sense to implement the feature now, may be from contributors, even if some changes will be needed later, after the alpha5 you are talking about.

May I mention that libui is a young project and while very promising it needs to gain adoption to bacome a viable possibility and gain a community of developers. IMHO it is critical now for libui to implement as much as possible of all the useful, important features so that people can actually use it, even if the code is not perfect.

In the programming world there is a race right now about the new programming model for UI development, Electron being the most conspicuous proposition. There is an opportunity now for libui to be there but some critical actions needs to be taken, and now is the moment to act.

I suggest @andlabs to accept more contributions and even to ask for them and coordinate the efforts. If libui stay a single-man projet its future will be very uncertain.

Just my two cents, I am just trying to be helpful because libui is a project I care about!

[andlabs]

I don't reject contributions outright, I've just been doing a really bad job of project management :D But yes, you are right about all that; though I should also point out what I want to do for Alpha 5 has been something I've been planning for a while now.

[rubyFeedback]

I don't reject contributions outright, I've just been doing a really bad job of project management

I think this part is ok. I am even worse at project management because I don't even consistently
keep discussions ongoing or answer to emails. Not deliberately - I simply don't do any of this
regularly myself either.

For LibUI itself it would be nice if we could have a slightly more relaxed contribution policy like
"addons" for browsers - you have a base core and then add-ons to add behaviour that is not
(yet) in core LibUI. This may help development a little bit by distributing the time investment
more evenly across contributors. IMO it would be simpler to postpone on Alpha 5 or any
big rewrites and make simpler changes more frequently.