Niri-IPC: introduce WindowAreaChanged

[aeghn]

Response to #624 .

I have observed that the author has recently been developing many fascinating features, such as floating windows, shadow effects, and tab indicators. I am deeply grateful for the author's diligent work in these areas. After personal experimentation, I found these features not only fascinating but also stable, without any performance degradation.

Compared to other features, this one is relatively minor, yet in the relevant discussions, I have not found anyone submitting a pull request here, so I decided to give it a try myself.

In general, I have introduced a new message type called WindowAreaChanged, which includes coordinates, dimensions, and whether it is a floating window.

When dealing with scrolling layouts, I found that it is not possible to use relative screen coordinates directly, as other window managers do. Therefore, I believe that floating windows and tiled windows should adopt two different coordinate systems(for x), hence the introduction of the is_floating configuration in WindowArea.

During the traversal of scrolling layouts, the system calculates the sum of xy coordinates, while floating windows directly use the method tiles_with_offsets.

The effect after using the niri msg -j event-stream command is as follows:

{"WindowAreaChanged":{"workspace_id":8,"window_id":65,"area":{"x":676,"y":-306,"w":947,"h":1022,"is_floating":true}}}

[YaLTeR]

Pinging @calops who was working on the same feature.

I'm not sure we wrote down the design anywhere, but my idea was to add new optional fields to Window for position within workspace (floating coordinates) and position within the scrolling layout (column index and index within column). This allows for adding more variants in the future (e.g. position within output for sticky windows) and allows setting multiple sets of coordinates (e.g. position within workspace for tiled windows too).

One important consideration is that positions and sizes should be reported for both the window (excluding borders) and for the tile (including borders).

[aeghn]

I have some confusion, do you mean reporting the window position and other attributes simultaneously in the IPC? Or only making this change within the internal structure?
I have tried to put these coordinates into the existing window messages, but in this case, when we move the floating window, a large number of position messages will be reported, at this time I think other window attributes are redundant, so should we only output these attributes when using the command niri msg windows, and output messages independently in the IPC?

[YaLTeR]

The events can stay. I'm saying that the data should be laid out a bit differently, and there should be more data.