Freeciv

Reply To ddeanbrown

Cloning this ticket from hostedredmine.

Please provide a link to the original report when doing that.

https://www.hostedredmine.com/issues/929314

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.

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.

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...

We have a winner, this patch works OK. Still also need to do the same for the options dlogs.

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)