QuestionDlg opened under ShowModal form

[Yurgenz]

Hello all.
OS Debian 12.5 64-bit XFCE, Lazarus 3.2.2 x86_64-linux-gtk2.

  I have a main form and a child form. The child form opened with ShowModal. When I call a QuestionDlg from the child form, it opens BETWEEN the main and child forms, lower in Z-order than the child form. If the child form is fullscreen, invisible dialog... frustrating. In Windows, dialog always appears on top of all forms. How do I display a QuestionDlg on top of a child form in Linux? Opening the child form with Show is undesirable.

[tetrastes]

Change DE to KDE or whatever else where modal forms are not always on top, as at XFCE (https://forum.lazarus.freepascal.org/index.php/topic,67254.msg517320.html#msg517320).
To be serious, if you managed to do that at XFCE or in general, please do not forget to show the solution.

[Yurgenz]

Using the "xprop | grep TYPE" command, it turned out that when using XFCE/xfwm4, ordinary windows have the window type _NET_WM_WINDOW_TYPE_NORMAL, modal windows - _NET_WM_WINDOW_TYPE_NOTIFICATION, dialogs - _NET_WM_WINDOW_TYPE_DIALOG. This explained a lot - notifications take precedence over dialogs. What to do with this is not yet clear.

[Yurgenz]

Tests result: the window type depends on the form property BorderStyle! If the form is opened with Show, then the window type _NET_WM_WINDOW_TYPE_NORMAL with any BorderStyle. And if the form is opened with ShowModal, then the window type directly depends on the BorderStyle:
 bsNone            _NET_WM_WINDOW_TYPE_NOTIFICATION
 bsSingle           _NET_WM_WINDOW_TYPE_NORMAL
 bsSizeable        _NET_WM_WINDOW_TYPE_NORMAL
 bsDialog          _NET_WM_WINDOW_TYPE_DIALOG
 bsToolWindow  _NET_WM_WINDOW_TYPE_UTILITY
 bsSizeToolWin  _NET_WM_WINDOW_TYPE_UTILITY

When window type _NET_WM_WINDOW_TYPE_DIALOG or_NET_WM_WINDOW_TYPE_UTILITY, the dialog appears on top of the form. But! The form can be activated and it will override (hide) the dialog, although the focus of input will remain on the dialog. Only _NET_WM_WINDOW_TYPE_NORMAL ensures that the form cannot overlap the dialog.

I use forms with BorderStyle = bsNone in the program and open them through ShowModal, so I came across a _NET_WM_WINDOW_TYPE_NOTIFICATION/_NET_WM_WINDOW_TYPE_DIALOG and related problem.

[AmatCoder]

Keep in mind that with Gtk2/Linux, modal windows prevent interaction with other windows in the same application but they does not keep on top of application windows by default. You must to use gtk_window_set_transient_for() for that.

So this seems like a bug in Lazarus:
    a) Dialogs from Lazarus are set transient only for the toplevel window.

    b) BsNone windows are set transient for all windows from application.

So BsNone windows are keeped on top of all windows, even dialogs.

[Thaddy]

You can only show additional dialogs over a modal form if the owner is not the main form, but the child form. Try that first, before you think it is a bug.
Modal forms are not supposed to behave like that, modal is modal.
Where did that silly idea come from? You made a logic error.

[Yurgenz]

AmatCoder, thank you!

You can only show additional dialogs over a modal form if the owner is not the main form, but the child form. Try that first, before you think it is a bug.

Thank you, I will try.

Modal forms are not supposed to behave like that, modal is modal.
Where did that silly idea come from? You made a logic error.

Sorry, I didn't get it. Can you explain in more detail?

[Thaddy]

If you have a modal form, which by nature is on top and fixed until closed, if you want a dialog on top of that, that can only be done if that dialog is owned and parented by the modal form. Not by the main form.
Showing extra dialogs on top of a modal form is not my style of programming - that is being kind -, but if you are desparate, you can achieve it like this. Has to be done in code, not through the designers.

[MarkMLl]

If you have a modal form, which by nature is on top and fixed until closed, if you want a dialog on top of that, that can only be done if that dialog is owned and parented by the modal form. Not by the main form.
Showing extra dialogs on top of a modal form is not my style of programming - that is being kind -, but if you are desparate, you can achieve it like this. Has to be done in code, not through the designers.

My gut feeling is that there is a thin line between modals and dialog(ue)s, depending on whether the underlying GUI provides e.g. a file selector as a predefined construct.

I suspect that there might also be "gotchas" involved due to the different way that the underlying OS implements (and in particular animates) the GUI. As a specific example, some old Delphi code of mine relied on the main procedure not returning, and (working from memory here) while it worked superficially on Lazarus any child form appeared on the screen but was quite simply never given any CPU.

So this is an area in which one should tread carefully.

MarkMLl

[Yurgenz]

I have a menu and many nested sub-menus. And all this on a small touchscreen. Sometimes you need to ask the user for confirmation - you need a dialog. Modal forms are very handy, but invisible dialog is horror.

OK. I figured out how to get rid of modal forms. The active form can dynamically set the property FormStyle=fsStayOnTop, nonactive - Enabled=False. Then the active form is always at the top and the dialog is above it.

I did a test project and tested it on Windows and Debian 12 (XFCE:xfwm4). It is attached to the post. Can someone check it out on other Linux configurations? I am interested in whether it is possible to hide the dialog under the form so that it does not go up, on whatever form you click.

[Yurgenz]

Screenshot

[MarkMLl]

OK on Debian+KDE, built for GTK2 or Qt5.

However remember that those form options are also likely to be Window Manager specific: don't ignore Thaddy's advice casually.

MarkMLl

[Yurgenz]

Thank you,  MarkMLl!

If I understand correctly, Thaddy suggested using TTaskDialog and making dialog with child form as Owner. I'll think about it.

[MarkMLl]

Thank you,  MarkMLl!

If I understand correctly, Thaddy suggested using TTaskDialog and making dialog with child form as Owner. I'll think about it.

Without checking the LCL source... the issue here is that the various form options translate fairly straight to window manager settings, which tend to be quirky and are not going to improve with the mess surrounding X11 vs Wayland.

Now I'm not saying that what you were doing is wrong, any more than I'm saying that what I was trying to do in my own anecdote was right. But you might find it useful to explore Thaddy's suggestion, in case the best way of keeping your code working as expected is to manipulate things at both the language/LCL level (ownership) and the LCL/window-manager level (window options).

Also remember that having untitled windows will confuse any software that uses wmctl etc. to work out what's actually on the screen. I think the major use of this is to determine whether an error dialog(ue) is visible, so since the dialogues still have titles (at least with the widget sets I've tested) you should be OK.

MarkMLl

[Zoran]

I don't think that Owner property has any influence on this.

You might get better results with setting PopupMode and PopupParent properties.

For how to use these properties, read the docs at the links above.

I am still not quite sure even this can help with some window managers.