Modal dialogs appear behind toplevel window if set by layer-shell-qt about labwc

[tokyo4j]

Hm.. we do move layershell popups to their own popup tree per output that is positioned above the "overlay" tree (but below the session-lock tree):

(note: the comment above is actually wrong, they are moved to a dedicated layer popup tree rather than the top layer)

However we only do so for layershell parents <= "bottom" layer:

So we should likely just move all layershell popups to the dedicated popup tree.

I think it's another topic. Dialogs can be decorated (e.g. confirmation dialog shown on quitting QTerminal) so popups are not suitable for this.

But I agree that current implementation of layer-shell popups feels strange. At least the reason why we do so only for bottom/background layer should be documented in comment.

[Consolatis]

I think it's another topic. Dialogs can be decorated (e.g. confirmation dialog shown on quitting QTerminal) so popups are not suitable for this.

Whoops, somehow missed this comment:

Those dialogs (preferences and confirmation for pasting multiline text) are just normal windows and are seen in switcher and lxqt-panel's taskbar.

That is indeed something different. And I have absolutely no idea how we (or in fact any other compositor) could make that work without using some private wayland protocol. When layershell clients with layer "top" or above spawn a new xdg_toplevel, it will always be rendered below the layershell client if their surfaces overlap.

The layershell protocol is not really intended to be used for usual applications like terminal emulators but rather for notification daemons, backgrounds, desktops and panels.

[tokyo4j]

From all compositors I've tested only kwin gets this right.

I built QTerminal and started in Kwin, but its preference window is shown behind the terminal window, just like in labwc. Could you tell me how you managed to make it shown on top?

[stefonarch]

Oh, yes you're right. I tested on a clean user and it's like in your screenshot. I noticed I've left over a window rule in kwin from when dropdown wasn't supported.

I see just a window rule for "normal window" is enough.

[stefonarch]

Oh, yes you're right. I tested on a clean user and it's like in your screenshot. I noticed I've left over a window rule in kwin from when dropdown wasn't supported.

I see just a window rule for "normal window" is enough.

[stefonarch]

I tried with labwc rules "Raise" and "alwayOnTop" but those won't work.

[droc12345]

I'm curious, does the dialog show in the window switcher?

[stefonarch]

I'm curious, does the dialog show in the window switcher?

Those dialogs (preferences and confirmation for pasting multiline text) are just normal windows and are seen in switcher and lxqt-panel's taskbar.

[tokyo4j]

Oh, yes you're right. I tested on a clean user and it's like in your screenshot. I noticed I've left over a window rule in kwin from when dropdown wasn't supported.

I added the window rule in KWin but it didn't work.

But AFAIR there's no way for clients to tell compositor that a wlr_layer_surface is the parent of xdg_toplevel. When the parent window is xdg_toplevel, clients can send xdg_toplevel.set_parent so the compositor always places the dialog above the parent window. wlr-layer-surface protocol doesn't have any request like that.

Perhaps KWin uses another protocol for this but I have no idea.

[Consolatis]

Hm.. we do move layershell popups to their own popup tree per output that is positioned above the "overlay" tree (but below the session-lock tree):

labwc/src/layers.c

Lines 436 to 457 in 1495708

	/*
	* We move popups from the bottom to the top layer so that they are
	* rendered above views.
	*/
	static void
	move_popup_to_top_layer(struct lab_layer_surface *toplevel,
	struct lab_layer_popup *popup)
	{
	struct server *server = toplevel->server;
	struct wlr_output *wlr_output =
	toplevel->scene_layer_surface->layer_surface->output;
	struct output *output = (struct output *)wlr_output->data;
	struct wlr_box box = { 0 };
	wlr_output_layout_get_box(server->output_layout, wlr_output, &box);
	int lx = toplevel->scene_layer_surface->tree->node.x + box.x;
	int ly = toplevel->scene_layer_surface->tree->node.y + box.y;
	struct wlr_scene_node *node = &popup->scene_tree->node;
	wlr_scene_node_reparent(node, output->layer_popup_tree);
	/* FIXME: verify the whole tree should be repositioned */
	wlr_scene_node_set_position(&output->layer_popup_tree->node, lx, ly);
	}

(note: the comment above is actually wrong, they are moved to a dedicated layer popup tree rather than the top layer)

However we only do so for layershell parents <= "bottom" layer:

labwc/src/layers.c

Lines 499 to 502 in 1495708

	if (surface->layer_surface->current.layer
	<= ZWLR_LAYER_SHELL_V1_LAYER_BOTTOM) {
	move_popup_to_top_layer(toplevel, popup);
	}

So we should likely just move all layershell popups to the dedicated popup tree.

[johanmalm]

layer_popup_tree is output specific though, so needs to be different, doesn't it?

--EDIT-- Ignore me. Can't read properly.

[tsujan]

The layershell protocol is not really intended to be used for usual applications like terminal emulators...

It isn't usual in the sense that it's in the drop-down mode.

Moreover, Wayland has left no other option for us.

[stefonarch]

The layershell is needed only to set position on screen centered at top, which would need fiddling with window rules otherwise, depending on the screen size.

[tsujan]

... which would need fiddling with window rules otherwise

In this case, window rules are out of question because the drop-down terminal should to be positioned as it is now. Window rules are good when the user likes to put a window somewhere, or when there's no other way.

[Consolatis]

Completely random idea: what if the terminal uses an exclusive zone? Newly spawned windows should then be placed outside of that zone AFAIR. However it would also make existing maximized / snapped windows smaller as long as the terminal is visible.

[tsujan]

However it would also make existing....

Annoying UX ;)

[stefonarch]

It would be huge usually and there would be no place for the preferences window.

[johanmalm]

I can't reproduce. Have tried with qterminal --drop (2.0.0) but it doesn't appear in overlay-layer so I'm guessing we're talking about an unreleased branch.

If the PID of the layer-shell-client is the same as the dialog (which I'm guessing it would be), we could use that in some logic to position the dialog in a tree above overlay-tree.

[stefonarch]

It was released just 2 days ago, but for another reason. The pid is the same.