Closed wr3ckt1fy closed 1 year ago
@wr3ckt1fy So this happened after you clicked | + | , right?
It is supposed to open a file dialog to locate the engine's executable on the top of what you see in your screenshot. Like this
The file dialog is modal so while it's open, everything under it doesn't listen to events, so it appears frozen.
Isn't it possible that the file dialog opened in some weird way that it is not visible? Like for example that it appeared on another monitor, or possibly on coordinates of a monitor that is no longer connected?. Linux graphical environments sometimes bug like that.
I remember that once i started some app, moved it's window to my secondary monitor, then closed the app, disconnected the monitor, started the app again, and the window was created in the space of the screen representing the disconnected monitor. So i had to connect the monitor, move the window back to my primary screen, and then disconnect the monitor, otherwise it wouldn't be visible.
Yes, it happens after I click | + |. I see what you mean by it opening another modal window. See below screenshot. However it appears as if it hasn't rendered properly, i.e. blank. I don't have another monitor plugged into this computer, however I checked other Workspaces and I changed my resolution a couple times to see if it would fix anything, to no avail.
UPDATE: Upon more troublshooting, this issue only occurs when I click Menu->Initial Setup when the "Files" tab is open. If I go to either "Launch Options" or "Output Options" tabs, then click Menu->Initial Setup, I get the file dialog modal window.
Odd, but that was the "workaround."
I'm still trying to figure this out on Linux, but I'll try to help you optimize your program as I go on this Linux journey!
Problem I was encountering from "Files" tab:
File dialog popup when the "Launch Options" is the current tab:
Hm, that's super weird. Even more so, because i don't use any special non-portable hacks to show the file dialog, only standard, well documented and widely used function https://doc.qt.io/qt-6/qfiledialog.html#getOpenFileName
Can you please try something, because it works on my Kubuntu. Open Initial Setup, set some map directory other than root ("/"), click Done, then open Initial Setup again and click Add engine.
Also, do you have some task manager that would show you which resources does an application consume. Can you check, if DoomRunner is for example doing a lot of disk reading, or using full CPU core?
Results: Setting map directory to other than root "/", click Done, then open Initial Setup again: SAME RESULT.
DoomRunner is doing something in the background at all times. No matter the state, it's always using 4-5% CPU (i5-12600K). There does not appear to be any Disk Read/Write. Usually says N/A.
Screenshot of resource monitor:
Believe it or not, it was found that even the "Add mods" button (and probably others that require File Dialog Modal WIndows) did not work on the Files tab. Is there some weird state the program is in or a variable that is not being called properly for system level file windows based on MainWindow (P.S. I'm not a programmer, just trying to interpret code lol sorry).
So a summary:
Unfortunately I'm at a state where because of this Files tab not working, I'm not able to create any mod presets or lists 😢. Thanks for trying to look into this. I do have Visual Studio Code, not sure if that can help with any debugging. I've never used it, but I've always wanted to try one day.
Thats looks like a bug of Qt. It seems it just gets stuck in an infinite loop somewhere inside QFileDialog::getOpenFileName
. All i can do is report it to Qt and hope for some fix or advice for workaround.
Visual Studio Code won't help here. If you really wanted to try to debug this, you would have to install Qt Creator, download this git repository, open the DoomRunner.pro
in it, then start debugging, and pause the program when it gets stuck.
But i'm affraid even then we wouldn't see enough, because in standard release version of Qt, it would show only names of functions.
Seems very similar to this issue https://bugreports.qt.io/browse/QTBUG-59184 (reported in 2017 and not fixed until today :disappointed:)
By reading the comments, i made 2 different workarounds, can you please try them out? DoomRunner-DontUseNativeDialog.zip (uses Qt's own file dialog instead of the standard system one) DoomRunner-nullptrParent.zip (doesn't set a parent window for the file dialogs) (both of them applies the workaround for "Add engine" button but not for "Add IWAD" button, so that you can compare the results)
Also, please try running DoomRunner from terminal, to see if there aren't any warning log messages.
I can confirm "Don't use native dialog" solves this issue for me on Drauger OS 7.6 XFCE (Ubuntu 22.04 base). "nullptrParent" had the same "where is the window issue" as the current release.
Update: I realized I needed to add another WAD and started the initial setup dialog which did the hidden window trick.
I think I'm going to like this launcher much better than ZDL. Thank you for making it.
RESULTS
Note: for some reason, after fiddling with both DontUseNativeDialog and nullptrParent versions, my 1.6.3 lost most options.json entries. Got a bunch of messages saying things were missing. Not sure what went wrong there. Perhaps you may want to look into what is happening. UPDATE: Actually, it may be because I had two instances running at the same time.
Should be fixed in 1.6.4
@Youda008 Thank you! It seems to be working great for me so far.
Any subwindow that opens from the Initial setup window stalls and is unresponsive. Nothing can be changed. Only Alt+F4 can close the window.
This was using a compiled version of Doom Runner 1.6.3.
Pop!_OS 22.04 LTS Doom Runner 1.6.3 Qt Ver 5.15.3
Example Window:![image](https://user-images.githubusercontent.com/98293028/194728798-502996f6-e6c2-4d3b-a7c2-58054caafc6f.png)