i3status-rust compatibility

[MaxVerevkin]

Fully compatible	✔️
Not implemented	❌
Partially implemented	🕒
Complete but incompatible	🔵

Block	State	Notes
apt	✔️
backlight	✔️
battery	🕒	greshake/i3status-rust#1383 greshake/i3status-rust#1378
bluetooth	✔️	Use format flags instead of different format strings
cpu	✔️
custom	✔️
custom_dbus	🔵	The original protocol couldn't handle multiple blocks at once
disk_space	✔️
dnf	✔️
docker	✔️
external_ip	✔️
focused_window	🔵	More advanced formatting
github	✔️
hueshift	✔️	Docs are incomplete
ibus	❌
kdeconnect	🕒	Doesn't support old version
keyboard_layout	🕒	Everything except kbdd (unable to get it work on my machine), greshake/i3status-rust#1386
load	✔️
maildir	✔️
memory	✔️
music	🕒
net	🕒	no ip(6), bitrate and hide_(missing/inactive)
networkmanager	❌
notify	✔️
notmuch	✔️
nvidia_gpu	❌
pacman	✔️
pomodoro	🔵	Interactive configuration
rofication	✔️
sound	✔️
speedtest	✔️
taskwarrior	✔️	Experimentally use format flags instead of format, format_singular and format_everything_done
temperature	✔️
time	✔️
toggle	✔️
uptime	✔️
watson	✔️
weather	✔️
xrandr	✔️

[MaxVerevkin]

• pomodoro: add notify-send greshake/i3status-rust#1264
• battery: Add full_threshold option for setups that don't reach 100% greshake/i3status-rust#1261
• blocks: Add function to find default battery greshake/i3status-rust#1258

[farwayer]

About greshake/i3status-rust#1258 it is better to check device type is Battery from /sys/class/power_supply/*. On some notebooks battery device has another name (not BAT*)

[MaxVerevkin]

About greshake/i3status-rust#1258 it is better to check device type is Battery from /sys/class/power_supply/*. On some notebooks battery device has another name (not BAT*)

Yeah, that's a way better approach. (8439e50)

[ammgws]

@MaxVerevkin, @remi-dupre

Are there any specific issues with the remaining blocks that require solving before they can be ported?

Otherwise perhaps we can all get together and power through the remaining blocks so we can merge back upstream. After that I think we should ask to add @MaxVerevkin as co-maintainer.

[MaxVerevkin]

I don't think there are any technical issues with porting the rest of the blocks.

The constraining factor is (as always) free time.

In addition, I can't port some of the blocks simply because I can't test them. For example, I cannot port ibus, hueshift, xrandr because I don't use X11, apt because I don't use Debian-based distro and so on.

[ammgws]

What do the unchecked boxes mean under the "Compatible" section?

[MaxVerevkin]

They are ported but they lack some features and/or config options.

[MaxVerevkin]

Hi @GladOSkar, can you please check if the bluetooth block reports correct battery level (if you still have that device of course)?

[GladOSkar]

Yes, it works @MaxVerevkin. Took me a bit to realize you changed the default format to not have the battery info though ^^

[MaxVerevkin]

Well, after #11 everything is technically incompatible.

[ammgws]

That's fine since it was going to happen anyway.

[ammgws]

Was compatibility for the older version of KDEConnect dropped because it was too hard to implement?

[MaxVerevkin]

Was compatibility for the older version of KDEConnect dropped because it was too hard to implement?

In contrast to sound, no, I just didn't want to find and install outdated package. And by the way, which of the popular distros are affected?

[ammgws]

which of the popular distros are affected?

I remember mentioning it somewhere but the answer is almost always Debian/Ubuntu since we were looking at LTS releases.

By the way can you check your email? ;)

[ammgws]

Thanks for updating the table, very easy to grok the situation now :)

From a quick glance, apart from ibus and networkmanager, sound (pulse audio part), all the other blocks are trivial ones that just call external programs, right? It seems like we're so close to getting there now!

[ammgws]

If it's going to be a blocker then I wouldn't mind dropping ibus support. I don't even think anyone uses it apart from me, and now I've moved onto fcitx5...

external_ip incompatibilities are fine since it's never been in a release.

[ammgws]

What's missing from music?

[MaxVerevkin]

What's missing from music?

Some little things like filtering, on_collapsed_click, hide_when_empty, and I didn't have time to verify that new formatting covers all use cases.

NetworkManager is a double pain because of dbus -> zbus transition.

Also, NetworkManager and NvidiaGpu are the only two blocks that seem to use multiple widgets. The issue here is that because of the new formatting (I decided to implement rotating text in a more generic way, so that every block with a format option can benefit form it) blocks don't "own" widgets anymore, because blocks don't know anything about rotating text and that it needs to be scheduled. So all widgets (as well as formatting templates and hashmaps) are owned by the main thread. Some time ago I decided that "one block -> one widget + some buttons (widgets with only icons)" is good enough. Well, no, it's not.

[ammgws]

no ip(6), bitrate and hide_(missing/inactive)

Is that because it can't be done with netlink?

[ammgws]

Also, NetworkManager and NvidiaGpu are the only two blocks that seem to use multiple widgets.

Originally more blocks were using multiple widgets, but ended up being merged when adding format strings.
Each widget could have had its own format string but then you would probably want a way to specify widgets in a "master" format string as well...

Is rotating text the only thing stopping widgets returning to each block?

[MaxVerevkin]

Is that because it can't be done with netlink?

I'm sure everything can be done with netlink. neli has an example on how to fetch ips.

Is rotating text the only thing stopping widgets returning to each block?

Well, the whole (internal) API was already built around the idea of blocks not owning the widget but instead sending "commands" to the main thread to modify it. To support multiple fully-functional widgets the (internal) API must be changed. Or, there is an option to go back and let every block own the widgets and send their clones on updates, but the scheduling gets a bit tricky.

But I'll not drop generic rotating text support.

[MaxVerevkin]

Nvidia GPU

Migrating to format strings will eliminate the need to use multiple widgets.

Network Manager

As I understand, multiple widgets are being used in order to have multiple states (i.e. colors). It is possible to use one widget with multiple colors, but i3bar has issues with this (IDK if it was reported or not and whether it is considered as a bug). An easy "solution" would be to display only one connection per time. Not sure though if it's useful.

[ammgws]

Migrating to format strings will eliminate the need to use multiple widgets.

Doesn't that mean we lose per-widget click actions?

[MaxVerevkin]

Doesn't that mean we lose per-widget click actions?

It does...

But now that I look at greshake/i3status-rust@714b29f (split format string into multiple widgets) - it might actually be the way to go. Back then I removed it, because it required boilerplate in the blocks' code. Now widgets "own" format templates, so it should be much better.

It should work for both Nvidia and NetworkManager (and even Music - for buttons, so I can remove the "buttons API").

[MaxVerevkin]

Just one issue though: if we split format templates into widgets, there is no way to support "short" versions...

[GladOSkar]

Yeah that's difficult... We could at most collapse each widget to an empty i3 block, right?

[MaxVerevkin]

That will just collapse every block, since i3bar and swaybar haven't implemented progressive switching yet (i3/i3#4113).

[GladOSkar]

Well only if they have a short version set, right? So if widget A hasn't and widget B has a short text (set as icon only or empty) it should only show widget A in short mode, right?

[MaxVerevkin]

Ah, yes, we can have allow_hide option or something like that.