set_fullscreen(false) does not work on window creation

[litvinov-git]

Describe the bug

When certain windows (firefox --kiosk in my case) are created, they are in fullscreen, and set_fullscreen(false) on their creation does not work. I have not found any reliable ways to prevent windows from spawning in fullscreen

Reproduction steps

firefox --kiosk

Relevant parts of config

        Window.add_window_rule(function(window)
            window:set_decoration_mode("server_side")
            my_border(window):decorate()
            window:set_maximized(false)
            window:set_fullscreen(false)
        end)

Version info

pinnacle 0.2.3

Build Info:
Build profile: release
rustc version: 1.91.1
Branch: v0.2
Commit: b33d2fe (release: v0.2.3)

Distro

Arch

GPU

builtin i5

Config language

Lua

[Ph4ntomas]

I have not found any reliable ways to prevent windows from spawning in fullscreen

Currently, there's none.

Maximize/Fullscreen state are handled via two tristate (maximize|fullscreen|unset), one managed by the client, the other managed by the server/config. That second tristate have a priority on the first one so you could force the window to me maximized.

set_fullscreen(false) does unset the client fullscreen flag if present, but window rule may be applied before the client request to be fullscreen in which case there's nothing to remove.

I guess a correct way to handle this would be to have an set_fullscreen_override(Option<bool>), but IMO it's kinda a client bug to start fullscreen without leaving the user some way to configure that behavior.

Out of curiosity, do you have a real-world example ? The reproduction steps starts firefox in kiosk mode and while it's a useful test, it's kinda weird to want to override a client you've explicitly asked to be fullscreen.

[Ph4ntomas]

I guess a correct way to handle this would be to have an set_fullscreen_override(Option), but IMO it's kinda a client bug to start fullscreen without leaving the user some way to configure that behavior.

Maybe a better API would be to have some functions than can be called from the window_rule to sets capabilities on window:

local window_caps = {
  ---Usual arbitration. If the server flag is unset, the client requested state is applied.
  ---This is the default
  AUTO = 0,
  ---Ignore client request. Only the server may change the given state
  IGNORE = 1,
  ---Always respect client request. This allows clients to override state applied through the config
  RESPECT = 2,
}

window:set_capabilities({
    fullscreen: window_caps.IGNORE,
    maximize: window_caps.AUTO,
    minimize: window_caps.RESPECT,
})

@Ottatop any thought on that ?

[litvinov-git]

I have not found any reliable ways to prevent windows from spawning in fullscreen

Currently, there's none.

Maximize/Fullscreen state are handled via two tristate (maximize|fullscreen|unset), one managed by the client, the other managed by the server/config. That second tristate have a priority on the first one so you could force the window to me maximized.

set_fullscreen(false) does unset the client fullscreen flag if present, but window rule may be applied before the client request to be fullscreen in which case there's nothing to remove.

I guess a correct way to handle this would be to have an set_fullscreen_override(Option<bool>), but IMO it's kinda a client bug to start fullscreen without leaving the user some way to configure that behavior.

Out of curiosity, do you have a real-world example ? The reproduction steps starts firefox in kiosk mode and while it's a useful test, it's kinda weird to want to override a client you've explicitly asked to be fullscreen.

I tried to use kiosk to basically make separate "webapps" for things i use very frequently - messengers mostly.

i am transitioming from hyprland and there the idea worked trough some combination of profiles. On pinnacle those windows get decorated by firefox, even if i set server side decoration explicitly, so i tried to use kiosk.

that is also another issue - sometimes client decoration persists even when server side decoration is explicitly set in a window rule

i believe that comes from those windows being considered "option windows" of the main window, like "save as" dialogs and whatnot, even though they are not

[Ph4ntomas]

The protocol(s) for decoration is a bit weird. The client can request to be decorated, and the server can notify the client that it will be decorated, but since CSDs are drawn in the client surface, there's nothing the compositor can do if the client doesn't respect the protocol.

Gnome doesn't want SSDs, and as a result GTK refuses to respect the server requests and always apply CSDs (I think apps have a bit of control as to what's included in the CSD, but I'm steering clear from GTK, so I can't say).

I'm surprised it worked on hyprland, since the MR to support that is still unmerged in GTK (https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6161)

[Ottatop]

@Ottatop any thought on that ?

I'll have to think about it