Potentially Implement a Tab Order Param?

[RobinXe]

I have a UI panel for logging onto a server (it's an online game) which has a number of text entry lines. I wanted the user to be able to cycle through them using the TAB key.

In order to do this, I have implemented a list of the relevant text line objects, and applied an itertools cycle to them. When TAB is pressed, it positions this cycle, by cycling until it finds the element which matches manager.focused_element, then shifts focus to the next item, and selects all the text within it.

This required modifying the UITextEntryLine class, in order to add K_TAB to the _process_action_key_event method, merely to prevent the keypress being taken as an input.

This could probably be most neatly handled at the UIManager level, if it's thought that it could add value enough to justify it. Providing a "tab_order" parameter to the text_input_line class (and potentially buttons) could allow this to be implemented, perhaps on a container-wide level.

def tab_cycle(self):
    focused_elem = self.manager.focused_element
    while focused_elem != next(self.focus_cycle):
        continue
    focus_elem = next(self.focus_cycle)
    self.manager.set_focus_element(focus_elem)
    focus_elem.select_range = [0, len(focus_elem.text)]

[MyreMylar]

I definitely do want to do this, or something very like it - and add the enter key as an alternative to a mouse click on focused buttons.

I do suspect there is probably going to be a range of issues with the way it works though. While I can clearly imagine how it would work for simple click interactions, my brain is whispering to me (as it sometimes does) that some things that work smoothly with the mouse (like dragging? ) are going to be less usable with a keyboard or d-pad.

I have a vague plan in my head to figure out:

1. A good, themable way of showing the focused element to the user. I'm thinking I'll need to expand to having hierarchical shape states so things like buttons can be hovered & focused or selected & focused, but the focus colours will get priority if they exist. That way everything could still work exactly the same as it does now or the drawing code could also know that if a shape is in the focused state it should draw, say the border, in a different colour.

2. Keyboard only UI Controls, once you can see where the focus currently is (if it's anywhere). You should be able to move it around the 'focus-able' UI elements on the screen (some UI elements are not interact-able by default so don't need focus). I'm thinking tabbing elements normally goes left to right then top to bottom which I can probably work out with some sorting. The enter would become a generic 'interaction' key like it is already on the text entry line.

3. Followed by console controller only controls as I think they will share a lot of similarities - though a controller is also going to need an onscreen keyboard element for text entry and can maybe do a few things better than a keyboard thanks to analogue sticks.

[MyreMylar]

This issue is related to #76,

[RobinXe]

I only picked up your library a couple of days ago, and I'm still getting to grips with its intricacies, so forgive me if I demonstrate my unfamiliarity, but please allow me to share my thoughts:

1. I don't see any reason not to use the 'hovered' behaviours to demonstrate focus; it's normally an indicator that it will be triggered by action, so it seems apt to me. For buttons, to ape the windows behaviour, the focus could additionally involve simply (and optionally) drawing the rect that contains the button text. Drop-down menus and selection lists, I would suggest, could share the behaviour of hover, actuated with the arrow-keys, with the behaviour of clicking the drop-down button triggered also by gaining focus (with its own button simply set_focus_element'ing it).

2. Thinking back to my dim-and-distant days working with VBA, I recall that the elements within a group (container) could be assigned an integer value to specify the order in which TAB (and Shift + TAB) would cycle through them. Exposing an optional parameter, at the UIElement-level, that defaults to False, but will accept an int could achieve similar. Methods would be required, somewhere, to detect and handle assignment collisions, and perhaps to auto-assign values to elements assigned 'True', without value, as you seem to suggest.

3. Controller-only text entry certainly leaves room for novel solutions, beyond an on-screen keyboard. I'd consider the latter to be simply a panel of buttons, but moving between them could require the 'tab order' to be a 2D array.

I don't mean to seem like I'm teaching you to suck eggs, so sorry if that;s the case! I've been very impressed with pygame-gui so far, especially for the breadth of documentation and commenting, so am very glad that I came across it, and appreciative for your efforts in maintaining it!

I guess I better go add a Shift+TAB method to my panel!

[Snayff]

I think it is completely reasonable that some functionality is only accessible with certain input, e.g. not being able to resize a window with a controller. I can't think of any game that's allowed me to handle that sort of minutiae with a controller. Just being able to interact with the element, without resorting to manipulating the mouse cursor pixel by pixel, is of huge benefit. Though to confirm, tabbing through elements seems like core functionality that would be beneficial for any input device (maybe not the mouse).

Speaking of manipulating the mouse, one approach to controller/UI interactions that I've seen before is to jump the mouse cursor from element to element in response to controller input. That way no the only controller specific code is basically middle ware between the input and the mouse. Certainly not advocating that, as I think it's a workaround more than a solution, but its a thought.