Incidencia #43943

qt - dlogs can get lost behind map window

Abrir Fecha: 2022-02-20 12:37 Última actualización: 2022-06-27 11:53

Informador:
Propietario:
(Ninguno)
Tipo:
Estado:
Open
Componente:
Hito:
(Ninguno)
Prioridad:
5 - Medium
Gravedad:
5 - Medium
Resolución:
Ninguno
Fichero:
4

Details

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.

Ticket History (3/18 Histories)

2022-02-20 12:37 Updated by: ddeanbrown
  • New Ticket "qt - dlogs can get lost behind map window" created
2022-02-20 12:39 Updated by: cazfi
Comentario

Reply To ddeanbrown

Cloning this ticket from hostedredmine.

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

2022-05-09 10:15 Updated by: ddeanbrown
Comentario

The local options dlog and server options dlog also have the same problem.

2022-06-26 05:08 Updated by: cazfi
Comentario

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.

2022-06-26 06:00 Updated by: ddeanbrown
Comentario

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.

2022-06-26 06:08 Updated by: cazfi
Comentario

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.

2022-06-26 06:45 Updated by: cazfi
Comentario

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.

2022-06-26 12:25 Updated by: ddeanbrown
Comentario

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.

2022-06-26 22:08 Updated by: cazfi
Comentario

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.

2022-06-26 22:56 Updated by: cazfi
Comentario

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

2022-06-27 02:47 Updated by: ddeanbrown
Comentario

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

2022-06-27 11:43 Updated by: ddeanbrown
Comentario

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.

2022-06-27 11:53 Updated by: cazfi
Comentario

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)

Attachment File List

Editar

You are not logged in. I you are not logged in, your comment will be treated as an anonymous post. » Entrar