GtkWindow destroyed when changing tty since wlroots 0.19

[Tamaranch]

Create a layer shell window simply with this code:

  GtkWidget *window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  gtk_widget_set_size_request (window, 400, 40);
  gtk_layer_init_for_window (GTK_WINDOW (window));
  gtk_layer_set_monitor (GTK_WINDOW (window), gdk_display_get_monitor (gdk_display_get_default (), 0));
  gtk_window_present (GTK_WINDOW (window));

Then change tty with Alt-Fn and return: the window has disappeared, and you can verify that the GtkWidget::destroy signal has been emitted by connecting a signal handler to it.

Setting a default size is necessary for me for the window to show up, in general: I don't know if the problem is new.

There are also cases where assigning a monitor to the window is not necessary for it to be destroyed, but perhaps only in multi-monitor mode (with possibly several tty changes).

Versions:

• gtk-layer-shell 0.9.2 or 0.9.2+4+gac95e22
• wayfire 0.10.0
• labwc 0.9.0

[wmww]

My guess is what's going on when you TTY switch is

• Wayfire removes the output, since it's not longer active on it
• Wayfire logic requests all layer surfaces on removed outputs be closed
• this request gets handled and converted to a GTK window close request by gtk-layer-shell
• your app respects this request and closes

If true you should be able to change this behavior in your app by attaching to the window's delete-event signal and returning TRUE (note this would be close-request for GTK4). In testing this seems to work, though there's a lot of variables.

It might be more correct for gtk-layer-shell to completely ignore this close request, or ignore it by default and have a way for apps to explicitly opt in to responding to it. If compositors send .closed reliably that might be useful, but unfortunately the protocol doesn't demand they send it in any particular case, so I suspect they don't. I'll think on it.

[Tamaranch]

Yes, monitors are disconnected when changing tty since wlroots 0.19. I had already opened a bug report about this on labwc: labwc/labwc#2939

And indeed, you are right, it is the GtkWidget::delete-event signal that is emitted. And contrary to what I said at first, it is not specific to wayfire; I can also reproduce the problem on labwc. I was misled by the fact that initially, I encountered this problem with xfce4-panel only on wayfire, where whether or not the panel is anchored to the edge of the screen affects the result. Similarly, in the case of xfdesktop, where layer-shell windows cover the entire surface of the monitors, they are not destroyed...

Well, in the end, it's problematic in any case. You can indeed connect gtk_true to GtkWidget::delete-event, but you really don't expect to have to do that. These windows should not be closed just because the monitor they were on has disappeared, in my opinion.

[ammen99]

This wlroots MR (and the linked issues) explain why this happens, and why it did not happen before: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/5127

[Tamaranch]

I feel like the best thing would be to intercept GtkWidget::delete-event here anyway, #210 would do it for me.

[ammen99]

These windows should not be closed just because the monitor they were on has disappeared, in my opinion.

On the contrary, layer-shell surfaces are tied to a particular wl_output. If the wl_output goes away, then the surfaces have to be closed as well. Just my 5 cents of course.

[wmww]

@ammen99 There's two main cases:

• the app is output-aware. it listens for changes in outputs, creates new layer shell surfaces for new outputs and destroys them when outputs go away
• the app is not output aware. it creates one layer shell surface and expects it to remain open on an arbitrary active output

In both cases the app does not need respect the .closed event. In the first case because it also sees the output remove event and in the second because staying open and being placed on a new output if it appears is desirable.

The being said, preventing the app from being able to get access to this event seems bad. It's a feature of the protocol, and therefore should be accessible. My thought is by default it is ignored, but there's a function you can call to enable handling. If handling is enabled you get the delete-event signal, and can either auto-close or attach a handler for that. This change would be rolled out to both the GTK3 version and GTK4 version. Thoughts?

[wmww]

Does #211 seem like the best approach? I generally wouldn't be adding API to this library anymore, but the need to change the default behavior comes from the change to wlroots, and I want it to be configurable.

[ErikReider]

LGTM :)

[wmww]

Posted summery to the wlroots issue https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/5127#note_3152932

[Tamaranch]

Does #211 seem like the best approach?

Good for me too!