Async branch progress

[ammgws]

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	❌	deprecate
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	🔵	No smart_trim
net	🕒	no ip(6), bitrate and hide_(missing/inactive)
networkmanager	❌
notify	✔️
notmuch	✔️
nvidia_gpu	✔️	Not tested (at all)
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	✔️

Other issues that will be solved once async branch is merged:
#430
#557
#1015
#1024
#1038
#1127
#1262
#1304
#1314
#1318
#1334
#1371 (partially)
#1442

[ammgws]

@MaxVerevkin copied the table here to make things easier to track.

[ammgws]

Need to split format templates into widgets

Is this the only non-block specific thing left to implement?

[MaxVerevkin]

Need to split format templates into widgets

Is this the only non-block specific thing left to implement?

I think so. It's pretty easy to implement, but I already mentioned that this particular solution is probably not the best one - it doesn't allow for "short formats".

[ammgws]

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?

Originally posted by @GladOSkar in MaxVerevkin/swaystatus#4 (comment)

Doesn't it work out with the above suggestion?

[MaxVerevkin]

Consider a block with the following format:

[block.format]
full = "two buttons: $btn1 $btn2"
short = "one button: $btn1"

The full format expands into something like

[
    {"full_text": "two_buttons "},
    {"full_text": "<btn1 label> ", "instance": "btn1"},
    {"full_text": "<btn2 label>", "instance": "btn2"},
]

How should the short version integrate into this?

[GladOSkar]

Maybe i'm not seeing something but I don't see why

[
    {"full_text": "two buttons", "short_text": "one button"},
    {"full_text": "<btn1 label>", "short_text": "<btn1 label>", "instance": "btn1"},
    {"full_text": "<btn2 label>", "short_text": "",  "instance": "btn2"},
]

wouldn't work?

[MaxVerevkin]

Okay, bad example. How about

[block.format]
full = "two buttons: $btn1 $btn2"
short = " $btn2 $btn1" # buttons are swapped

[GladOSkar]

Yeah true there i'm stumped :D I would probably try to prohibit this in some way unless there's a good reason for it

[MaxVerevkin]

Well, telling users that both of their formats should contain buttons in the same order is kinda weird.

And BTW, when/if i3/i3#4113 is implemented, the whole idea of splitting stuff into widgets will be broken.

[GladOSkar]

Also true :(

[MaxVerevkin]

Actually, something like this might work 😆 (haven't tried it yet)

[block.format]
full = "two buttons: $btn1 $btn2"
short = "$btn2 $btn1" # buttons are swapped

[
    {"full_text": "two_buttons ", "short_text": ""},
    {"full_text": "<btn1 label> ", "short_text": "", "instance": "btn1"},
    {"full_text": "<btn2 label>", "short_text": "", "instance": "btn2"},
    {"short_text": "<btn2 label> ", "full_text": "", "instance": "btn2"},
    {"short_text": "<btn1 label>", "full_text": "", "instance": "btn1"},
]

[GladOSkar]

Oh no... As if a lot of all this wasn't already hacky enough -.-

[MaxVerevkin]

As if a lot of all this wasn't already hacky enough

There's more.

Setting full text to "" completely disables the block. Setting short text to "" disables the short text. But we can use "<span/>" (or something similar) instead and it works.

[MaxVerevkin]

b42df75. For now I've implemented only clickable placeholders, i.e buttons.

Now, configs like this are possible

[[block]]
block = "music"
[block.format]
full = "$title_artist.rot-str(20) $prev $play $next|"
short = "$title_artist.rot-str(15) $play|"

And BTW, when/if i3/i3#4113 is implemented, the whole idea of splitting stuff into widgets will be broken.

Actually, this (given that something like this will be accepted) can be easily fixed - i3bar/swaybar should group the blocks by their name and treat them as a single "block" while choosing whether to use short or full text.

[MaxVerevkin]

If anyone has an nvidia gpu, please test this block: https://greshake.github.io/i3status-rust/i3status_rs/blocks/nvidia_gpu/index.html.

[MaxVerevkin]

Music block: smart_trim isn't... implementable. Unless a new type "string pair" and a specialized formatter "rot-str-smart-trim" are introduced in the formatting system. Is it worth it?

[MaxVerevkin]

About the networkmanager block: is it really necessary to display multiple widgets at once? Perhaps an approach identical to the music block is sufficient?

Edit: never mind, apparently each connection can have multiple devices (which implies that a connection can have multiple access points, IDK if this is actually possible). I'm not sure what it means in practice, but this is impossible to implement using current formatting system unless I implement some sort of loops (#1304 (comment)).

[MaxVerevkin]

Actually, this (given that something like this will be accepted) can be easily fixed - i3bar/swaybar should group the blocks by their name and treat them as a single "block" while choosing whether to use short or full text.

I've implemented this in my port of i3bar and this seems like a good solution (no modifications needed in i3status-rs).

[MaxVerevkin]

Yet another async design

Startup time comparison with the same config

Master

old.mp4

That branch

new.mp4

[ammgws]

I can't find the post but I remember seeing you write that the second design would make it easier to port existing blocks. Do you think that's the way to go for now in order to switch master over to async ASAP?

[MaxVerevkin]

I can't find the post

#430 (comment)

Do you think that's the way to go for now in order to switch master over to async ASAP?

IDK :) Porting complex blocks (networkmanager / music / dbus in general) is still painful, and everything except networkmanager is already ported to "the first async".

[MaxVerevkin]

and everything except networkmanager is already ported to "the first async".

And just to clarify, networkmanager is over-complicated and I neither understand nor use all of it's features, so don't expect me to port it

[ammgws]

Yeah it's basically untouched from the time it was contributed. I'm in favour of dropping it for now since there's no one available to maintain it anyway.

[ammgws]

Closing this since async branch has been merged. Create separate issues if required.