I gather from your comment on my file selection dialogue, F95checker doesn't use standard mouse handling? Still doesn't work though in latest build. And in my iOS RD Client it still doesn't work at all, can't use the tool at all then. Almost feels as if this UI library has more issues than benefits judging by the OpenGL issues I've seen mentioned
the only issues so far were 2 if I remember correctly. 1 due to me not configuring correctly, and while fixing that one some people had invasive, outdated and incompatible software messing with it. Both fixed. Only one now is yours which I only have 1 single report of, and I haven’t been able to reproduce. And trust me it has caused WAYYY less headaches compared to what Qt does. Fuck qt.
also, standard mouse handling means nothing. It is up to the os to receive inputs. It is up to the application to interpret them. If you mean that it does not use window’s double click interval, well that’s not “standard” anyway. That is Windows’s interval for it, no more and no less. If you use windows interface components, they’ll use that. This is not using any interface components. The interface is an illusion. It is drawing rectangles and shapes on the window and interpreting the clicks and inputs in relation to them.
in terms of advantages, well I did explain it more in detail somewhere here before, but it’s hard to explain. It boils down to the process of programming the interface. With a “standard” toolkityou need to create all the interface components, then update their state based on changes. Say you change sorting, now I need to go through all game rows, hide them, remove and readd them to the layout in the correct order, and then show them again. Say you change what buttons are visible, now go through all games, disable and enable what buttons are needed. You have the interface already present and need to update as you go along. This is a VERY error prone way to code interfaces. Say you change a setting that should alter the interface, now that has to change the setting variable, update all the relevant interface components, and then request a redraw. With imgui instead you configure a step by step process to draw a complete interface. Every time the interface refreshes, it uses the same process. Only that this process is altered by some inputs, and given the same inputs you always get the same interface output. For example, say the draw cursor gets to the setting sidebar. In qt I need to have a drop down menu than when clicked it update all the elements inside it and hides them, or shows them, to simulate a drop down. With imgui instead it’s more like a variable check, is this drop down open? Thendraw the elements. If it is not, continue onto the next element after. And this variable is more often than not managed by imgui,so it boils down to (pseudo code):
Python:
if imgui.button(“Refresh!”):
start_refresh()
if imgui.dropdown(“Browser”):
settings.private_mode = imgui.checkbox(“Private mode”)
imgui.text(f“FPS: {imgui.io.framerate}”)
if imgui.dropdown(“Manage”):
if imgui.dropdown(“Import”):
if imgui.button(“Bookmarks”):
import_bookmarks()
if imgui.dropdown(“Export”):
if imgui.button(“Links”):
export_links()
with qt it would something like:
Python:
dropdown = qdropdown(“Manage”)
dropdown_button1 = qbutton(“Import”)
dropdown_button1.clicked.connect(import_bookmarks)
def toggle_dropdown(state):
dropdown_button1.setVisible(state)
dropdown_button2.setVisible(state)
dropdown.toggled.connect(toggle_dropdown)
sure you only have to setup the components and callbacks once, but it gets very hard to manage the state of the interface and ensure a consistent output. With imgui the interface is drawn based on its actual state, with qt I have toensure the state is correctly updated are represented based on hundreds of events and inputs. In the end it’s easier to understand, faster to write, and less error prone
