Change style

[jeff-cai]

Perhaps make sets of style changes to be included in default installation?

Ideas:

• Default (current setup)
• Legacy (emulates i3 appearance)
• User (if I want to make my own and not edit default)

[qdbp]

Currently, global styles (such as the default border, font colour as well as other i3bar json api options) are controlled by the chunk_kwargs argument, but this is not well documented and rather opaque.

For individual units, it depends on what you mean by style changes. If you mean, for instance, lowercase vs. uppercase and other in-text display choices, currently those are hardcoded. Adding multiple appearance settings of that nature to units would probably require adding a layer of styling abstraction for units, and I don't see a straightforward way of specifying, for instance, "each unit's output begins with a lowercase three or four letter word".

I feel for totally custom styles it's best to just let users edit the units themselves.

[jeff-cai]

I was thinking of style changes in the spirit of matplotlib style sheets or firefox themes. These can be used as templates for user custom styles. But yes, documentation of the borders, colours, would be nice.

I'm roughly following (what I believe to be) your preferred style formatting, but personally I would rather use the i3 default or my own which get overwritten by your future changes since style is global. If you implement style sheets I can start ricing without being overwritten (currently my only anti-motivation for using py3status)

[qdbp]

I do very much like the idea of separating style from raw output for the units, but no clear idea on how to do that presented itself to me. I propose it be done so:

• add a new core class, PY3DisplayStyle (py3ds for short)
• PY3Units provide an interface to read what numerical or boolean values they output
• PY3Units are instantiated with an instance of PY3DS, which reads the unit's api and raw output, formats it, and produces the unit's final output

It will be finnicky getting a single style, which amounts to a glorified format specification, to be able to produce sensible unit output across all units, when you consider the diversity of output units generate, and especially when click events come into play. However, I think an approach similar to the one outlined above might be a good start.

PY3DisplayStyle should handle only what text is displayed, as per-unit i3bar-level styles (like borders and backgrounds) are already supported (though not well documented) by py3unit.persistent_overrides

[qdbp]

4ea516d has split get_chunk into a read and format method, separating the printing of unit output from the actual output.

I believe this resolves this issue in a way in line with py3s philosophy. I have no intention of creating any sort of intermediate formatting language, beyond possibly some more helper functions like pangofy, to "configify" output formatting.

However, inheritance to override format (or handle_click, for that matter) for each default unit is nonetheless an unsatisfactory solution...