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

Feature request / Question: Threshold for making module invisible #934

Closed
maximbaz opened this issue Jun 8, 2017 · 12 comments
Closed

Feature request / Question: Threshold for making module invisible #934

maximbaz opened this issue Jun 8, 2017 · 12 comments

Comments

@maximbaz
Copy link
Contributor

maximbaz commented Jun 8, 2017

Some modules have thresholds array, that allows changing colors based on some value.

What I want is to have an additional threshold which I can use to hide the output entirely. I'll show you an example below, please tell me if this is already possible :)

I don't want to see the output of modules like diskdata or net_rate at all times. If I have enough free space on disk, I want to hide the diskdata output from my bar. But if I begin lacking space, I want this to appear on my bar and I want the indicator to use yellow or red color based on my thresholds.

Same goes for net_rate, now it has hide_if_zero, but I want to hide it if it's less than a certain value.

I would use it perhaps even for volume_status and battery_level, there's no need for me to be notified that I'm on my usual volume level and my battery is fully charged.

Basically, it's a request to unify things like hide_when_full and hide_when_zero with an extra thresholds value, that will work everywhere and is a bit more adjustable.

/cc @tobes, @lasers

@tobes
Copy link
Contributor

tobes commented Jun 8, 2017

Hmmm,

I like this idea. Currently it's not possible but it could be done if we had a way to specify a 'this color should be hidden'. One option would be to create a special color for this purpose. I think specifying None for a color just removes any color so we can't overload that. I'll look at the code in a bit more detail when I get a chance.

@maximbaz
Copy link
Contributor Author

maximbaz commented Aug 5, 2017

Out of curiosity, have you had a chance to look at this? I like the idea of adding some kind of COLOR_HIDDEN, sounds like the code change will not be big after all 🙂

@tobes
Copy link
Contributor

tobes commented Aug 6, 2017

I've been a bit busy so no not yet. I think the COLOR_HIDDEN may just be the easiest option.

@lasers
Copy link
Contributor

lasers commented Jan 10, 2018

You could try multiple ifs.... This works for me. 😊

order += 'volume_status'
volume_status {
    format = '[\?if=percentage>15 [\?if=percentage<90 '
    format += '[\?if=is_input 😮|♪]: {percentage}%]]'
}

@lasers
Copy link
Contributor

lasers commented Feb 21, 2019

@maximbaz You can try this. https://github.com/lasers/py3status/tree/fuckcolor.

Don't try it with volume_status because the color is hardcoded there.

fuckmodule {
    thresholds = [
        (0, "fuckcolor"),
        (5, "#FF0000"),
        (10, "#E2571E"),
        (20, "#FF7F00"),
        (30, "#FFFF00"),
        (40, "#00FF00"),
        (50, "#96BF33"),
        (60, "#0000FF"),
        (70, "#4B0082"),
        (80, "#8B00FF"),
        (90, "#FFFFFF"),
    ]
}

@lasers
Copy link
Contributor

lasers commented Feb 26, 2019

@maximbaz Have you tried this yet? I updated fuckcolor branch to use invisible.

@maximbaz
Copy link
Contributor Author

Just got to try it @lasers, works beautifully with diskdata and net_rate, if you make a PR, I'll definitely approve 👍

After that is merged, if you have time and energy we can re-use this bug for follow-up PRs to also deprecate things like hide_if_zero in net_rate.

@lasers
Copy link
Contributor

lasers commented Feb 26, 2019

My issue is that this is related to formatter and we have RFC 4.0 issue to drop py3status formatter in favor of f-string formatter. I can leave the branch here (confirmed working okay and approved too) waiting for others to tell us what we should do with this issue.

I have other working branch too shift+middleclick to solve the shift+middleclick rfc 4.0 if you want to try it out. It removes bunch of button_refresh configs too. I'm also waiting for others to chime in on this and other issues. Do we wait, proceed, or drop? Et cetera.

@maximbaz
Copy link
Contributor Author

Thresholds aren't formatter though, right? So even if implementation might change, thresholds themselves and thus all functionality will remain.

We've just talked with cyrinux and dreamed of all the possibilities that this "invisible" threshold brings, let's merge this 🙏


I'm not sure what shift+middleclick is, where was it mentioned? Ping me in that thread and I'll test and reply there, to keep things focused (I thought middle click by itself is supposed to be refresh, so what is shift+middleclick?).

@lasers
Copy link
Contributor

lasers commented Feb 26, 2019

I don't know. Making blocks disappear is part of the formatter. Then again, colorizing the blocks is done in the formatter too. To be anal, using invisible color does not make it invisible (i.e. the color should be a color and its length should still be same).

This just mark the block False and return right away instead of determining via \?if= and/or [{value}]. If we lose blocks due to new formatter, then maybe we lose this too.

Will we still have blocks or something like that in new formatter? I think we should see the new formatter first to understand this better which is maybe not going to happen anytime soon. Contributor No.1 is Contributor No.1 ;-).

@maximbaz
Copy link
Contributor Author

Good point about the naming, I'd rename invisible to hidden to be perfectly clear about the end goal. I'm 100% sure that we will not lose thresholds, how ever they are implemented behind the hood, formatter or not. But if you want @ultrabug's opinion, can you please submit a PR and blackstar it?

(@ultrabug offtopic, I have a semi-urgent question waiting for you on IRC in a private message)

@lasers
Copy link
Contributor

lasers commented Feb 28, 2019

Closed via #1726.

@lasers lasers closed this as completed Feb 28, 2019
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

3 participants