mouse: Add the Back/Forward Mouse Buttons#906
mouse: Add the Back/Forward Mouse Buttons#906RobLoach wants to merge 16 commits intoImmediate-Mode-UI:masterfrom
Conversation
RobLoach
changed the title
|
What these will be used for? Asking out of curiosity. You may want to add an example usage somewhere to EDIT: Also, how about other backends? Pretty sure most of them support mouse 4/5 |
|
Mostly for nuklear_console to allow going back in the menu. Do have to figure out a history in it though. https://github.com/RobLoach/nuklear_console/ |
|
This looks good. I just tested a couple backends but it seems fine. Interesting X1 is the back button and X2 is the forward button (both in physical positioning and what they trigger). I wonder how they decided that. Maybe just that back is the more common action, and on mine a least it's the larger button. |
src/nuklear.h
Outdated
| NK_BUTTON_X1, | ||
| NK_BUTTON_X2, |
There was a problem hiding this comment.
@RobLoach maybe this should be reverted back to:
NK_BUTTON_BACK
NK_BUTTON_FORWARD
I feel like X1/X2 is a bit too ambiguous for a name.
Most people understand what Left/Right/Middle/Double click means and does,
but mouse4/5/X1/X2 doesn't really suggest how this could be used by the library.
There was a problem hiding this comment.
I switched to it X1 and X2 because back/forewards that may not be their intended function. None of the renderers also refer to them as Back/Forwards. Majority call it X1/X2, which is likely safer to use.
There was a problem hiding this comment.
In review, only raylib refers to them as Back/Forwards
There was a problem hiding this comment.
because back/forewards that may not be their intended function
What was your use case in nuklear_console?
It feels odd that core library would ever use these for something else than navigation. Many desktop applications reuse those buttons for going back and forward (aka reverse-back) to some spots in the UI. In web browser it causes the tab to go back/forward in the page history.
There was a problem hiding this comment.
In games, I use it for the Melee button, and Specials... In nuklear_console, I'll be using it for...
- Navigation within the UI
- Allowing the user to use it as an input button:
There was a problem hiding this comment.
I'll be using it for... 1. Navigation within the UI
Not sure if I understand right. This will be a different kind of navigation to what most apps do? genuinely asking what's the plan here
I found those keys quite strange. It's hard to mentally imagine which one exactly is it based on raw 4/5/X1/X2. The buttons appear on actual physical mice as closer to you (Back/X2) and further from you (Forward/X1) so I thought the previous naming makes some sense.
I'm just afraid we won't understand what's going on when seeing something like mouse.buttons[NK_BUTTON_X2].down in the code. The backend library (like SDL/GLFW) doesn't care about actual name, it only serves the input and expects the app/user to treat it in any possible way, but Nuklear associates "common sense behavior" with each key/button
@rswinkle Any thoughts? You mentioned in #906 (comment) that X1/X2 are "reversed" to what you initially expected. [EDIT: or at least this was my impression when I read your comment.] Would BUTTON_BACK/FORWARD (or any other naming really) make a difference?
I don't want to pressure on changing anything. Just want to ensure the decision about those names is fully aware.
There was a problem hiding this comment.
I'm using SDL3 as a modal for all of them here...
- SDL_BUTTON_X1: NK_BUTTON_X1
- SDL_BUTTON_X2: NK_BUTTON_X2
The button that hits the same button as SDL3's X1 is hitting the same NK_BUTTON_X1 across all other renderers I've tested.
There was a problem hiding this comment.
Alright. We've talked about it, and figured out this will be resolved with doc comment: 929db27 / https://discord.com/channels/922234432071548968/934963188011773952/1480391263613223043
@RobLoach Feel free to resolve this thread, unless you wish to wait for rswinkle's opinion
Co-authored-by: sleeptightAnsiC <91839286+sleeptightAnsiC@users.noreply.github.com>
Co-authored-by: sleeptightAnsiC <91839286+sleeptightAnsiC@users.noreply.github.com>
RobLoach
changed the title
| if (nk_input_is_mouse_pressed(in, i)) | ||
| nk_label(ctx, "Pressed", NK_TEXT_LEFT); | ||
| else if (nk_input_is_mouse_down(in, i)) | ||
| nk_label(ctx, "Down", NK_TEXT_LEFT); | ||
| else if (nk_input_is_mouse_released(in, i)) | ||
| nk_label(ctx, "Released", NK_TEXT_LEFT); | ||
| else | ||
| nk_label(ctx, "Up", NK_TEXT_LEFT); |
There was a problem hiding this comment.
Because of how Nuklear serves those events, it's almost impossible to see Pressed/Released appearing. I even had hard time to capture recording of this (because my display is 75Hz) and I haven't seen it ever appearing in some demos (not sure if that was a bug in specific demo or not)
Any ideas on improving this? My first one was to split Down/Up and Pressed/Released events into two columns, but I don't think this would help much anyway.
This can be fixed as follow up PR but maybe you see any quick solution now?
There was a problem hiding this comment.
That's true. Pressed is only displayed for 1 frame. Same with Released. Unsure of a good way to ensure that's clear without some timers and gross code. Maybe a follow up.
There was a problem hiding this comment.
Probably just split it and then make the text slowly fade away. This file already uses delta time in few places, but yea, it might become ugly.
I'll enter a task for it, right after this PR gets merged.
sleeptightAnsiC
left a comment
sleeptightAnsiC
left a comment
There was a problem hiding this comment.
@RobLoach
Alright, everything that was possible to test, was tested.
I would suggest to wait a day or two, and then merge.
A lot of changes happened today, maybe we missed something in a rush.
3 participants
Found I wanted to allow use of the back/forward 4/5 butons on the mouse.