qt - dlogs can get lost behind map window
ddeanbrown Reply To ddeanbrown
Cloning this ticket from hostedredmine.
Please provide a link to the original report when doing that.
ddeanbrown ddeanbrown The local options dlog and server options dlog also have the same problem.
Maybe this is because they have no parent set, but are top level windows themselves? So nothing tells the system that they should be treated as something to appear in relation to the freeciv window.
Attaching trivial test patch for the help dlg case.
ddeanbrown Tried the patch and it made no difference. I think need to make the dialog modal. If that's not possible, then re-doing whatever causes the dialog to appear should bring it to the front if it's already open but hidden.
Reply To ddeanbrown
I think need to make the dialog modal.
Not so loudly. We've worked hard to get rid of modal dialogs on all clients, as they were considered the most evil thing by bloodthirsty multiplayer game players. We don't want to enable "trigger modal window on enemy's screen to prevent them from reacting quickly" tactics again.
Two testing patches attached. All the changes made are "hints" or "wishes" for the system, i.e., there's no guarantee that window manager grants them.
Both patches likely apply to all branches, but on freeciv-3.0 we support older Qt version than 5.9, that is the minimum version providing functionality used by the "better" patch. If both patches work, ideally we would push the old-style implementation to S3_0, and newer one to S3_1 and master.
One change is that help dialog is requested to always remain on top.
The other change is that if it isn't on top despite the fist change, selecting a new entry from the help menu should bring it front.
All changes are made for the help dialog only.
ddeanbrown Both of the new patches work on my Mac (which has Qt 5.15.2), but it works too well. The help dlog stays on top even when I switch to a different app, like to my web browser. Yikes!
By itself, the call to help_dlg->setWindowState(Qt::WindowState::WindowActive); doesn't bring it to the front. Maybe need something like help_dlg->bringToFront();
Re. modal dialogs - I don't understand how you can trigger the help/options dlogs on someone else's client, but I haven't played multi-player so I wouldn't know.
Reply To ddeanbrown
Both of the new patches work on my Mac (which has Qt 5.15.2), but it works too well. The help dlog stays on top even when I switch to a different app, like to my web browser. Yikes! By itself, the call to help_dlg->setWindowState(Qt::WindowState::WindowActive); doesn't bring it to the front.
According to web searches all this is a rather common problem, where nobody seems to come up with an universal solution - these things work so differently on different platforms.
I wonder if we could do such trickery that we set Qt::WindowStaysOnTopHint (which you said to "works too well") when we want the window to come top, and then clear the flag again once we are sure (how?) that the window now is on top.
Reply To cazfi
According to web searches all this is a rather common problem, where nobody seems to come up with an universal solution - these things work so differently on different platforms.
Then again, maybe this has lead me to think too complicated - maybe the solution for the Mac problem at hand is as trivial as raise() the window? Another test patch attached...
ddeanbrown We have a winner, this patch works OK. Still also need to do the same for the options dlogs.
ddeanbrown Experimented and found adding
opt_dialog->raise();
at line #785 in routine option_dialog_popup() in optiondlg.cpp fixes the problem for the option dlogs.
Yeah, I think that for a commit-quality patch we need to implement the change to our dialog class (that would cover both helpdlg and options. IIRC diplodlg doesn't use it and would need to be handled separately)
It would be good if you could test also this/these commit-candidate patches.
ddeanbrown Tested and everything looks OK. Go ahead and commit.
Cloning this ticket from hostedredmine. Seen in 3.0.0
Help, diplomacy dlogs get hidden when you click on the main window (usually the map window F1, but also others like research F6 or Nations F3). Especially bad for the help dlog because you then can never see it again unless you turn off Fullscreen and resize the map window to make it smaller. Those dlogs should be modal or at least always on top.
Chippo chiphog@gmail.com says he sees the same bug on Linux/Openbox, but not on Linux/wayland-gnome-something.