Conversation
| args = args or {} | ||
| args.colour = copy_table(args.colour) or copy_table(G.C.BLUE) | ||
| args.text_colour = copy_table(args.text_colour) or copy_table(G.C.UI.TEXT_LIGHT) | ||
| args.hooked_colour = copy_table(args.hooked_colour) or darken(copy_table(G.C.BLUE), 0.3) | ||
| args.w = args.w or 2.5 | ||
| args.h = args.h or 0.7 | ||
| args.text_scale = args.text_scale or 0.4 | ||
| args.max_length = args.max_length or 16 | ||
| args.all_caps = args.all_caps or false | ||
| args.prompt_text = args.prompt_text or localize('k_enter_text') | ||
| args.prompt_colour = args.prompt_colour or lighten(copy_table(args.colour), 0.4) | ||
| args.current_prompt_text = '' | ||
| args.id = args.id or "text_input" | ||
| args.multi_language = args.multi_language or false | ||
| args.smods_gui_input = true |
There was a problem hiding this comment.
I'd have to do more through testing, but I believe that it makes sense to make the defaults for this more flexible (My inital thoughts are multi_language = true, max_lenght = inf or maybe 256) and then have the old text input just call this one with it's defaults instead of the new defaults. I don't really see a need to keep both inputs around
There was a problem hiding this comment.
max_length = inf will explode your pc because it creates new text element for each letter which can be fit in this limit. Thunk moment. Changing that will require complete rebuilding of how text input as ui element operates. Not easy task to do.
multi_language = false by default because this element intented to be "better text input with multi-language feature", not "multi-language text input", despite PR name saying otherwise :droll:
There was a problem hiding this comment.
Vanilla input should be kept because of backwards compatibility. There's a lot of patches from various mods that applied to G.FUNCS.text_input specifically to make it behave as they need; breaking it is not what I like to do.
Plus, doing that will change behaviour of already existing vanilla inputs, such as profile name and seed. Dont want mess around with them too.
| -- Ignore input longer than 1 symbol | ||
| if utf8Len(args.key) ~= 1 then return end |
There was a problem hiding this comment.
G.FUNCS.smods_gui_text_input_key processes love.textinput for inputting actual letters, and love.keypressed for control inputs, such as left and right arrows, backspace and enter events. If we remove this length check, we will start inputting symbols such as Ctrl, Alt, Caps Lock and other.
Tho moving this check after calling hook_config.func() makes more sense.
| if e and not e.REMOVED and e.config.ref_table and e.config.ref_table.smods_gui_input then | ||
| G.FUNCS.smods_gui_text_input_key({ | ||
| key = text, | ||
| caps = G.CONTROLLER.held_keys["lshift"] or G.CONTROLLER.held_keys["rshift"], |
There was a problem hiding this comment.
I thought love.textinput handled caps for us
There was a problem hiding this comment.
Maybe it is, I was just following vanilla caps handling approach.
Maybe makes sense call string.lower when it's not caps.
| -- Reject input from keypressed unless it's from in-game screen keyboard | ||
| if args.keypressed and not SMODS.keypress_from_os_keyboard then return end |
There was a problem hiding this comment.
When would this get a keypress that is not from the keyboard?
There was a problem hiding this comment.
Idea is: if function called from G.CONTROLLER:key_press_update, process it only if it was either special key (left/right arrow, back, enter), or from screen keyboard to allow input from it. Otherwise we would need manually call love.textinput(key) to make screen keyboard work.
Co-authored-by: WilsontheWolf <git@shorty.systems>
2 participants
This PR adds functionality for creating text input via
SMODS.GUI.text_input(args), which have next features:Things to do:
Additional Info: