Expose the UNIX socket as public API

[MaxVerevkin]

First of all, thanks for this project! Finally there is a tool to change the temperature without flickering under wayland.

The README mentions that daemon and clients communicate via unix socket. It would be really nice if the API to communicate with this socket was public and documented, in which case status bars like i3status-rust could directly communicate with the daemon.

[jeremija]

Hi @MaxVerevkin, thanks for the feedback!

I only finished the socket implementation last night and it's a simple JSON protocol over the wire. I didn't even know there would be any interest in the inner workings of it, but now that I know that there is I'll try to make it more future proof and document it so other utilities could make use of it.

[jeremija]

I moved all the types to the types/ package and added a new section to the README.md

Let me know what you think.

Note that there were a few breaking changes on master:

The default socket path was changed to $XDG_RUNTIME_DIR/wl-gammarelay.sock

The JSON message schema was changed a bit, this shouldn't matter as long you upgrade to the latest version.

All of this shouldn't matter as long as you upgrade, but you might want to delete the $HOME/.wl-gammarelay* files.

[MaxVerevkin]

Thanks, -v flag makes it very easy to debug.

The daemon currently only only writes the temperature updates to the connection that made the request, but this might change in the future. For example, we might want to enable sending updates to all other connections so that applications that are interested can update the UI.

That will definitely be useful for something like a status bar.

[MaxVerevkin]

By the way, shouldn't the response temperature and brightness be numbers instead of text?

[jeremija]

I've found that in practice it's better to pass numbers as formatted strings, due to the differences in parsing libraries used by various programming languages.

Integers, floats and doubles are all formatted in the same way and the JSON spec deliberately leaves out any details about how numbers should be parsed.

Hence I decided to transfer numbers as strings so that we can ensure there's no uncontrollable data loss due to this implicit conversion by the various parsers. For more details see https://stackoverflow.com/a/38357877

[MaxVerevkin]

Oh, okay, didn't know this is a popular technique.

[MaxVerevkin]

Added support in the experimental branch of i3status-rust, works flawlessly so far :)

[jeremija]

That's awesome! Mind sharing the link to your branch? :)

Just curious, which bar are you using with i3status-rust? I used it under i3 with i3bar, but after switching to sway I didn't like swaybar because the notification are context menus aren't implemented yet.

[MaxVerevkin]

Mind sharing the link to your branch? :)

Sure: https://github.com/greshake/i3status-rust/tree/async (docs are not hosted yet, but can be generated with cargo doc)

which bar are you using with i3status-rust?

I'm using swaybar.

because the notification are context menus aren't implemented yet

I've never used i3bar, so I don't know what these are :) Can you please explain what I'm missing?

[jeremija]

Thanks for sharing!

I've never used i3bar, so I don't know what these are :) Can you please explain what I'm missing?

i3bar is the default bar in i3 window manager that works under X-server. sway and swaybar are re-implementations (or forks?) of i3 and i3bar that work under wayland. The context menus don't work under swaybar.

I use nm-applet and some other apps that close to tray/notification area and I need to be able to interact with them, so I guess I have to keep using waybar until this is implemented: swaywm/sway#3799