How to get TAB to navigate between edit widgets?

[ronaaron]

I've got a layout with labels on the left and edit controls on the right. Everything works nicely, but I want to be able to hit TAB (for instance) to move from one 'field' to the next.

What is the proper way to accomplish this?

[ronaaron]

OK, so just to say I do have a way to do it, but it seems like much more work than makes sense.

Check for KEY_TAB pressed in the render loop, and increment a counter; if the edit being created matches the counter, set the edit focus. Some other mechanism would be much more friendly.

[dumblob]

Thanks for asking and glad you already found the "recommended" solution.

Some other mechanism would be much more friendly.

I'm not sure we would want something like that. There would need to be a transparent way how to determine which widget has widget in the current frame and which widget will get it after receiving Shift+Tab (backward) or just Tab (forward). Such thing is not easy and we would probably end up with just saying "the last rendered" widget for Shift+Tab and "the next to be rendered widget" for Tab. But that's still far from being transparent/unambiguous - imagine all the if-else logic for widget creation. Furthermore there are popups and stuff (messing with the logical "previous widget" and "next widget" transparency). This would get messy very early.

So I think the solution with an explicit variable (e.g. counter) is the best to my knowledge 😉. Thoughts?

[ronaaron]

The real difficulty is that because of immediate-mode, you don't really have knowledge of all the widgets which might exist during a frame, as you would with traditional GUIs.

That said, if there were a 'tabbing order' field, say, in each widget, where the programmer assigned that order (or it could alternatively be auto-assigned in widget-creation order), then it would be possible to handle Tab/Shift+Tab inside Nuklear and just give the focus to the next widget in the assigned order.

Possible?

[dumblob]

That said, if there were a 'tabbing order' field, say, in each widget, where the programmer assigned that order (or it could alternatively be auto-assigned in widget-creation order), then it would be possible to handle Tab/Shift+Tab inside Nuklear and just give the focus to the next widget in the assigned order.

That's what I described above as a problematic approach. But how would you handle (in a more readable and easier way than your current solution) all the cases where the programmer wouldn't want neither the default ordering and maybe not even the at-compile-time-known ordering (because that changes in accordance to which widgets will get drawn and which not in that particular frame based on user input or other criteria)?

Just a smallest example. Nuklear draws stuff mostly (not always due to layouting, compound widgets, popups, etc.) top-down left-right, but that's not how a human perceives the wished "tab order". This "jumpy" experience would get even worse e.g. for arabic people who read buttom-top right-left.

I think this lurks on the edge of this small library - either we would need to introduce full locale support (which is itself bigger than the current nuklear.h) and act accordingly or we'll provide the programmer with some tiny helper - like a generic void pointer "in each widget" (there is no such thing, but maybe struct nk_context could be somehow abused for this purpose) where the programmer can store her struct containing whatever she finds fit - among other things also some ordering information.

[ronaaron]

Actually, I think allowing a 'userdata' pointer for all widgets would be a great thing.

As far as tab ordering, I am assuming that only widgets with a tab-order would get tabbed-to. So part of the widget's construction (or a helper like 'widget_tab_order' or something) would set how to handle tabs for that item.

I guess it works out to be more complex for Nuklear, and could be handled (by me, anyway) if a userdata pointer were available.

[dumblob]

Ok, that doesn't sound bad to me - PRs welcome 😉.

[ronaaron]

Hey man, I've got two PRs in the queue already...

[dumblob]

Hey man, I've got two PRs in the queue already...

Which is perfect - I'm glad there is the code. We're just out of manpower to review that everything. The thing is immediate mode UIs are really complicated architecturally and all the subtleties are not easy to review 😢. That's why I'm so persistent about thorough reviews - an ideal case would be to require at least 2 different persons to review each PR in our case, but if there is bunch of people having a different idea (and consensus among them) how to evolve Nuklear, I'm all for it 😉.

[ronaaron]

I feel your pain :)

I've got several beta-testers giving me valuable feedback as I port 8th from JUCE to Nuklear. It's a ton of work rewriting all the docs, and filling in the missing bits.

[hanatos]

i think this might be simpler than we thought. i can navigate through the edit fields in properties using tab:

recording.mp4

and it even circles around to the first element, by using these macros:

// define groups of widgets that can be switched by pressing "tab"
#define nk_focus_group_property(TYPE, CTX, NAME, m, V, M, I1, I2)\
  do {\
    if(0 == focus_id_next) { nk_property_focus(CTX); focus_id_next = -1; }\
    nk_property_ ## TYPE(CTX, NAME, m, V, M, I1, I2);\
    int adv = nk_property_## TYPE ##_unfocus(CTX, NAME, m, V, M, I1, tab_keypress);\
    if(adv) { tab_keypress = adv = 0; focus_id_next = 0; }\
  } while(0)

// call this before the above, at least once
#define nk_focus_group_head() \
  static int focus_id_next = -1;\
  static double time_tab; \
  double time_now = glfwGetTime(); \
  static int tab_keypress = 0; \
  if(glfwGetKey(vkdt.win.window, GLFW_KEY_TAB) == GLFW_PRESS && (time_now - time_tab > 0.2)) \
  { \
    time_tab = time_now; \
    tab_keypress = 1; \
  }

(i think tab_keypress and focus_id_next here are redundant and hold the same information, so it could be shortened)

and then calling nk_focus_group_property instead of nk_property. i had to implement focus and unfocus functions for the property widgets, i think with nk_edit it might just work since these functions already exist. also i locally merged #688 for it to work.

i suppose at that level of complexity it wouldn't be hard to integrate into nuklear proper and make it work for both edit fields and properties..