Framework usage examples (please add suggestions)

[focustense]

I'd like to provide a good, clear set of maybe 5-10 examples covering everything from introductory material ("how do I create a simple menu") to very advanced usage (nested repeaters, included views, and generally anything with complex behavior). The best examples would be UIs that modders have actually made and found somewhat difficult, or are thinking of making but haven't pulled the trigger - again, because difficult.

Please add any suggestions here. There is no need to actually create the examples - I will do that as part of the docs/testing - I'm simply looking to understand what people might want to do with the framework.

Note - I'll probably use my own Garbage In Garbage Can as one of the examples - redone as StarML, of course - and see that as kind of a middling example; it's not terribly complex but it does have a grid, repeater, scrolling, etc., so it's not beginner-level either. Suggestions on both the easier and harder end of the spectrum would be great.

P.S. This doesn't have to be limited to menus. AFS uses StardewUI for some of the HUD as well. Right now, there isn't an API for creating a HUD through StarML, but it's easy to add if there are any compelling examples. Examples could also include config menus that were difficult or involved tradeoffs in GMCM; AFS has its own custom config and the Radial Menu config also involves a bunch of nutty hacks to GMCM that would be less of a mess in StardewUI. I'm happy to take on any examples like these from other people's mods or idea bins.

[Mushymato]

• Form/Config menu, with the usual text input, checkbox, dropdowns, keybind, buttons
• Grid view of all fruit objects in the game, demonstrate data binding
• Tabbed menu, akin to the vanilla pause menu.
• Overlay/Modal as child menus
• HUD elements

[focustense]

Thanks for this. Just for clarification, this entire discussion is about what you're referring to as data binding (that is the "framework", as opposed to the "library" or "shared project" which we've been using up 'til now). While the library/shproj is going to continue to remain available as a submodule, at least for the foreseeable future, I'm expecting that 9 out of 10 users will have a much easier time with the framework (same as using React/Angular/etc. vs. building a whole app in vanilla JavaScript, or building a WPF app using MVVM vs. using all the control types directly with code behind; you can do the latter, but it's not a ton of fun.)

Thanks again!