Configurable shrinking

[Arc676]

I'm submitting a…

[ ] Bug
[x] Feature Request
[ ] Documentation Request
[ ] Other (Please describe in detail)

The purpose of this issue is to track support for customizable block shrinking as described in #4113 (specifically this comment).

Current Behavior

The original behavior of i3bar is to use short mode either for all the blocks or none of the blocks. With #5818 merged, the blocks are now shortened progressively (based on the original feature description in #4113) such that the maximum number of blocks retain their full length while still ensuring that the bar length does not exceed its limit. However, the blocks are shortened in order and there is no option to force a certain block to retain its full length with greater priority than other blocks.

Desired Behavior

The user should be able to specify priority values for the blocks such that the blocks with the least important information (or whatever other heuristic the user desires) are shortened first, while the more "interesting" blocks retain their full length and only switch to short form if the bar is too long even after the "less interesting" blocks are shortened.

Impact

[ ] This feature requires new configuration
[x] This feature expands the i3 protocol

In the absence of any explicit configuration, i3bar would treat all blocks as having the same priority and thus shrink the blocks in order, as is the behavior already implemented in #5818. Therefore the feature does not require additional configuration in existing environments, per se, since users would be free to ignore this feature.

A prototype implementation of configurable shrinking is visible in the history of #5818 (removed before merging).

This feature expands the protocol by adding another optional data field to the JSON blocks. However, I believe the added complexity is not very significant and the additional flexibility provided to users would be an overall improvement.

[i3bot]

Please note that new features which require additional configuration will usually not be considered. We are happy with the feature set of i3 and want to focus in fixing bugs instead. We do accept feature requests, however, and will evaluate whether the added benefit (clearly) outweighs the complexity it adds to i3.

Keep in mind that i3 provides a powerful way to interact with it through its IPC interface: https://i3wm.org/docs/ipc.html.

[MaxVerevkin]

such that the maximum number of blocks retain their full length

treat all blocks as having the same priority and thus shrink the blocks in order

Shrinking blocks in order does not produce the maximum number of full-sized blocks. Maybe assign short_width - full_width to be the priority if none of the blocks have this property set?

[Arc676]

Good point, shrinking in order indeed doesn't give the absolute maximum number of full sized blocks, just the maximum number of consecutive blocks starting from the end of the list.

Using the width change as the default priority is a good idea too; that behavior would actually match my own use case quite well. I suppose this would also properly guarantee the absolute maximum number of full sized blocks.

I know that there is a tendency to avoid adding additional configuration to i3 at this point, but for completeness: this could also be configurable behavior. It was suggested in the original thread that some users might prefer the original "all or nothing" approach to shrinking, e.g. for vertical displays. The default methodology for inferred shrinking priority could also be configurable. But this would certainly introduce more complexity, which is maybe undesired for i3 at this stage.

[Arc676]

If additional configuration is undesired, the aforementioned length-based prioritization could also be made to be the only behavior, instead of the current "shrink in order" implementation. No user configuration would be required at all; this would simply be how i3bar behaves.

[orestisfl]

I think length-based prioritization can be chaotic as different blocks can change their length dynamically

[MaxVerevkin]

I think length-based prioritization can be chaotic as different blocks can change their length dynamically

As a user of a bar with "delta-length" prioritization implemented, I can say that it is not chaotic.

[orestisfl]

Maybe "chaotic" was an unfair word, unpredictable might be better. It's much simpler for a user to understand that their blocks get shrunk left-to-right rather than they having to guess at each moment which block has the biggest diff between full and short text. This is especially true if you have multiple blocks that display variable information such as song and window titles.

…

On Fri, 23 Feb 2024, 15:29 Max Verevkin, ***@***.***> wrote: I think length-based prioritization can be chaotic as different blocks can change their length dynamically As a user of a bar with "delta-length" prioritization implemented, I can say that it is not chaotic. — Reply to this email directly, view it on GitHub <#5887 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMCZPQWRM4QOXBWGMYR2PDYVCRVZAVCNFSM6AAAAABCOCORRSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRRGQZTKNJUGY> . You are receiving this because you commented.Message ID: ***@***.***>