Problems with tabs in touch screen

[Aarkham]

Version/Branch of Dear ImGui:
Dear ImGui 1.72 (17200)
Branch: docking

** Back-end/Renderer/Compiler/OS**
Backend: imgui_impl_win32
Renderer: imgui_impl_dx9
Operating System: Win10

My Issue/Question:

Please note that the backend/renderer are just for emulating the problem.

In a touch screen device I use simulate the mouse events with the touch events, but when the user is not pressing the screen, the mouse position does not update. Usually it works quite well, but I have noticed a problem with the tabs.

If the window that has the tabs does have the focus, clicking on a tab just highlights it, but the tab is not set as current. You have to click a second time to activate it.

If the window that has the tabs does have the focus it works Ok.

And regarding tabs, just a suggestion. It would be fine that when there are more tabs in screen than space available, if you use the mouse wheel in the tabs they scroll so you don't need to go the the arrows to scroll them. Firefox, for example, uses this.

Screenshots/Video

Standalone, minimal, complete and verifiable example:

In the file imgui_impl_win32.cpp add the following lines at the beginning of the function static void ImGui_ImplWin32_UpdateMousePos() (add at line 151)

if(!ImGui::IsAnyMouseDown())
  {
    return;
  }

With this, imgui will receive the mouse events only when a mouse button is pressed.

[ocornut]

(Apologies for the late answer)

Any item using the ImGuiButtonFlags_AllowItemOverlap behavior will need at least one frame of Hovered state before actually being considered as Hovered, and this is causing trouble with the way you are submitting mouse data.

This is interesting because I was looking into transitioning more code toward this low-level button behavior to become the default (it's more useful to allow overlap by default) but then I would need a plan for touch devices.

On a touch device would need to:
1- Set mouse position but not set button right away.
2- Then set mouse buttons on the next frame.
On a release you would need to:
3- Clear mouse button.
4- On the next frame, clear mouse position.

The drawback is that adding step 1 would incur one frame of delay for touch device to react to presses.

You can probably attempt to implement this on your side. Eventually this is a very good reason to move forward with the idea of implementing a new IO queue (see https://gist.github.com/ocornut/8417344f3506790304742b07887adf9f), because that seems like the most natural way to solve this problem (and also for a standardized answer to #2797, #2334).

(
By the way - but this is unrelated to this specific issue) - when touch is released after two frame you should probably clear mouse position to become invalid again (e.g. so avoid those tooltip to appears).
)

[Aarkham]

(No problem)

Thanks, I was planning on doing what you suggest. I was just wondering if I had miss something.

[ocornut]

Work on #4921 should now make it easier to fix it and trickle MousePos+MouseDown over two frames in situations like that.

EDIT I guess it would still need a new API to submit events notifying a touch aka mouse pos is valid vs old.

(Also linking to #3453, #2650, #2372)

[Aarkham]

Hi Omar

Thanks for your incredible work.

I have tested last version.
The first thing I tried was just changing:

io.MousePos.x = m_MousePos.m_X;
io.MousePos.y = m_MousePos.m_Y;
io.MouseDown[0] = m_MouseDown;
io.MouseDown[1] = false;

with:

io.AddMousePosEvent(m_MousePos.m_X,m_MousePos.m_Y);
io.AddMouseButtonEvent(0,m_MouseDown);
io.AddMouseButtonEvent(1,false);

But it did not work. The behavior was exactly the same.

So, I have done this:

if(m_MouseButtonChanged)
  {
    if(m_MouseDown)
      {

        io.AddMousePosEvent(m_MousePos.m_X,m_MousePos.m_Y);
        ImGui::NewFrame();

        ImGui::PushFont(m_ImFont2);
        m_ComputerPaneAction->Step(aTime,is_visible);
        ImGui::PopFont();

        ImGui::Render();


        io.AddMouseButtonEvent(0,m_MouseDown);
        io.AddMouseButtonEvent(1,false);
        ImGui::NewFrame();
      }
    else
      {

        io.AddMouseButtonEvent(0,m_MouseDown);
        io.AddMouseButtonEvent(1,false);
        ImGui::NewFrame();

        ImGui::PushFont(m_ImFont2);
        m_ComputerPaneAction->Step(aTime,is_visible);
        ImGui::PopFont();

        ImGui::Render();


        io.AddMousePosEvent(m_MousePos.m_X,m_MousePos.m_Y);
        ImGui::NewFrame();

      }

    m_MouseButtonChanged=false;
  }
else
  {
    io.AddMousePosEvent(m_MousePos.m_X,m_MousePos.m_Y);
    io.AddMouseButtonEvent(0,m_MouseDown);
    io.AddMouseButtonEvent(1,false);

    ImGui::NewFrame();
  }

And now it works fine.

Is this Ok? I thought that with the new input queue I would not need to do two frames.
Am I doing something wrong?

Carlos

[elfenix]

Fwiw - I've verified for my use cases / UI - that I get the desired behavior on all elements by setting the mouse cursor to invalid. (I used -1, -1 earlier, but that caused a handful of issues with deltas, setting to -F_MAX, -F_MAX and now all behaviors are working OK - also clears up some issues with implot thinking there was an initial large drag due to large values in IO.MouseDelta.

Thanks @ocornut - I swear I searched and didn't see this one! ImGui has been awesome as a minimalist library for a really low-resource application.

[ocornut]

FYI although that is not the main issue here, I solved this today:

And regarding tabs, just a suggestion. It would be fine that when there are more tabs in screen than space available, if you use the mouse wheel in the tabs they scroll so you don't need to go the the arrows to scroll them. Firefox, for example, uses this.

With commit 5f30191

I'll also be looking at the main issue at hand here, since I'll likely do a bit of a push related to touchpad/screen/pen events.

[ocornut]

In essence, the main issue is the need to discriminate the input source, once we can then the fix becomes to add:

            if (mouse_input_source == TOUCH_SCREEN && mouse_moved)
                break;

In the code handling the ImGuiInputEventType_MouseButton event.

[Aarkham]

FYI although that is not the main issue here, I solved this today:

And regarding tabs, just a suggestion. It would be fine that when there are more tabs in screen than space available, if you use the mouse wheel in the tabs they scroll so you don't need to go the the arrows to scroll them. Firefox, for example, uses this.

With commit 5f30191

I'll also be looking at the main issue at hand here, since I'll likely do a bit of a push related to touchpad/screen/pen events.

Awesome!!

Thanks again for your great work!!

[ocornut]

This should be fixed by a16f99c + f070497 + f33a0de assuming the backend supports that detection.
It is supported by Win32 and SDL, and GLFW on Windows only for now.
The exact high-level behaviors fixed are listed in the Changelog for f33a0de