search

SFML / imgui-sfml

Dear ImGui backend for use with SFML
MIT License
1.13k stars 169 forks source link

Implemented hovered state / use window events instead of global functions to query mouse state #261

Closed Nightmare82 closed 10 months ago

Nightmare82 commented 10 months ago
Bambo-Borris commented 10 months ago

Could you expand on why you've done these changes, the PR description doesn't go into enough depth.

Nightmare82 commented 10 months ago

Could you expand on why you've done these changes, the PR description doesn't go into enough depth.

Sure:

ChrisThrasher commented 10 months ago

Could you expand on why you've done these changes, the PR description doesn't go into enough depth.

Sure:

  • It should fix issue Events not handled when apps start without focus #212 where you can't interact with windows when the app starts unfocused since the focused state wasn't initialized properly, now I use the focused state of the sf::Window to do so
  • I enabled mouse wheel event handling for hovered windows to allow users to scroll through windows currently hovered, before my changed users had to focus the window which felt cumbersome
  • The tap / click states used global functions to query those, I got rid of the whole state since it's not required and instead used window events to set the state needed(hovered/focused). This was mentioned here as the suggested solution : Events not handled when apps start without focus #212

Do all three of these issues need to be solved in the same PR? Is it possible to extract these things into separate PRs where we can see each change in isolation or is it required that all three fixes land at once?

Nightmare82 commented 10 months ago

I think I could split it into two steps, the mouse wheel change could be done in a follow up PR(but would require the base of this PR)

eliasdaler commented 10 months ago

In my opinion, finishing https://github.com/SFML/imgui-sfml/pull/227 would be better. I don't believe that imgui-sfml should filter any events - it should be up to the user to pass events to imgui-sfml (and call or not call update when needed).

If imgui-sfml will process all events that are thrown into it, this PR won't be needed, I think.

Nightmare82 commented 10 months ago

In my opinion, finishing https://github.com/SFML/imgui-sfml/pull/227 would be better.

I don't believe that imgui-sfml should filter any events - it should be up to the user to pass events to imgui-sfml (and call or not call update when needed).

If imgui-sfml will process all events that are thrown into it, this PR won't be needed, I think.

Ok but who is working on that ? I was waiting for a fix but since it seemed to be stuck I used this branch to fix the main issues I had in my tool since this is a big problem of ImGui-Sfml, at least for tools like mine.

I could try to do it as you suggested since this is partially done already in this PR(I think I would mostly need to remove the hovered state and the checks related to that) or do you think someone will finish the other PR soonish ?

eliasdaler commented 10 months ago

No one is working on this PR. You can probably make a new one in the same vein, since it should fix your problem (most likely).

Imgui-sfml just needs to stop caring about whether the window is un focus or not. It should handle all the events that are passed to a particular window. It should be up to the user to determine which events need to be passed and which ones should not. (Though there might be some problems with multiple windows…)

Nightmare82 commented 10 months ago

Yes I think it should solve my issues (as this PR does), the main difference is that I need to decide from outside which events are sent to Imgui-Sfml. I agree that it sounds like the best solution since it allows users to add any custom rules easily.

I will try to create a PR in the near future