Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default formats wtf. #1563

Closed
tobes opened this issue Nov 2, 2018 · 7 comments
Closed

Default formats wtf. #1563

tobes opened this issue Nov 2, 2018 · 7 comments

Comments

@tobes
Copy link
Contributor

tobes commented Nov 2, 2018

IMHO default formats for modules should be super simple.

I do not think that \?... should be in any default formats. A default format should look something like 'lalala: {placeholder}' I think anything else is insane and we should probably just delete the whole module.

@maximbaz
Copy link
Contributor

maximbaz commented Nov 2, 2018

I can see benefits in using \? in the default formats, you'd probably want to be more specific 🙂

For example it's quite cool that sysdata module by default changes color based on the CPU load. Even though I did customize formats for most modules, it was helful that default formats are sophisticated and inspirational enough that I could just copy-paste them and adjust small bits. I even used the same approach to color diskdata module (which is not colorful by default), i.e. for it to turn yellow or red when I run out of disk space.

Using \?if is also quite helpful, for example it is of essence in yubikey module — if there is no yubikey activity, there is no need to display an urgent section at all.

But again, I'm customizing my formats for all modules I use anyway, so don't really mind what defaults we use, as simple as possible or as sophisticated as possible.

In my mind, what's important is to stay consistent (e.g. either add colors to diskdata, or remove them from sysdata), and have a good documentation for what's possible to achieve with formats. Right now default formats are the best source of both inspiration and documentation about what's even possible.

@lasers
Copy link
Contributor

lasers commented Nov 9, 2018

I think default formats should be something that make most sense to the modules.

And if we can, give them good default config with colors, simple if statements to hide zeroes, etc so users does not have to do that themselves. It is also easier to remove than to add colors (and formatting).

I don't think we should get rid of coin_market because of... format_coin = '{name} ${price_usd:.2f} [\?color=24h {percent_change_24h}%]'. This is a good default config. Many other modules could be like that too.

I honestly don't know how to respond to this one as we have many modules using them... If you can list specifically what you don't like, then we could try and address that. Is the issue more about the formatter than default configs?

I do not think that ?... should be in any default formats
... probably just delete the whole module.

  • do_not_disturb: new module from scratch -- NAK -- This replaces 2 modules.
  • systemd: new module from scratch -- NAK -- This replaces 2 PRs.
  • bunch of modules, et cetera, et cetera, et cetera -- All NAK.

@tobes
Copy link
Contributor Author

tobes commented Nov 9, 2018

I agree that we need some flexibility but I think we should have

a) Simple formats (if they are not then something is very wrong with py3status)

b) Try to have a more uniform default look. Currently some modules are monochrome and some are completely colour crazy.

@lasers
you completely lost me at the end

@lasers
Copy link
Contributor

lasers commented Nov 9, 2018

b) Try to have a more uniform default look. Currently some modules are monochrome and some are completely colour crazy.

That's what I have been doing with systemd, do_not_disturb, etc. I also applied it to nvidia_smi, loadavg, lm_sensors, redshift, xrandr_tweaks, etc. The theme is to use default "title/name", then colorized values. Sometimes we need secondary, so make that one darkgray.

I think to make this much better, we swap out titles with icons and require new icon dependency. I want to focus on fixing up all modules so colors are done via formatter instead of direct entry. There are too many modules not doing this. I don't want to worry about icons right now mainly because we need to figure out a good solution to enable them. Default should be titles either way.

you completely lost me at the end

Sorry, I meant those specific PRs does not agree with this issue because of new ? in the format as this would allow users not to have non-completely color crazy. Perfect example is systemd as it have \?if= (degraded color) there to behave same as old systemd.

@lasers
Copy link
Contributor

lasers commented Nov 10, 2018

@tobes What's your position on this?

2018-11-10

If we don't have ?, then updates looks stale. I could say the same for scratchpad, but not necessary because scratchpad have icon so it looks okay. When it comes to text such as "Scratchpad 0" then it looks poor.

It does not look poor for scratchpad, brightness, etc because they all have icons. We still need colorized values in some default modules... to paint information better. The users shouldn't have to do everything themselves. Alternatively, we could introduce allow_colors similar to allow_urgent.

Anyway, this is an issue for simplified systemd, new pomodoro, etc. Speaking of "basic set of features", do we want to add thresholds in scratchpad_* too even although there could be almost no customization from users? I guess we should?

The (consolidated) scratchpad screenshot above have darkgray 0. I'd put in Scratchpad 0 to make it more consistency with other modules, but I think that one is a really unpopular move to pull on the users. Icons are just useful and does not take much spaces. I think we seriously should find a way to introduce icons to the modules in the future, but what do we do with the ? issue here?

@tobes
Copy link
Contributor Author

tobes commented Nov 10, 2018

@tobes What's your position on this?

I'm not sure what you are getting at here. For me they are all possibly over colourful.

introduce icons to the modules in the future

The only way currently to do this is via fonts. I made a py3status font a year or two back that does this but I don't think it's really the correct solution.

For me I'd like us to be much more clever,. The thing is there are a huge number of things we can do I have branches that add all sorts of crazy features. Some of which I think we should look at. One is my themes branch. It basically allows us to create a load of different themes for modules that can easily be set. So we could then have monocrome, crazy coloured etc (simply select-able) and potentially work across all the modules. It would need some work.

The thing is you have to consider different needs, eg you appear to use multiple status bars on a large screen. Personally I have one on a small screen, for me minimal formats are great, also I do not want to be distracted by colours.

I still go back to my original point that we want things super simple. We need to work out what we want not how to do it. This is so important. Writing the code is generally the smallest part of the problem. Not writing code is in my opinion the best way to get good code (I am serious here).

@ultrabug
Copy link
Owner

Referencing #1582 here. If you feel we need this issue open still, please tell me why and how we can get this closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants