Comments (9)
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.
from nuklear.
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?
from nuklear.
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?
from nuklear.
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.
from nuklear.
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.
from nuklear.
Ok, that doesn't sound bad to me - PRs welcome 😉.
from nuklear.
Hey man, I've got two PRs in the queue already...
from nuklear.
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 😉.
from nuklear.
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.
from nuklear.
Related Issues (20)
- Backspace does not actually clear a buffer when using nk_edit_string HOT 4
- File Menu HOT 6
- Request: create example for showcasing integration with RGFW HOT 2
- How to make own title bar, without using the operating systems HOT 3
- Group margins/alignment Ubuntu HOT 3
- Demo doesn't include code on how to display images without OpenGL. HOT 1
- After set an opened Combo Box to invisible, no response from the entire window.
- How to do multiple render with one update HOT 2
- Events not working with multiple Nuklear windows
- Add `delta_time_seconds` to each renderer
- GUI "cards" HOT 6
- Multiple window instances HOT 2
- Inputs propagating to windows in background HOT 1
- No documentation explaining how to convert an nk_rune to a char. HOT 1
- Fragment shader used in the GLFW GL4 wrapper doesn't compile
- Getting some strange text clipping behavior when dragging windows around. HOT 1
- prefilling and updating an nk_edit_string while allowing manual editing ?
- 2 errors HOT 2
- Can`t assemble from src in msvs win HOT 2
- feature request: extend NO_SCROLLBAR with horizontal/vertical options HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nuklear.