Willy-JL / F95Checker

GNU General Public License v3.0
101 stars 16 forks source link

[Linux] broken the filepicker #71

Closed ParaplegicRacehorse closed 11 months ago

ParaplegicRacehorse commented 1 year ago

Linux. (Manjaro GNOME. OpenSUSE Tumbleweed KDE) Precompiled binary. v.10.2

When attempting to navigate the filepicker: arrow keys, vim keys, no keyboard combination seems to move the selection up or down the filepicker list. I am able to select a different subdir directly with the mouse cursor. Scrolling with mousewheel or trackpad gesture works as expected. Utilizing the file:// URI scheme also fails (for binaries. Did not try HTML or JS or WASM files.)

When attempting to select the executable for a game, the file picker properly opens to the basedir I configured in the settings. It then refuses to enter a subdirectory. Double-click does not work. Pressing "enter" key does not work.

Is it possible to offload filepicker duties to the OS-defined filepicker?

Willy-JL commented 1 year ago

Is it possible to offload filepicker duties to the OS-defined filepicker?

technically speaking, yes. in reality, no. the interface toolkit im using works completely different to any standard toolkit, and hacking in an existing filepicker would cause all kinds of issues. thats why i made my own filepicker widget using said toolkit

as for the issues youre having:

the real issue is double click not working for you. that is most likely due to your window refreshrate being off, so clicks arent being registered properly. make sure your Interface > Vsync Ratio is set to 1:1 and that the Current framerate hovers around 60 (or what your monitor uses if its different).

ParaplegicRacehorse commented 1 year ago

Vsync is 1:1 current framerate varies 155-165, depending on whether the mouse cursor is moving. I don't know my screen refresh rate. It has never been important to me.

Now, it has become interesting to me that you're using a GUI toolkit that redraws itself continuously, instead of only when something changes. That explains why there is ghost-refresh when it is not the focused window but all or part of it is visible. Are you developing this with a game engine? I can't think of anything else that might want to continuously redraw the window...

Uh... That's all off-topic.

Vsync is 1:1. Refresh rate is 150+. No other programs, including other game-engine based non-game applications, have this problem. Indeed, only the filepicker has this problem, and the problem is only with double-clicks; sincle-clicks works okay.

ParaplegicRacehorse commented 1 year ago

the interface toolkit im using works completely different to any standard toolkit

PyQt6, right? (taken from header of gui.py).

What's wrong with QFileDialog?

Willy-JL commented 1 year ago

the interface toolkit im using works completely different to any standard toolkit

PyQt6, right? (taken from header of gui.py).

What's wrong with QFileDialog?

Nope, qt is only for the system tray icon and for the webviews (run as a parallel process). The main interface is made with imgui running through opengl and glfw.

Now, it has become interesting to me that you're using a GUI toolkit that redraws itself continuously, instead of only when something changes. That explains why there is ghost-refresh when it is not the focused window but all or part of it is visible. Are you developing this with a game engine? I can't think of anything else that might want to continuously redraw the window...

Uh... That's all off-topic.

Answered it a couple times somewhat ago in the f95zone thread, I’ll give a brief roundup. Classic gui’s are designed imperatively: you create widgets, put them in places, update their status and so on. You need to remember to do all those things, else the interface won’t reflect the state of the program. I much prefer the immediate design of imgui, instead of creating widgets, you create a set of instructions for how to draw the interface based on the programs state, so what the user sees and what the program is doing literally can’t go out of sync. And another result of this is that it fits my way of thinking about an interface much better, I either “draw a button or I don’t”, it’s not “I have to hide the button and show it later”.

Vsync is 1:1 current framerate varies 155-165, depending on whether the mouse cursor is moving. I don't know my screen refresh rate. It has never been important to me.

Try bumping it up a bit then, maybe 1:2 or 1:3 might work well. Or maybe your system’s double click interval is set weirdly. Because what’s happening is that it fails to recognize the 2 clicks as a double click

ParaplegicRacehorse commented 1 year ago

1:2 worked, but was unreliable. 1:3 worked (reported FPS now 55-60) and is still unreliable. In both cases, continuous double-clicking eventually registers. It's very finger tiring, though.

Willy-JL commented 11 months ago

welli cant manage to replicate it, works fine here. you can try to tweak your double click speed in your desktop environment maybe