[WIP] Horizontal scrollable implemetation

[bungoboingo]

Still need to do some edge-case testing & api refinement, but thought I'd post it to get feedback on my initial approach.

I originally tried including a direction enum in the existing Scrollable struct directly but that was an issue for two reasons:

1. The API design is bad/unclear due to having stuff like fn height() available as an option for a scrollable whose direction is horizontal when it was ignored internally. This is what CSS does and I find it incredibly annoying.
2. Properties like scrollbar_width don't make sense in a horizontal scrollable so I messed around with renaming it length or other names before deciding it was more clear just to separate it out.

I also tried just duping most of the code over between the two Horizontal & Vertical structs & swapping the w/h x/y bits as necessary, but the amount of duplicated code was pretty immense. I have a significant amount of match cases in scrollable mod right now that could be reduced by just duping the code between Horizontal / Vertical modules. On the fence about this.

I ALSO tried doing some funky stuff with just modifying the bounds before use in a horizontal scrollable but that was superrrr confusing to read.

Note: No scrolling keybinds are currently supported other than just the good ol' grab & drag. Using mousewheel seemed counter intuitive when scrolling x-y, also would cause conflicts with nested scrollables.

For now the new (breaking) implementation is this:

scrollable::vertical(content) //or
scrollable::horizontal(content)

//can also call the variants directly e.g.
scrollable::Vertical::new(content)
scrollable::Horizontal::new(content)

I've modified the scrollable example to showcase the new options.

Again, just want to reiterate -> I have not tested this very thoroughly at ALL, just want to get some feedback on the API! Thanks!

[ids1024]

In GTK a ScrolledWindow handles both horizontal and vertical scrolling. So with this implementation, if you need both (which is typical if you want to allow a window to be shrunk small enough to need both) you'd compose one within the other?

That isn't an inherently bad (theoretically it's quite elegant), but I wonder if the single widget handling both might handle at least certain things better.

[bungoboingo]

Yeah I was thinking that if you wanted to scroll on both the x & y axis you would compose one within the other. I could see an argument for having scrolling for both axis contained to one widget. I was assuming that the most use cases are 1) vertical scroll, and then the more niche 2) horizontal scroll, and then the most niche, 3) scroll on both axis, so thought to design around that hierarchy. I could be wrong about this assumption however!

[ids1024]

My thought is that having both generally doesn't provide a good experience, but if you want your application to not be broken when the window is too small, you may want it show a horizontal scrollbar as a last resort at least. I think that behavior is pretty common.

[bungoboingo]

Working on a version that contains an Option<HorizontalScroll> or something similar as there is no way to have both scrollbars appear on screen at the same time in a wrapped situation with this current implementation. The nested scrollbar will always be at the end of the scrollable area of the outer one which isn't ideal.

[bungoboingo]

Closed this in favor of new Optional<Horizontal> implementation coming Soon