search

ggerganov / imgui-ws

Dear ImGui over WebSockets
MIT License
448 stars 53 forks source link

Add handling for a resize event #11

Closed ihilt closed 3 years ago

ihilt commented 3 years ago

If the front end allows the canvas to be resized, then imgui needs to know about this. This PR wires up that data so it can be used by imgui.

ggerganov commented 3 years ago

How do we handle the case where multiple clients are resizing the canvas? Who has priority?

ihilt commented 3 years ago

How do we handle the case where multiple clients are resizing the canvas? Who has priority?

So they would conflict. I didn't consider this a problem since the same thing is true of the mouse events. As I understand it, you can only have one instance of imgui in these cases so you wouldn't be able to separate who currently is controlling imgui, either with the mouse or the size of the canvas.

ggerganov commented 3 years ago

The mouse is a bit different because I can have logic in my application for who is currently in control and accept only their mouse actions. I would then show the mouse actions from the primary client to the secondary clients.

Resizing the canvas is different because ImGuiWS cannot control the canvas size of the secondary clients.

Let me think about this some more..

ggerganov commented 3 years ago

So I guess it does have some value to be able to resize the canvas in single-client cases. For multi-client cases, one can now use the addVar() method that you recently introduced to propagate the canvas size to secondary clients and they can potentially resize their canvases as well. With that in mind, I think we can merge this chage.