Implement new formatting mechanism

[MaxVerevkin]

An attempt to close #1108. Any thoughts on this PR are welcome.

Overview

The syntax for the formatting string placeholders is (the order doesn't matter, but the name must always be first)

​{<name>[:[0]<min width>][^<max width>][;<min prefix>][*<unit>][#<bar max value>]}

Examples of configs:

• format = "{signal_strength:2} {graph_down}{speed_down;K}{speed_up;1*Bi/s}"
• format = "{volume:03}"
• format = "{volume:5#110} {volume:03}" - demo

Examples of code (blocks' POV):

Temperature:

            let values = map!(
                "average" => Value::from_integer(avg).degrees(),
                "min" => Value::from_integer(min).degrees(),
                "max" => Value::from_integer(max).degrees()
            );

Speed test:

                let values = map!(
                    "ping" => Value::from_float(ping).seconds().icon(self.ping_icon.clone()),
                    "speed_down" => Value::from_float(down).bits_per_second().icon(self.down_icon.clone()),
                    "speed_up" => Value::from_float(up).bits_per_second().icon(self.up_icon.clone()),
                );

Sound:

        let values = map!(
            "volume" => Value::from_integer(volume as i64).percents(),
            "output_name" => Value::from_string(mapped_output_name)
        );

TODO

• Add more suffixes.
• Add suffixes for bytes/bits (Ki, Mi, Gi, Ti)
• Translate every block to a new formatting and remove render_static_str()
• disk_space: alert_absolute
• Allow users to override placeholders' icon with {var~icon} will not implement.
• Add ability to draw bars for every numeric placeholder.
• Add max_width for strings. Something like "{var.5}" will truncate the text to first 5 characters.
• Add proper error handling.
• Write genral documentation.
• Document changes in every block
• Add unit tests
• Extend Value to have colors (via pango) (not useful because i3 renders pango differently compared to sway)
• (A lot of) Testing.

[ammgws]

I don't understand the use case for var~icon. Any examples?

[MaxVerevkin]

I don't understand the use case for var~icon. Any examples?

Net block displays speed as <icon><speed><suffix><unit>. "Var~icon" gives ability to override the icon. But yeah, this is not very useful, and most likely I'll leave it.

[MaxVerevkin]

Also, an error will be shown if any icon was not found. I think it's better than unwrap_or_default()ing and makes more sense.

[MaxVerevkin]

Maybe instead of having per_core option in cpu block it is better to have multiple utilization and frequency placeholders? For example: format = "Average: {utilization} {frequency} 1: {utilization1} {frequency1} ...". This gives much more flexibility. Moreover, this is the only way I see how to implement new formatting for cpu block.

[ammgws]

Maybe instead of having per_core option in cpu block it is better to have multiple utilization and frequency placeholders? For example: format = "Average: {utilization} {frequency} 1: {utilization1} {frequency1} ...". This gives much more flexibility. Moreover, this is the only way I see how to implement new formatting for cpu block.

Sounds OK to me.

[MaxVerevkin]

Add ability to draw bars for every numeric placeholder.

Would something like this be OK: "{var:5~110}"? This will create a bar 5 characters long with minimum value of zero and maximum of 110. And I'm not sure if the minimum value should be configurable.

[ammgws]

So it would pad the string? I don't get why the minimum is 0 in that example.

Is this what you mean (replaced spaces with □ to make it easier to tell):

format = "{var:5~7}"
(min length of 5, max of 7)

var	output
""	"□□□□□" <-- pads to the left?
"x"	"□□□□x" <-- pads to the left?
"x□"	"□□□x□" <-- pads to the left?
"12345678"	"1234567" <-- trims from the right?

[ammgws]

Oh sorry I thought you were talking about strings because of your comment on the other PR. Didn't realise you were talking about the barchart.

fn format_vec_to_bar_graph(content: &[f64], min: Option<f64>, max: Option<f64>) -> String

I assume your min and max are referring to the ones used by our current function?

[MaxVerevkin]

@ammgws No, I meant this function

i3status-rust/src/util.rs

Lines 348 to 355 in 094cfdc

	}
	}
	pub fn format_percent_bar(percent: f32) -> String {
	let percent = percent.min(100.0);
	let percent = percent.max(0.0);
	(0..10)

As you can see, 0 and 100 are hard-coded.

[MaxVerevkin]

This feature would remove redundant placeholders like

i3status-rust/src/blocks/disk_space.rs

Lines 274 to 275 in 094cfdc

	let values = map!("{percentage}" => format!("{:.2}%", percentage),
	"{bar}" => format_percent_bar(percentage),

and give ability to draw bar for, lets say, sound block, as well as every other block.

[ammgws]

Oh wow I totally forgot that even existed. It's not even documented for the sound block.

Anyway, right now I can't think of any cases where configuring the min would be useful, so perhaps it may be OK to hardcode it at 0. One nit: the proposed syntax kinda looks like a number range due to the "~", so perhaps another char would be better. And maybe explicitly declare that it's a barchart to make it more obvious as well. "{var:bar:5:110}" or something.

[MaxVerevkin]

It's not even documented for the sound block.

Sound block doesn't have this feature.

One nit: the proposed syntax kinda looks like a number range due to the "~", so perhaps another char would be better. And maybe explicitly declare that it's a barchart to make it more obvious as well. "{var:bar:5:110}" or something.

The parsing I currently have doesn't work well (at all) with repeated "keys" (:, ;, *), so maybe "{var:5#100}"?

[ammgws]

Sound block doesn't have this feature.

src/blocks/sound.rs
40:use crate::util::{format_percent_bar, FormatTemplate};
856:                    format_percent_bar(volume as f32)
870:                format_percent_bar(volume as f32)

maybe "{var:5#100}"

Sure why not. We can overview the overall syntax for everything once it gets nearer to completion, and get some more feedback from other interested parties too.

[MaxVerevkin]

Ohhh, well, that's weird 😆

[ammgws]

Memory block also has a bunch of undocumented format key specifiers that output a percentage bar 😆

src/blocks/memory.rs
277:            "{MFpb}" => format_percent_bar(mem_free.percent(mem_total)),
282:            "{MUpb}" => format_percent_bar(mem_total_used.percent(mem_total)),
287:            "{Mupb}" => format_percent_bar(mem_used.percent(mem_total)),
292:            "{MApb}" => format_percent_bar(mem_avail.percent(mem_total)),
299:            "{SFpb}" => format_percent_bar(swap_free.percent(swap_total)),
304:            "{SUpb}" => format_percent_bar(swap_used.percent(swap_total)),
309:            "{Bpb}" => format_percent_bar(buffers.percent(mem_total)),
314:            "{Cpb}" => format_percent_bar(cached.percent(mem_total)));

[MaxVerevkin]

What's going on here? Looks like it's applying the engineering notation to the percentage (usage is around 0.03%)

An exception can should be made for percents.

[GladOSkar]

Ah yes the classic millipercent, also known as the centipermille :D

[MaxVerevkin]

Also i always thought for network speeds bits were the default unit instead of bytes?

No, bits are default only for speedtest.

[GladOSkar]

Also i always thought for network speeds bits were the default unit instead of bytes?

No, bits are default only for speedtest.

I meant in general use, not this software. But it doesn't really matter as long as both are possible

[ammgws]

is it even necessary?

It may be, since before it would have been displayed as "1.92Kb" and now it's "1.92Kb/s", and I imagine there are people who want to keep it short by removing the "/s" part. (Actually I am one of those people but I don't have it set to bits 😃 )

[ammgws]

Also i always thought for network speeds bits were the default unit instead of bytes?

Bits for network speed, but when actually downloading files to disk (browser, torrents, etc), if my memory is correct then it's almost always been bytes.

[GladOSkar]

Honestly same, but i don't really know how we could completely decouple the actual unit from the displayed unit unless we made the entire unit after the prefix customizable, which would then make it hard to semantically get the desired units (b vs B) from it (but it would probably be possible)

[MaxVerevkin]

A little TODO:

• Do not apply engineering notation for percents
• _b/s should mean "convert to bits per second but don't display it"

[GladOSkar]

Is there a way to do what @ammgws wanted? A way do discard the /s? I'm imagining something like:

"{down*B/s}" -> "1KB/s"
"{down*b/s}" -> "8Kb/s"
"{down*Bps}" -> "1KBps"
"{down*bps}" -> "8Kbps"
"{down*B}" -> "1KB"
"{down*b}" -> "8Kb"
"{down*_B}" -> "1K"
"{down*_b}" -> "8K"

i.e. matching the used unit by finding the substring b or B instead if matching the entire unit and then just appending the rest.

Or is that too difficult?

[MaxVerevkin]

"[units_overrides]" 😆?

[GladOSkar]

"[units_overrides]" laughing?

Oof 😆

[ammgws]

How about adding bits as a unit and then just allowing conversion between BitsPerSecond/BytesPerSecond and Bits/Bytes?

[MaxVerevkin]

How about adding bits as a unit and then just allowing conversion between BitsPerSecond/BytesPerSecond and Bits/Bytes?

It still would not give enough flexibility to, for example, switch between b/s and Bi/s, so I don't think it's a good idea.

If just hiding the unit with _unit doesn't work good enough either, then I suppose, [units_overrides] doesn't look that bad.

[ammgws]

Since we only have bits/bytes per second and not per minute/hour/etc then just remove them and have Bits and Bytes only. The "/s" part can be added in the format string. Especially since there are other ways people might want to write it, such as "Kbps" instead "Kb/s"

[MaxVerevkin]

Since we only have bits/bytes per second and not per minute/hour/etc then just remove them and have Bits and Bytes only. The "/s" part can be added in the format string. Especially since there are other ways people might want to write it, such as "Kbps" instead "Kb/s"

OK, at least it would look the same way it was before.

[MaxVerevkin]

By the way, would it be possible to use rustdoc to generate documentation? This would make it much easier to keep it up to date.

[ammgws]

If it makes things easier, I don't see why not. Something to look at in the future.

[ammgws]

OK I've done as much testing as I can.

Excellent work on this!

[GladOSkar]

Yeah honestly great work :) Thanks!