Add hueshift block & updated list of blocks

[AkechiShiro]

• Scrolling up or down updates the screen temperature by a "step"
  amount (max_step 2000K).
• Supports either Xsct (X11 set screen color) or Redshift to change screen color temperature.
• Redshift is preferred as it as a much larger range of temperature
  color changes (between 1000K and 25_000K).
• Currently for testing purpose only redshift is supported.

I'm open to any feedback or suggestion.
I'm a fairly new to Rust and willing to learn if there is anything I can make a little nicer, just say so.
Also I've used u16 because the temperature of the color should never be negative nor go over 65535 since the highest limit I've seen is 25 000K that Redshift can set.

I'm also planning to add a MouseButton event later perhaps to toogle between different values instantly by clicking on the text.
But first I have to find out what's going on with the JSON error #801 I'm getting from i3bar.

[omertuc]

You forgot to update the documentation to include your block and its configuration options

[ammgws]

Does your output still look like this when scrolling?

{"version": 1, "click_events": true}
[[{"background":"#000000","color":"#a9a9a9","full_text":"| ","markup":"pango","separator":false,"separator_block_width":0},{"background":"#000000","color":"#93a1a1","full_text":" 6500 ","markup":"pango","name":"8e354b15488f46a9bbbf97e89ccd7574","separator":false,"separator_block_width":0}],
[{"background":"#000000","color":"#a9a9a9","full_text":"| ","markup":"pango","separator":false,"separator_block_width":0},{"background":"#000000","color":"#93a1a1","full_text":" 6500 ","markup":"pango","name":"8e354b15488f46a9bbbf97e89ccd7574","separator":false,"separator_block_width":0}],
5
[{"background":"#000000","color":"#a9a9a9","full_text":"| ","markup":"pango","separator":false,"separator_block_width":0},{"background":"#000000","color":"#93a1a1","full_text":" 6500 ","markup":"pango","name":"8e354b15488f46a9bbbf97e89ccd7574","separator":false,"separator_block_width":0}],
5
[{"background":"#000000","color":"#a9a9a9","full_text":"| ","markup":"pango","separator":false,"separator_block_width":0},{"background":"#000000","color":"#93a1a1","full_text":" 6500 ","markup":"pango","name":"8e354b15488f46a9bbbf97e89ccd7574","separator":false,"separator_block_width":0}],
5
[{"background":"#000000","color":"#a9a9a9","full_text":"| ","markup":"pango","separator":false,"separator_block_width":0},{"background":"#000000","color":"#93a1a1","full_text":" 6500 ","markup":"pango","name":"8e354b15488f46a9bbbf97e89ccd7574","separator":false,"separator_block_width":0}],
5
[{"background":"#000000","color":"#a9a9a9","full_text":"| ","markup":"pango","separator":false,"separator_block_width":0},{"background":"#000000","color":"#93a1a1","full_text":" 6500 ","markup":"pango","name":"8e354b15488f46a9bbbf97e89ccd7574","separator":false,"separator_block_width":0}],
[{"background":"#000000","color":"#a9a9a9","full_text":"| ","markup":"pango","separator":false,"separator_block_width":0},{"background":"#000000","color":"#93a1a1","full_text":" 6100 ","markup":"pango","name":"8e354b15488f46a9bbbf97e89ccd7574","separator":false,"separator_block_width":0}],

As a sanity check can you change your scroll commands to "echo test" and see what the output looks like?

[AkechiShiro]

Yeah it still does look like that when scrolling down.
I did what you told me, and here's is what I'm getting now, we're making a little bit of progress understanding a bit more the issue here, I guess.
It seems the 5 or the 4 are related to whether I scroll up or down.
The command I wrote inside the code is the following : echo test >/tmp/debugi3rs 2>&1

[{"background":"#000000","color":"#a9a9a9","full_text":"| ","markup":"pango","separator":false,"separator_block_width":0},{"background":"#000000","color":"#93a1a1","full_text":" 5700 ","markup":"pango","name":"90ac1a68fe8d44578291852aad88f6a9","separator":false,"separator_block_width":0}],
tail: /tmp/debugi3rs: file truncated
test
4

When I scroll up a 4 get printed, when I scroll down a 5 shows up, finally when I click onto the block a 1 shows up and the JSON error shows up as well.

[AkechiShiro]

I will also add that a 3 is printed when I right-click on it and a 2 is printed when I use the mouse3 button on it.
To me this seems like some kind of debug for the mouse events that is currently getting printed.

[AkechiShiro]

I've got even more interesting now, even without the new block the JSON error appears with the numbers as well in the debug.
I just need to scroll anywhere on the status bar.
This bug seems to happen (I'm running i3-gaps, and the status bar having this error is the bottom one, I have an upper one too on which scrolling works).
I've tested the hueshift block on the upper one and the same JSON error does not appear at all.
On the bottom status bar there is also the i3 workspace numbering 1 to 10 showing and if depending on the direction on which I'm scrolling I can switch to other workspaces.

So i3 seems to be somewhat interfering with the i3status-rs JSON output I suppose, how that is happening is a little beyond me to be honest but the link is that scrolling does two actions on the bottom status bar.

[ammgws]

What's the bare minimum config you can reproduce this with?

[AkechiShiro]

This is the bare minimum config I can reproduce this with :

[[block]]
block = "hueshift"

Or with any other config that doesn't have this block either, it happens even if I choose another block than the custom one I've made.
However this issue seems to be intermittent, right now when I scroll on the i3 bottom status bar, the JSON error does not get triggered anymore, this could be harder to reproduce since it doesn't seem to be related to the i3status-rs config file at all.

[ammgws]

OK I can reproduce the numbers in the output, however they are only logged to stderr so it shouldn't have an affect on i3/swaybar. When using tee command from before it was redirecting stderr to stdout which explains why it was causing those JSON errors.

I think the stderr output was added by accident in fe517af. I'm thinking about added a --debug flag since it has been mentioned before, but until then I'll just remove it for now.

[AkechiShiro]

I can confirm that without the debug the sliding works with no errors on the bottom status bar. Seems the redirection of the stderr in stdout was indeed the culprit.
Right now, there is just one more issue I'm having, it's that when I scroll the color temperature does change. But then when an update of the bar happens the screen goes back to the default color temperature (6500K) instead of the number that is shown updated in the bar.
Any idea why that is happening ?

[AkechiShiro]

The block is done and it's documentation is too, I did not test however changing the temperature when setting the hue_shifter to sct but with redshift the block seems to work as intended.

My issue came from a custom block I had made to change my color temperature every time the i3bar updated the command with the default 6500K would change back conflicting with the new hueshift block.
There are no more issue I believe, if any changes are required or any more documentation needed feel free to ask me and I'll make the required changes.
This PR I believe is now ready to be merged with master.
Thanks for all the help given here.

[omertuc]

Works great otherwise, thanks for this block, it's super useful for me!

[omertuc]

A bug I found while using it throughout the day: Seems like left click anywhere in the bar (for example, pausing/unpausing music) triggers the left click action on the hueshift block

[omertuc]

A bug I found while using it throughout the day: Seems like left click anywhere in the bar (for example, pausing/unpausing music) triggers the left click action on the hueshift block

Figured out what causes it, you need to add a check that the click event was on your block ID, like this:

[AkechiShiro]

Thanks for the help to fix the bug, I believe that the block is now fully ready, if you wish to test it some more and provide some feedback however I think there won't be any issues anymore.
I've also updated the doc describing the left click behavior and its config argument click_temp.
Maybe a neat upgrade would be to manage some kind of state, and when the left_click is pressed once the state switch and the click_temp value is set then if another left_click is triggered a reset to a default_temp happens, but currently it is possible to do this by doing a left click then a right click so I'm not too sure it's really necessary.

[ammgws]

LGTM and looks like you already have a happy user in @omertuc

I checked some other status bars and apart from geolocation/GPS (which I don't think should be handled by us), it looks like we are feature complete.
https://bumblebee-status.readthedocs.io/en/latest/modules.html?highlight=redshift#redshift
https://py3status.readthedocs.io/en/latest/modules.html#hueshift

Thanks!

[AkechiShiro]

Also, I'm thinking of opening another PR or continuing this one if possible?

To improve the hueshift block.

The current implementation does not work under Wayland (which I was going to transition to), even if i3status-rust works on Wayland.

Redshift has a specific package which works well under Wayland provided you use the -m wayland method.
Unfortunately, there is no easy way to distinguish the redshift that is patched to work with Wayland and the one that isn't (the one that isn't just spits an error when given the -m wayland option).

However, I'm thinking that to be broader, I should try to include more Wayland compatible hue shifting programs to the hueshift block such as gammastep.

[aloispichler]

Thanks for this widget. It recognizes the hue_shifter automatically (redshift, on my machine) and changes the temperature upon scrolling.
But the shifter does not autostart, and it does not change the temperature displayed, if it changes during the day. I would expect the displayed temperature to change at the beginning of the night (and day). Further, an icon is missing. Is it a problem on my side?

[MaxVerevkin]

and it does not change the temperature displayed, if it changes during the day

I might be wrong, but AFAIK there is no way to query current temperature from redshift. This is not a limitation of this block because it is able to monitor changes when wl_gammarelay(_rs) is used.

But the shifter does not autostart

Can you describe current behavior and expected behavior?

Further, an icon is missing

Covered in #1465

[naveg]

I might be wrong, but AFAIK there is no way to query current temperature from redshift.

I believe redshift -p does this.

I agree that it would be a good improvement for the block to display the current temperature, as set by redshift itself outside of the status bar.

[MaxVerevkin]

I believe redshift -p does this.

Good to know! I did some initial work in 34e2b45, PRs implementing temperature updates for concrete back-ends are welcome.