Recently, I finally finished working on a scrollable container.
As I wrote previously, getting rid of Unity’s native scroll view implementation was not so easy as I expected.
Implementing scrolling is an additional engineering effort because it has to solve multiple problems which we usually don’t know or care about. That’s because the system takes care of them and we are taking it for granted.
However, since the Unity implementation is wrong (well, it works fine for a 99% of time but that’s not good enough for eDriven :)), I had to change the scrolling system completely.
The good news is that this comes with a big bonus: eDriven doesn’t use Unity’s implementation of scrollbars anymore.
Now it has its own scrollbar component, consisting of 4 buttons (track, thumb, up and down buttons) and it should work fine with any rendering system capable of rendering simple buttons (that’s for possible future implementations).
So, why is a scrollable control a separate topic? Shouldn’t it be easy as adding a single child to the container having the scrolling turned on?
The reason is because the scrolling implementation is component specific.
For instance, TextArea control should scroll line-by-line. And should also listen to the low-level GUI.TextArea events such as “internal scroll position changed due to walking the cursor off screen using keys or the selection area”.
I’m working on a new TextArea control and currently haven’t found the way to react to low-level cursor position change. While still in research, I’m in doubt that this is possible, so it will most probably remain as a current single-style-container implementation. Note this is far from perfect (especially with a text selection) but this is the only option there is, because GUI.TextArea doesn’t dispatch anything to the outside world, and there’s no way of set its internal scroll position.
List is another component currently having the container-like implementation. How it has been working by now is having the hard-coded item renderer type which couldn’t be changed on the fly.
This was meant to be the simple-type of the list (like the native list implementation) which serves as a separate input control or as combo box popup list.
It would be really nice if the renderer type could be changed even on this simple type of the list. It would also be great if a custom layout could be sticked in, so the vertical arrangement of list items being optional.
Virtualization? Well, better not to think about it (yet)!
It would be great if there is only a single type of list which is data-driven, skinnable, having custom renderers and layout. And having the other data-driven components (like DataGrid for instance) built on top of it.
However, I have to check out the complexity of it, and doing that at this time, while still working on a (long waited) v1.12.