i3status-rust
i3status-rust copied to clipboard
greshake
Merge strings into single blocks
The blocks in the text output of i3status-rs do not match the rendered blocks one-to-one. Instead, the short form and full form labels are separate elements; blocks with multiple placeholder strings are also output as separate blocks. Is there a specific reason for this, other than simplicity? Would it be possible to merge the strings such that each block in the output is truly a single block on the status bar? Presumably the clickable icons would still have to be separate.
I could work on this myself, but I wanted to check in first to make sure I wouldn't be breaking any deliberate choices with this change.
Related: https://github.com/i3/i3/issues/4113. I'm working on an implementation for this feature but ran into a roadblock when testing with i3status-rs (I don't use the original i3status on this machine) and noticed this behavior. If each individual block has its own "use short form" state variable, then the blocks output by i3status-rs would need to have the long and short form text in the same block, as well as having all the text in the same block.
Presumably the clickable icons would still have to be separate.
Correct. Clickable elements are the reason why blocks are split. Since full-format and short-format may have different sets of clickable elements it is not clear how they can be merged, so full/short versions are also split. They could be merged in case they have the same structure, but that wouldn't solve the problem and would only increase complexity.
This is a workaround of i3bar's protocol limitations. If you can come up with a way to improve this while preserving current functionality, please share :)
While porting i3bar to another wm, I wanted to implement progressive short text and rounded corners, so I came up with this rules, which work with i3status-rust. I haven't looked into what other bar generators do, so I didn't propose this upstream.
Thanks for sharing; I think perhaps yours might be the approach to take, at least until someone comes up with an alternative (I couldn't think of anything yet). The original feature suggestion for i3 also included the idea of priority levels for the blocks, i.e. the blocks would be shortened in the order of their priority level.
The blocks can effectively be identified by their "shortening priority", so if i3bar shortens all blocks with the same priority, then it would work even with the current i3status-rs implementation. This isn't quite the same behavior as the suggested feature, since a config with no priority levels whatsoever would result in the current non-progressive shortening behavior, but this is easily addressed by sequentially assigning dummy priority values while the blocks are being loaded. (Although your approach makes more sense as a general implementation; this is just with minimal changes to achieve the desired feature.)
Custom shortening priority sounds good for customizability, but I'm not sure how practical it would be.
Another option would be to extend the protocol with "group id", not sure if something like this would be accepted upstream.
My current approach is to have a second list of pointers to blocks, sort them by priority, and then shorten in that order. By default, all blocks have the same priority. Then, all blocks of equal or higher priority are also shortened to ensure that all blocks pertaining to the same logical block are using the same length label (requires some more config, but it works for now).
See changes to i3 and i3status-rs (I worked off v0.32.0 due to compilations with the latest release, not sure what the issue is).
From the mentioned i3's issue:
This maybe could also be combined with a preference factor (of keeping full size) which can be given by the JSON api.
I would like to avoid expanding the protocol.
Maybe their opinion has changed, but it would probably be a good idea to ask again.
Also I'm not convinced that manually assigning preferences is a good UX. And protocol-level way of grouping blocks could be used for other features. Rounded corners are the first thing I can think of, but maybe there are more.