[High Prio] New Blocks about i3status-rust

[barraponto]

Just wanted to suggest an MPD block. I know we have mpris/mediaplayer2 support, but MPD itself doesn't support that protocol and I don't think upstream is going to fix it anytime soon. There are clients connecting MPD to MPRIS/DBUS (like [mpd-mpris][1]) but I'm sure we could do it as a block.

[greshake]

This would be my go-to approach: https://wiki.archlinux.org/index.php/lm_sensors

[BrendanBall]

It would be great if the Custom block, ie. Scriptable Block to execute shell commands can do more than just set the text of the output. I would really like to set the state as well. E.g my current use case is to show my current kubernetes context e.g. DEV or PROD. For DEV the state is info, and for PROD the state should be warning or critical. This is very dependent on each person's environment as they might want their own logic. Making the Custom block more powerful would be really awesome. I can open a separate issue if you're willing to discuss implementation details.

[svmnotn]

it seems to be working fine, i'll add a few config options and then submit a pr.

[shioju]

Hey I'm pretty new to rust and i3, but I'd like to help. Will take a look at your code first.

[greshake]

Sure, I'd love you to! If you have questions, just ask here.

[NullVoxPopuli]

This may help for temperature:

nvidia-smi --query-gpu=temperature.gpu --format=csv,noheader

not sure if there is a catchall for any gpu/driver, though.

[greshake]

That command is very specific and depends on nvidia-smi, I'd favor any approach to read the temperatures directly from the kernel, or using a program that is readily available and works for more components than a specific GPU.

[svmnotn]

On the network one, I just made a quick one using speedtest-cli that show ping, upload, and download. It still needs some work to make it nice and error free enough to use but that might be a thing. (I didn't know what else to use to measure all 3)
PS: it also uses a "nightly" feature (although it is stable in 1.18, 1.18 is the beta version sadly.)

• 1.18 just became stable 👍 👍 👍

[greshake]

@svmnotn Hey, what happened to the block you mentioned?

[svmnotn]

any thoughts on what that last block left should look like/do? or any off the top of the head knowledge about the needed docs to make it? Probably useful to put here ;)

[greshake]

So, I was imagining some block that displays current network connectivity (e.g. Ethernet/Wifi) and updates through dbus signaling instead of periodic updates... But I'm not sure I checked if NetworkManager actually provides those signals.

[etrombly]

looks like you'd probably want to monitor the active connection https://developer.gnome.org/NetworkManager/stable/gdbus-org.freedesktop.NetworkManager.Connection.Active.html

Nevermind, looks like that's to activate a connection. There's a state method that might be useful. I might play around with it later.

[etrombly]

Here's a quick example for how to get your ip address. Probably not going to work more on it unless nobody else takes it up.

extern crate dbus;

use dbus::{Connection, BusType, stdintf};

fn main() {
    // Connect to server and create a ConnPath. A ConnPath implements several interfaces,
    // in this case we'll use OrgFreedesktopDBusProperties, which allows us to call "get".
    let c = Connection::get_private(BusType::System).unwrap();
    let p = c.with_path("org.freedesktop.NetworkManager", "/org/freedesktop/NetworkManager", 5000);
    use stdintf::OrgFreedesktopDBusProperties;
    let connection = p.get("org.freedesktop.NetworkManager", "PrimaryConnection").unwrap();

    if let Some(x) = connection.0.as_str(){
        println!("{}", x);
        let p = c.with_path("org.freedesktop.NetworkManager", x, 5000);
        let settings = p.get("org.freedesktop.NetworkManager.Connection.Active", "Ip4Config").unwrap();
        if let Some(y) = settings.0.as_str(){
            let p = c.with_path("org.freedesktop.NetworkManager", y, 5000);
            let addrs = p.get("org.freedesktop.NetworkManager.IP4Config", "AddressData").unwrap();
            println!("{:?}", addrs);
        };
    };
}

if you get "org.freedesktop.NetworkManager.Connection.Active", "Type", that should give you whether it's wired or wireless.

There's also a statechanged signal you can connect to for the active connection. Should get the info without polling. The dbus library has a tokio interface, but I didn't look too much in to it. Not sure if the way you have the project set up would work with that anyway.

[matthiaskrgr]

Further ideas:
Display disk io (read /proc/diskstats and obtain diffs between block updates)
display cpu frequency (lscpu --json or /proc/cpuinfo)
display page cache size ( cat /proc/meminfo | grep Dirty ) (the amount of data the kernel intends to write to disk but hasn't yet)

[ammgws]

I'd also like to piggyback here: In a custom block, is there a way to monitor environment variables without polling? Something like how you can subscribe to DBus signal events, but for env vars.

[atheriel]

I think there's a limit to how powerful we can really make the custom block. In the cases like those proposed by @BrendanBall, the long-term answer is probably to allow users to write their own blocks in Rust.

[atheriel]

Or, alternatively, should we simply take a monolithic approach and accept a number of these highly specific blocks into the main repo? I don't think we have any implicit criteria for the scope of acceptable blocks in this project yet.

[BrendanBall]

@atheriel a limit to how powerful you want to make the custom block? You could implement an entire stream based bidirectional protocol where the custom command is a long running process like language servers. That way users could implement their plugins in whatever language they want. This sounds like over kill for i3status however so unless someone REALLY wants all that power it would probably never happen. I think it's really nice to have all the generic blocks in the repo written in rust, but forcing all your users to write their very custom blocks in rust isn't really nice IMHO.
I personally decided to try this project out because it has nice features e.g individual intervals per block, nice default blocks, theming, straight forward config. I am much more in favour of having a more extensible custom block so that users can implement highly specific blocks in their scripting language of choice. And currently I think the most important addition for the custom block is to at least be able to set the state.
This doesn't stop the builtin block ecosystem from growing to a big list of robust blocks. If the list grows really big you might want to think about a plugin ecosystem (I don't know if this is possible in rust) or at least have the blocks behind feature gates.

[greshake]

As the creator, let me share some of my initial intentions. After I started using bumblebee (python i3status replacement with very similar looks) I realized it was eating up ~10% of my CPU because it was updating all blocks every X seconds. So I decided to make a status bar that is as efficient as possible while retaining all the features (and, as it turns out, I managed to squeeze a lot more in). This was only possible by doing everything in Rust and reducing subprocesses, subshells, system calls and JSON string operations to a minimum (there is still room for optimization however). Introducing a programmable Block for small and simple use cases is fine IMHO and so I made the Custom Block. The idea is that users who have more specific wishes would implement a block in Rust and share the implementation, so we all would benefit. This yielded many cool blocks already. I don't see how a fully fledged programmable block in the style you guys suggested (bilateral JSON protocol communicating with a subprocess interpreter or shell) helps us to achieve a better "product" for all users in the long run.
Also, the list of blocks can grow indefinitely. The compile time scales linearly, and so does the binary size. Runtime performance is unaffected by unused blocks, but the program may use a few more KBs of RAM in the process, no big deal today. But we should probably start finding a better way of documenting them than a huge list

[BrendanBall]

@greshake sorry for confusing you. When I mentioned stream based bidirectional protocol I was merely challenging @atheriel saying there's a limit to how powerful we can really make the custom block. I don't want to create such a complex custom block. I don't think we'll ever need more than a unidirectional protocol. The PR I submitted only adds a json protocol for the sake of setting the state of the block, and this is probably all I'll ever need. I think being able to set the state is a common enough use case to warrant that for custom blocks.

[atheriel]

@BrendanBall I think you've misunderstood me. I think there are limits to the complexity of the custom block simply because of the development work required and the need to maintain at least some level of backwards compatibility -- I'm really not opposed to feature requests in principle!

And I take your point that you don't want to be writing blocks in Rust yourself, as a user. That's likely a realistic position for most consumers of this project -- so consider my enthusiasm for a plugin system dampened. But I think it's also clear that @greshake (and other contributors, such as myself) are supportive of adding plenty of blocks in-tree, and as a consequence of that we should be looking to answer questions like "can we modify the custom block so that it supports a feature that I need for workflow X" with "workflow X sounds like a nice idea, can we just make a new block for it?".

[greshake]

@BrendanBall I know you were intentionally describing an over-the-top solution, but my argument still stands. We explicitly do not want the custom block to be adaptable to any use case to promt users to share their missing features with us, so that either we can implement a native block for it or they do. That is in part (the other part being me having no time) why there is another PR pending for improving the custom block.

But I'll keep thinking about this, maybe I'll change my mind, since their has been considerable community pushback against this idea.

[greshake]

So how can we communicate with MPD?

[barraponto]

@greshake i was thinking of https://crates.io/crates/mpd

[hanckmann]

I would be very interested in having a block showing the status of Caps Lock and Num Lock.
I have been looking around and did not find a nice library to help with this (or I would try to make this a pull request).

[ammgws]

If you need one right now you could try using a custom block with a shell command parsing the output of xset -q.

[hanckmann]

Yes I know, but I am trying to do this using info on these pages:

• https://github.com/erlepereira/x11-rs/blob/40f3cc218e53e89f4b5093b16348de3b7103a8bd/src/xlib.rs
• https://github.com/compenguy/clickrs/blob/master/src/inputsource.rs

But I am not yet there due to a compile error (see my newest issue) and since I am very new to rust.

[atheriel]

@hanckmann Can you open a separate issue on the topic of a Caps/Numlock block? (I can give you some feedback there.) This issue is a bit stale and I'd like to close it.

To any future readers: this project is mature enough that we have a good basis for assessing new blocks and contributions, and large enough that block ideas deserve their own threads. So I ask that any discussion of new blocks take place in dedicated issues, or in a new issue if there is not a suitable one already.