Don't error out on unknown values about i3blocks HOT 11 CLOSED

Hi @Airblader! I could have added a dynamic array of extra keys (I'm basically okay with dynamic allocation at load time, but not for runtime), I have to think a bit more about that (if it is worth it or not). About your fork, if it gets popular and have releases, I am willing to add support for extra i3-gaps-specific keys. In fact, someone already asked me to add this support for testing. See the gaps branch ;-)

from i3blocks.

In the meantime, I will warn on unknown values instead of erroring out.

from i3blocks.

Hi Vivien,

cool, thanks for your support! I really don't want to start my own releases on the fork, I simply keep it up to date with i3/i3, so the release cycle is "the same", though just more of a rolling release. I don't see a benefit in custom releases as I barely add any features to it :)

However, it's completely fine and acceptable that you don't want to "just add" it to your code base. Will the gaps branch be maintained? That'd be good enough for me; otherwise I'd just fork it myself and keep it up to date (the commit is small enough to make maintenance managable :) ).

In the meantime, I will warn on unknown values instead of erroring out.

Are you talking about the master branch? I could totally live with that, too – I don't care about warnings. However, would you pass these values on to i3bar?

from i3blocks.

Ideally I think we all would like to factorize as much as possible, instead of maintaining many code bases. So if I could make i3blocks generic enough to support your use cases, I'd be glad to implement that.

Accepting extra keys and returning them as is might be ok. My only concern is the type, for instance distinguishing a number (e.g. border) or a string (e.g. background). But I guess considering any extra keys to be "string or number" (as it is for e.g. min_width actually) is safe enough.

If you need an extra key to be a boolean, it's gonna be tricky. I will need to add something like a command line switch to specify new keys, e.g. i3blocks -k border -k background -k flag,bool. Not sure the latter is worth it, but it isn't unfeasable.

from i3blocks.

Ah, the types – I didn't think of that. It wouldn't be an issue if i3blocks were to quote strings:

keyA="string value"
keyB=42
keyC=true

But that would be a breaking change now – unless you parse it like that only for unknown keys, which in turn is somewhat inconsistent. Parsing it that way could be an opt-in via command line flag, though, for example; that way it wouldn't affect users who don't need it.

Specifying arguments on the command like is possible, too, of course. You'd have to find a good syntax for that, though, that allows specifying name and type. Maybe something like --int-key <key>, --string-key <key>, --bool-key <key>?

from i3blocks.

I like the idea behind your key{A,B,C} example, this looks robust. The only thing I don't like for that is the annoying quote escaping that this may involve. That's what ini format was used for the config, to keep it as simple as possible. I'll add support for extra "number OR string" keys, then we'll see which option is the best.

from i3blocks.

It would be good enough for me right now for sure :) It's also a compatible change, so there wouldn't be any issues with it.

Thanks for all your support by the way!

from i3blocks.

(Sorry, accidentally hit the wrong button)

from i3blocks.

The dynamic properties are finally implemented in i3blocks master. That was fast!
i3blocks knows what string keys are expected by i3bar (e.g. "full_text"). For these string keys, i3blocks will quote their values, unless they already are. For unknown keys, values are sent as is to i3bar if they already are valid JSON values (i.e. true, false, null, a number or an already quoted strings), otherwise the value gets quoted. See the relevant bits for details. We should cover most cases this way!

from i3blocks.

@vivien Awesome work, thanks! Are there any release plans yet?

from i3blocks.

Thank you! I'm passing through all issue, small stuffs to implement here and there and I have to write a good documentation before releasing. It's gonna be soon in all cases.

from i3blocks.