[Feature]: Enhanced input() function

[Baaaaaz]

Describe the Problem

Input is nice for quick data entry/maintenance, but the current range of input types and options is limited.

The Solution you'd like

New input types such as:

• SPINNER: for managed number input
• SLIDER: for managed number input
• TEXTAREA: for long text input
• CHECKLIST: for grouping related checkboxes

New control types such as:

• TITLE: to be able to customize the input dialog title
• PANEL: à la html fieldsets for grouping input types and which are placeable
• WIZARD: alternate TAB implementation, so behaves like an input wizard with previous/next buttons

Other improvements:

• allow TABs to be placed above/below/left/right
• allow a customizable end prompt character (currently a colon)
• ability to set default values relevant to the input type
• input validation on ok/next

Alternatives that you've considered.

Just build stuff in html5 dialogs/frames.

Additional Context

No response

[Baaaaaz]

e.g. some WIP...

[FullBleed]

These improvements would be very welcome!

Thanks for taking this on.

[Baaaaaz]

WIP RATING:

[Baaaaaz]

WIP SPINNERPLUSMINUS

[Baaaaaz]

WIP BAR (with number entry field on focus)

[Baaaaaz]

WIP CAROUSEL / CARD LIST

[Baaaaaz]

WIP WIZARD

[Baaaaaz]

WIP JSON (is this a step too far for the input function?!)

[Baaaaaz]

So have arrived at implementation crossroads, as on the way I have learnt some new things.... Do I:

• just productionize the above WIP input controls with the current input() function (still have start on the validation piece yet)
• refactor the current input() function to use and expose MiG Layout features (configurable and easier vertical or multi-columns forms then become available) and perhaps rehouse it in the new GenericDialog class
• just create a new greenfield inputWhatever() function and not have to worry about input() backwards support
• something else...

I know I do not want to paint this work into a corner and was thinking a bit beyond this PR, longer term it may be nice to have:

• user configurable interactions between input controls (e.g. cascading dropdowns, conditional visibility, ordering)
• input control actions / buttons which could go off, run a macro and update input control(s) with the results (e.g. roll some dice in a WIZARD, update an image from a roll table, update values in a dropdown list, do some calculation, etc)
• an apply button or optional live updates to token properties on changing input control values without have to press OK and the dialog closing (maybe this more like a frame implementation but could reuse the same input control / layout syntax)
• listen for certain token property change events that could update the dialog (or frame) [maybe needs to wait for the new event system]
  Most of these future ideas is possible currently with html/css/js, so it is even worth doing it? Would it reduce the barrier to entry?

@cwisniew any thoughts welcome. e.s.p. regarding feasibilities, dependencies, and your roadmap.

[FullBleed]

I feel like creating a new inputWhatever() function and not have to worry about input() backwards support is the safer, and hopefully, less taxing path. Better to put your time into debugging/updating the "new thing" than shoehorning into the "old" thing (which is extremely quirky). I feel like you're going to run into "can't do X, Y, Z because it might break established input behaviour".

Btw, any chance a new input could take html5?

[Baaaaaz]

I'll need to revisit some things for backwards support and isolating some changes, but putting the WIP stuff above into the existing input() seems the quickest route to live (but possibly at the expense of future desirables?).

A new greenfield does offer the opportunity to go back to current basic user requirements and modern accessibility requirements (noting input() which was originally released almost 20 years ago!), but then we end up with possible feature overlap and yet another way of doing things.

I suppose the two are not mutually exclusive.

html5... I think simply replacing the way input() currently does html to support html5 would not be performant (as you would end up with multiple little javafx webviews for each input control which uses html). It would be better to have a single webview, and get MapTool to write the html5 form controls, but then you are almost in the existing dialog5() territory (but without the cart blanche and needing some extra plumbing somewhere somehow for the automagic variable assignments). input5()? For more complex html5 forms involving tabs and wizards (in a single webview ) it would need some java code that then writes the necessary html, css, and js code. Maybe a input.toHTML() function which can be used inside any html5 thing, or maybe not...