socket2: add {,de}populateworkspace{,v2} events

[aytizren]

Describe your PR, what does it fix/add?

This PR adds 4 events to the events socket: populateworkspace, populateworkspacev2, depopulateworkspace, and depopulateworkspacev2. The former pair is emitted when an empty workspace gains a window, while the latter pair is emitted when a workspace no longer has any windows.

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

I tested it with this:

Rust code

use std::{
  env::var,
  error::Error,
  io::{BufRead, BufReader},
  os::unix::net::UnixStream,
  path::PathBuf,
  process::Command,
};

type Res = Result<(), Box<dyn Error>>; 

fn main() -> Res {
  let path: PathBuf = [
    var("XDG_RUNTIME_DIR")?,
    "hypr".into(),
    var("HYPRLAND_INSTANCE_SIGNATURE")?,
    ".socket2.sock".into()
  ].iter().collect();
  let stream = UnixStream::connect(path)?;
  let mut lines = BufReader::new(stream).lines();


  while let Some(Ok(msg)) = lines.next() {
    let msg: Vec<_> = msg.split(">>").collect();

    match (msg[0], msg[1]) {
      ("depopulateworkspace", name) => notify(name, false)?,
      ("populateworkspace",   name) => notify(name, true)?,
      _ => (),
    }
  }
  Ok(())
}

fn notify(ws: &str, populated: bool) -> Res {
  let prefix = if populated {""} else {"de"};
  let _ = Command::new("hyprctl")
    .args(["notify", "6", "10000", "0", &format!("Workspace {ws} has been {prefix}populated")])
    .spawn()?;

  Ok(())
}

Demonstration video
A red circle in the the workspace indicator window at the top(which is separate) means that a workspace is populated, while grey means that it is not.

The only issue that I have seen(from my limited testing) is that, sometimes, events are not emitted in the correct order when you use the movetoworkspace dispatch, as can be see from second 29 until the end. I'm not sure why that happens.
EDIT: That only seems to happen from the notification side of things in the script I sent. Simply printing each time an event occurs seems to reliably preserve the order of events.

Is it ready for merging, or does it need work?

I think that it is ready for merging if that issue is not a dealbreaker.

[vaxerski]

why? You can already do this with existing infra.

[aytizren]

When making bars/shells with special indicators for empty and populated workspaces, it looks like people currently make calls to the request socket whenever the response of hyprctl clients changes(e.g. epik-shell and noctalia). The Using hyprctl page of the wiki that said that spamming the request socket may cause compositor slowdowns. It's also simpler to watch for a single event and update a single workspace by id than it is to watch for ("movewindow" | "closewindow") and make a few checks and also watch for openwindow and do the same.
If you think this PR is redundant, feel free to close it.

[vaxerski]

ok, I see. v2 is redundant though, v2 was because v1 sucked of a few events. Make one event.