message ActiveWindow
Control plane
message ActiveWindow
Which window has the keyboard now.
The compositor is the only process that knows, and until this there was no way for a second client to find out — which is why a panel could show a clock and nothing about the windows it sits above. A global menu is the first thing that genuinely needs it: the menu on the panel is the focused window's menu, and a panel guessing would show the wrong app's File menu.
A window, not an app: two windows of one process are two entries, because they are two menus and the user is looking at one of them.
idl/lava.npidl:423
Fields
pid: u32
Unix pid of the focused client. Qt5 on Wayland calls RegisterWindow
with QWindow.winId(), which is often 1 and never the compositor
surface id; the panel then matches the registrar entry by this pid.
0 when unknown (Lava clients, or a window with no client).
idl/lava.npidl:446
registrarId: u32
The key this window's menu is registered under on the AppMenu registrar.
Equal to surfaceId for Lava clients and native Wayland ones, which is
what they pass to RegisterWindow. X11 / Xwayland clients pass their
XID instead — a different number, in a namespace that can collide with
compositor surface ids — and looking the menu up under surfaceId is
how those menus never appeared. A panel that wants the window wants
surfaceId; only the registrar lookup wants this.
idl/lava.npidl:455
surfaceId: u32
0 when nothing is focused — the desktop, or the last window closing. Panels should read it as "show nothing" rather than "keep the last".
The compositor surface id, and the same number WindowInfo.surfaceId
carries. Menus are looked up under registrarId, which is not always
this.
idl/lava.npidl:430
title: string
What the window calls itself, so a panel showing a title does not need a second call to learn it.
idl/lava.npidl:433