-
-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mobile sizing and combo box click state question #443
Comments
Hello, I am not sure from message why you would need to know the size of the combo box and how this would be useful to you. Could you clarify what you are trying to do? (I'm on the go now, will try to provide a more elaborate answer later) Omar |
I forgot to specify but it's regarding user touch input. If the combo box is open and the user is trying to touch the area where the combo box extends then it could also be received by my application as normal user input (rotating the camera). I just wanted a way to specify if the touch was on the GUI or outside. |
There is a flag in the ImGuiIO structure called WantCaptureMouse that tells you exactly that, if the provided mouse/touch position is over a window handled by ImGui. |
OK I think that's what I might be looking for then. I knew there were flags for the ImGui windows, but I didn't know if that would work for the combo box (particularly if it extended outside the window like in my case). I'll give it a shot. Thanks. |
Or, If the window with the 3d render is a ImGui window then while inside a Begin/End block for that scope you can use the call to check is mouse is hovering that specific window. |
About that part:
I'm not sure there is a single answer for that. Your pattern of using (windowWidth * 0.80f) may just work well enough for you or not. If all your sizes comes in reference with the basic font size (which you may adjust based on resolution and/or DPI) then it may be enough. However ImGui won't work very well with imprecise touch inputs, you can increase TouchPadding but if widgets are close to each other (closer than TouchPadding) the first widget submitted will grab the touch instead of the closest one. So there's only so much you can pack tightly if you are expecting to use it with touch, it wasn't designed for that. |
I am working on an Android app that uses ImGui as a way to select scenes. The app is a 3D browser based on the LearnOpenGL tutorials. I have a question about properly sizing and laying out widgets (particularly combo boxes). I have a screen shot:
Basically, I have two problems / questions. One is regarding combo box state. I need to know when the combo box "drop down" is open because it can potentially extend below the window. If the combo box is closed then I can just do an AABB intersection test using the window coords (which I have specified in my code). If I know when the combo box is open then I can just add that boolean into my intersection test which would be simple (as opposed to computing the extended length of the window using the size of the entries in the combo box).
Next question is laying out the ImGui widgets on mobile. I want to know what might be the best way to lay out the widgets to best fit all devices. For instance, I want my combo box window to start at (0, 0) in the top left corner and extend down 10% of the screen height. This seems to work when I test it out but some devices have higher DPI and makes it hard to tap the widget. I am curious if anyone has been working with ImGui on mobile and found a good way to handle widget sizes on that platform.
Here's an example of my widget sizing code:
And then I create the combo box window like so:
The text was updated successfully, but these errors were encountered: