ncannasse
commented
4 years ago Regarding new package : I agree it's a good idea.
Regarding moving existing components:
- Slider and Dropdown : ok
- TextInput and Console : agreed
- Flow : no way ;-)
One problem with these extra components is styling. If you want to customize the look'n'feel (not only colors, but also fonts, margin, etc.) you end up with something that is only partly customizable and at some point you often need to make your own custom implementation : a good example for that are html components.
That's why we only did the "behavior" components so far (the ones that have a complex behavior but with very low "display" code).
One way to handle styling and to have some kind of unified API would be to have all of them extend Flow. This also permits Domkit styling, which is a big plus (actually even requirement).
Sparked from same conversation that started talk about Heaps and community. Currently there are 2 specific elements in h2d that look out of place -
h2d.Sliderandh2d.Dropdown. On top of that, samples use their own implementation of basic components that aren't part ofh2d. That approach always felt to me as kind of half-assed. I want to propose refactoring those elements into separateh2d.uipackage and expanding library of basic UI components. Those components are often used for debug interfaces, hence they don't require super-customizability of how they are rendered. But I think expanding amount of available UIs out of the box would make life easier for developers as they can throw together dev interfaces far faster and focus on adding actual function rather than reinventing the wheel with making UI components. I would like to reiterate main point: This aims heavily to ease up making UI at early development stages just to get things working, before artists and other people tune in and make stuff look fancy.Proposed changes
Move following classes from
h2dtoh2d.ui:SliderandDropdown. Debatable if those should be moved or not:Flow,TextInputandConsole.Backward compatibility
As to not introduce breaking changes, same approach as with
h2d.Spritewill be used: Instead of classes there would be typedefs:Expanding bundled UIs
Each component is debatable, obviously. Some can be excluded or some added. Those I consider as a must-have additions:
ButtonJust a button with tile background and text. Sometimes people just want a button. Optional: Toggle flagCheckboxWith label support. Again, sometimes people just want a checkbox. Optional: 3-state checkbox.RadioButtonYou get the idea ;)Those are "nice to have":
ProgressBarSimple progress bar. Can be useful when throwing together some loading screen before there's any dedicated graphics present (or more practical sample - we don't have time to make our loading bars fancy when doing a game jam game ;) )ScrollBarSomewhat similiar to Slider, but looks differently and used for different purpose.ScrollAreaExtension of Mask that also provides ScrollBars and Interactive that would listen to scroll events.NumberInputEssentiallyTextInputbut with steppers and, well, allowing only numbers.ToggleGroupSlightly altered Flow that can toggle it's contents. Essentialy a<details>tagTabsName pretty much describes function. Just an UI that lets you make tabular content.ListFlow wrapper that also provides ability to select elements.I understand that out-of-the-box engine is designed to not have too much advanced features, but those are not that advanced when you think about it. Those are basic UI components that are used very frequently, especially during development. And if those are present - it allows making of dev-UIs far less painful than without them, saving a lot of time for people by having the wheel already invented. Less time spent on writing UI components for thing that players won't even see means more time spent on actual game development. And if anything, those components can be made in a customizable way that with a few tweaks they can start looking presentable for players, which is double-win situation.