Window created/destroyed/layout_mode_change signals #368

anriha · 2025-10-03T00:03:39Z

This PR adds signals to track when windows enter or exit different layout modes (tiled, floating, maximized, fullscreen, and spilled).
When a window changes from one layout mode to another, the appropriate "unset" signal is fired for the previous state, followed by the "set" signal for the new state. This allows configurations to react to both entering and exiting specific window states. The signal is also fired when the window first spawns.

This PR adds signals for window creation and destruction. It also adds a layout mode change signal. This should address all the suggestions in this PR. I am not completely sure if the destroyed signal is correct like this in regard to unmap flag. But from my testing, this gave me the results I wanted.

I would also really appreciate it if someone checked my lua changes, I have basically no knowledge of lua, so I am just copying and pasting. I think it is right, but I am not sure how to actually check.

resolves #365

Ottatop · 2025-10-03T04:51:46Z

I think it's simpler if we have just one signal, LayoutModeChanged, that sends the new layout mode for a window when it changes.

anriha · 2025-10-03T10:55:37Z

You are right, that would be simpler. But I still think it makes sense to add the information about what layout mode it went from. One of my use cases that I plan for this is to add idle inhibitors to windows. Currently, when you are playing wine game via xwayland there is no way to get idle inhibitor on the window. This is usually fine as you are using mouse/keyboard. But if you play a game with just controller, that doesn't register as any activity. So I want to be able to add when window goes fullscreen add idle inhibitor, when it leaves remove it.

So I think it might make sense to change it to one signal, something like WindowLayoutModeChanged which would get the old_mode: Option<LayoutModeKind>, new_mode: Option<LayoutModeKind>. If the window was new the old_mode would be None. And if the window was closing (which I didn't handle at all thinking about it) the new_mode would be None.

Ph4ntomas · 2025-10-03T11:24:55Z

So I want to be able to add when window goes fullscreen add idle inhibitor, when it leaves remove it.

You don't need to know the old mode for this to work (that doesn't mean it won't be useful for other stuff).

So I think it might make sense to change it to one signal, something like WindowLayoutModeChanged which would get the old_mode: Option, new_mode: Option. If the window was new the old_mode would be None. And if the window was closing (which I didn't handle at all thinking about it) the new_mode would be None.

I think the Close should have its own signal, too. But sending one with a empty/None new_mode is still a good idea to allow for cleanup

Ph4ntomas · 2025-10-03T11:40:19Z

src/window/layout.rs

+            match old_mode.current() {
+                crate::window::window_state::LayoutModeKind::Floating => {
+                    self.signal_state.window_unset_floating.signal(window);
+                }
+                crate::window::window_state::LayoutModeKind::Tiled => {
+                    self.signal_state.window_unset_tiled.signal(window);
+                }
+                crate::window::window_state::LayoutModeKind::Maximized => {
+                    self.signal_state.window_unset_maximized.signal(window);
+                }
+                crate::window::window_state::LayoutModeKind::Fullscreen => {
+                    self.signal_state.window_unset_fullscreen.signal(window);
+                }
+                crate::window::window_state::LayoutModeKind::Spilled => {
+                    self.signal_state.window_unset_spilled.signal(window);
+                }
+            }
+
+            match new_mode.current() {
+                crate::window::window_state::LayoutModeKind::Floating => {
+                    self.signal_state.window_set_floating.signal(window);
+                }
+                crate::window::window_state::LayoutModeKind::Tiled => {
+                    self.signal_state.window_set_tiled.signal(window);
+                }
+                crate::window::window_state::LayoutModeKind::Maximized => {
+                    self.signal_state.window_set_maximized.signal(window);
+                }
+                crate::window::window_state::LayoutModeKind::Fullscreen => {
+                    self.signal_state.window_set_fullscreen.signal(window);
+                }
+                crate::window::window_state::LayoutModeKind::Spilled => {
+                    self.signal_state.window_set_spilled.signal(window);
+                }
+            }
+


This is not the only place the layout can change.

For example (there might be other instances):

src/layout.rs:108

src/api/window.rs:{443, 453, 459, 469}

IMO, it's better to handle this from State::on_event_loop_cycle_completion() rather than sprinkle the call to self.signal_state.window_*.

If you need the old value, it could be held in the window LayoutMode until the end of the loop, then from the aforementioned function, you'd iterate over windows to clear this value and send the old/new pair.
If you don't need the old value, just a boolean would work.

This should prevent missing layout changes.

(You may want to wait for Ottatop input on that first)

Yea I think having an old_layout_mode: LayoutMode, checking to see if the current mode != the old mode to send the signal, and copying the current mode to the old mode in on_event_loop_cycle_completion is the simplest solution.

anriha · 2025-10-03T11:45:09Z

You don't need to know the old mode for this to work (that doesn't mean it won't be useful for other stuff).

You do need to know when the window stops being fullscreen, so you can remove the idle inhibitor. You could track it internally in your configuration, but that would be more complicated.

Ph4ntomas · 2025-10-03T12:20:35Z

You don't need to know the old mode for this to work (that doesn't mean it won't be useful for other stuff).

You do need to know when the window stops being fullscreen, so you can remove the idle inhibitor. You could track it internally in your configuration, but that would be more complicated.

I already said that it might still be useful, but I still don't see the need for that use-case.

EDIT: Just to be clear, I'm not saying the old_mode shouldn't be sent. This is not up to me anyway.

You could track it internally in your configuration, but that would be more complicated

Just having the information doesn't solves your issue cleanly, so you'd still need to track some state in your config:

Let say for the sake of argument you want to use one global inhibitor if a window is full-screen, and you have this initial state:

window A { mode = Fullscreen }
window B { mode = Tiled }
Inhibitor { active = true }

You swap WindowA & WindowB (or fullscreen B then un-fullscreen A).

The following signal will be emitted:

WindowA::LayoutChanged( old = Fullscreen, new = Tiled }
WindowB::LayoutChanged( old = Tiled, new = Fullscreen }

There is no guarantee which signal will arrive first. If WindowB signal arrive first, the following sequence will happen:

WindowB::LayoutChanged( old = Tiled, new = Fullscreen }
Inhibitor::setActive() // ok, was already active
WindowA::LayoutChanged( old = Fullscreen, new = Tiled }
Inhibitor::setInactive() // there is still an active window, but the inhibitor was deactivated.

You can solve this by:

Reference counting Inhibitor activation/de-activation -> you do need to know the window previous mode
Having the inhibitor track which window is full-screen -> you don't need to know the window previous mode
Maintaining a set of fullscreened window -> you don't need to know the window previous mode
Having an inhibitor instance per window -> you don't need to know the window previous mode

anriha · 2025-10-03T13:36:45Z

EDIT: Just to be clear, I'm not saying the old_mode shouldn't be sent. This is not up to me anyway.

Don't worry, I don't mind discussing this.

What I plan to do is to add a way to manually insert idle inhibitor for the window itself. I think that would be cleaner than using one global idle inhibitor. Plus, it would work better if the fullscreen surface is not visible. At that point, the idle inhibitor shouldn't probably be active.

Ottatop · 2025-10-04T05:21:53Z

I think it's best to just send the new mode for now. If we send both modes then the old has to be an Option and is only None for the first signal, which I don't like.

anriha · 2025-10-04T11:29:31Z

Ok, in that case, how about this approach. I do need to know what is the window initial layout mode when it spawns, I need to know when it changes, and when it closes. So how about I add new signals, something like window created/destroyed. These would just give you window_id and you can then use API to get its layout mode. And I do just add WindowLayoutModeChanged.

For my use case, this would make it a bit more complicated to keep track of everything in my config, but it would be doable and it would address the issue.

Theoretically we wouldn't even need window created signal, as add_window_rules could be used for this, but I think adding new signal for this is cleaner. As the add_window_rules shouldn't be used for this.

Ottatop · 2025-10-06T00:16:29Z

Yea, an open and closed signal is good.

anriha · 2025-10-16T03:00:29Z

I changed PR to hopefully address all the comments here.

- Add new signals: WindowLayoutModeChanged, WindowCreated, WindowDestroyed - Move LayoutMode enum to util.proto for shared usage - Add tracking of window layout mode changes in on_event_loop_cycle_completion

Ph4ntomas

You missed a few types when moving LayoutMode to util, but the lua changes are fine as far as I can tell

api/lua/pinnacle/window.lua

api/lua/pinnacle/signal.lua

…ow.lua

api/protobuf/pinnacle/util/v1/util.proto

api/rust/src/signal.rs

src/state.rs

src/handlers/xwayland.rs

- Replace unwrap_or with if let for safer conversion in signal.rs - Move window layout mode change check to dedicated method in window.rs - Remove redundant window_created signal in xwayland.rs

api/lua/pinnacle/signal.lua

…layout modes

api/lua/pinnacle/window.lua

Ottatop

Thanks!

anriha force-pushed the layout_signals branch from 100423e to 0860c45 Compare October 3, 2025 00:06

Ph4ntomas reviewed Oct 3, 2025

View reviewed changes

anriha force-pushed the layout_signals branch from 0860c45 to b839510 Compare October 16, 2025 02:54

anriha changed the title ~~Add window layout state change signals~~ Window created/destroyed/layout_mode_change signals Oct 16, 2025

feat(api): add window lifecycle and layout mode signals

2326b3d

- Add new signals: WindowLayoutModeChanged, WindowCreated, WindowDestroyed - Move LayoutMode enum to util.proto for shared usage - Add tracking of window layout mode changes in on_event_loop_cycle_completion

anriha force-pushed the layout_signals branch from b839510 to 2326b3d Compare October 16, 2025 03:14

Ph4ntomas reviewed Oct 16, 2025

View reviewed changes

api/lua/pinnacle/window.lua Outdated Show resolved Hide resolved

api/lua/pinnacle/signal.lua Outdated Show resolved Hide resolved

fix(signal): correct LayoutMode type reference in signal.lua and wind…

a1819e1

…ow.lua

Ottatop reviewed Oct 19, 2025

View reviewed changes

api/protobuf/pinnacle/util/v1/util.proto Outdated Show resolved Hide resolved

api/rust/src/signal.rs Outdated Show resolved Hide resolved

src/state.rs Outdated Show resolved Hide resolved

src/handlers/xwayland.rs Outdated Show resolved Hide resolved

anriha force-pushed the layout_signals branch from be35085 to 4531c42 Compare October 21, 2025 18:33

refactor: improve window layout mode change handling

e9ecda7

- Replace unwrap_or with if let for safer conversion in signal.rs - Move window layout mode change check to dedicated method in window.rs - Remove redundant window_created signal in xwayland.rs

anriha force-pushed the layout_signals branch from 4531c42 to e9ecda7 Compare October 21, 2025 18:34

fix(window): move LayoutMode enum back to window.proto

b83f050

Ottatop reviewed Oct 21, 2025

View reviewed changes

api/lua/pinnacle/signal.lua Outdated Show resolved Hide resolved

api: Change WindowLayoutModeChanged callback signature to use string …

8039c17

…layout modes

Ottatop reviewed Oct 22, 2025

View reviewed changes

api/lua/pinnacle/window.lua Outdated Show resolved Hide resolved

api: remove unspecified window layout mode variant

efb0422

Ottatop approved these changes Oct 22, 2025

View reviewed changes

Ottatop merged commit 49c874f into pinnacle-comp:main Oct 22, 2025
4 checks passed

Uh oh!

Window created/destroyed/layout_mode_change signals #368

Window created/destroyed/layout_mode_change signals #368

Conversation

anriha commented Oct 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ottatop commented Oct 3, 2025

Uh oh!

anriha commented Oct 3, 2025

Uh oh!

Ph4ntomas commented Oct 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ph4ntomas Oct 3, 2025

Choose a reason for hiding this comment

Uh oh!

Ph4ntomas Oct 3, 2025

Choose a reason for hiding this comment

Uh oh!

Ottatop Oct 4, 2025

Choose a reason for hiding this comment

Uh oh!

anriha commented Oct 3, 2025

Uh oh!

Ph4ntomas commented Oct 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

anriha commented Oct 3, 2025

Uh oh!

Ottatop commented Oct 4, 2025

Uh oh!

anriha commented Oct 4, 2025

Uh oh!

Ottatop commented Oct 6, 2025

Uh oh!

anriha commented Oct 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ph4ntomas left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Ottatop left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

anriha commented Oct 3, 2025 •

edited

Loading

Ph4ntomas commented Oct 3, 2025 •

edited

Loading

Ph4ntomas commented Oct 3, 2025 •

edited

Loading

anriha commented Oct 16, 2025 •

edited

Loading