Add an IPC mechanism

[Drakulix]

IPC clients should able to connect via a local socket of some sort. Confirmation about access should be granted by the user via UI.

TODO:

• [ ] Make sure this cannot be used to DDOS the user. (Probably achievable with a checkbox - something like "Dont show requests from this client anymore")
• [ ] Enable setting trusted clients in the configuration / make it possible to autostart them

Protocol will be JSON based.

TODO:

• [ ] Search for some good documentation software.
• [ ] Define what we want to expose:
  • [ ] Different protocols/scopes, all differenciate between reading and writing
    • [ ] Output API
      • [ ] Get/Set scale
      • [ ] Get/Set gamma control
      • [ ] Get/Set DPMS
      • [ ] Set mirroring (blocked by #10)
      • [ ] Pin workspace (blocked by #40)
      • [ ] enumerate windows (requires window scope)
      • [ ] Get workspace api (requires workspace scope)
  • [ ] Workspace API
    • [ ] get/switch workspace
    • [ ] enumerate windows (requires window scope)
    • [ ] get mode api (requires mode scope)
  • [ ] Mode API
    • [ ] Fullscreen:
      • [ ] get status/window (requires window scope)
      • [ ] set/unset window (requires window scope to get id)
    • [ ] Floating
      • [ ] get_windows (requires window scope)
      • [ ] get/set_window_position (requires window scope to get id)
      • [ ] get/set_window_geometry (requires window scope to get id)
      • [ ] get/set_window_stack (requires window scope)
      • [ ] maximize (requires window scope)
      • [ ] minimize (requires window scope)
    • [ ] Combined
      • [ ] get/set filters
      • [ ] move window (requires window scope to get id)
    • [ ] Switch
      • [ ] switch mode
    • [ ] BSP
      • [ ] Get/manipulate tree (this might be difficult to get right)
    • [ ] Window/View API
    • [ ] all_windows - make sure to provide all information available to configuration filters
    • [ ] focus/unfocus
    • [ ] close
    • [ ] Lockscreen
      • [ ] activate/deactivate (Ref #11)
    • [ ] Statusbar
      • TODO - Maybe support i3bar's protocol?
    • [ ] Config
      • [ ] get/set configuration parameters - requires #39 to be useful
      • [ ] reload - blocked by #39

[kerscher]

Perhaps you could consider using something like D-Bus, with Rust bindings?

Most (all?) of the plumbing is then taken care for you, and for things like notifications, menus and status bars there's already a big ecosystem.

AFAIK it also works on FreeBSD, if that's a concern.

[Timidger]

D-Bus is what Way Cooler uses, and I'd recommend using it in fireplace as well. There are certain tradeoffs that you have to make, but in general I think that a Wayland compositor is a good use case for D-Bus.

The only issue I ran into is that the Rust library is a little over engineered / unrustic.

[Drakulix]

This is absolutely a planned feature, but not until the rewrite to support smithay has happened.

Also yes there is a big ecosystem, but I also will try to provide fireplace with it's own ecosystem, while still being compatible to whats out there. Most existing tools are still build for X11 and I want to build a dock, bar, notification daemon, etc with full on wayland support for modern compositors without any legacy code.

Also once that happens @Timidger I am also very interested in supporting WayCooler with my tools. Even if we still want to build our own compositors and both of us have a different vision, I think the ecosystem can greatly benefit from having just more options.

[Timidger]

@Drakulix sounds good to me. Anything I build I want to be compatible with other compositors as well. Currently that isn't the case, but in the future I hope users can choose whatever applications they want to use for notifications, bars, etc regardless of the compositor used.

[voxadam]

9P is another option.