Discussion: More flexible ~/.lifebarrc

[jens-na]

The configuration file of lifebar is not very flexible. To implement features like "multiple module lists for different screens" I think we need a more sophisticated configuration file.

I thought about something like that:

screen "VGA-1" {
  modules "bat0 ifone"
}

screen "LVDS-1" {
  modules "date time"
}

This would be the first step.

---

With this config style it should also be possible to have a more flexible configuration for the modules. This would be the second step.
Something like that:

module "date" {
  type "date"
  format "%A, %e %B %Y"
  keycolor "140,200,255,160"
  valuecolor "200,200,200,255"
}

module "fs0" {
  type "fs"
  directory "/mnt"
  keycolor "140,200,255,160"
  valuecolor "200,200,200,255"
}

module "fs1" {
  type "fs"
  directory "/home"
  keycolor "140,200,255,160"
  valuecolor "200,200,200,255"
}

What do you think of the idea or do you have another idea how to "design" the configratuon file?

[lynks--]

Yeah absolutely, I was hoping that my simple implementation of a key-value store would suffice, but I can see that more flexibility would be good. Perhaps there is a standard format/config library out there. XML would probably be overkill, but JSON might be ok. However we might just as easily be able to implement our own format and parser.

I was going to go with modules DVI-1 date time (so the first paramater after "modules" would be the output name as reported by i3, which are also echoed to stdout by lifebar), but I guess it's probably time to improve the config format.

The "instance" loop (between lines 693 and 1040 on the current master) is where the iteration over each screen happens, a simple string comparison against ins->output->name would allow us to apply the correct config values.

One other point; I wanted lifebar to report any problems to stdout, using the BAD_MSG definition, rather than failing silently (as it does right now if the modules config line is missing). Maybe we should take this opportunity to move the config stuff over to a config.c and implement something a little less brittle.

Anyway, I should be able to get back on with this in a week or so, lets make sure we add as much flexibilty to the config format as we will ever need, without making it difficult to parse, or worse, unreliable and buggy. Thanks for all the input and code :)

[jens-na]

Yeah absolutely, I was hoping that my simple implementation of a key-value store would suffice, but I can see that more flexibility would be good. Perhaps there is a standard format/config library out there. XML would probably be overkill, but JSON might be ok. However we might just as easily be able to implement our own format and parser.

json-c is very common if you want to parse JSON, I guess. But I think it's also ok to implement an own config style which suits lifebars needs.

Maybe we should take this opportunity to move the config stuff over to a config.c and implement something a little less brittle.

👍 to move config parsing to config.c

One other point; I wanted lifebar to report any problems to stdout, using the BAD_MSG definition, rather than failing silently (as it does right now if the modules config line is missing).

I thought about setting default values to conf->modules in the first place but what if somebody only wants to render the - pretty awesome - workspace icons and doesn't want to have any modules? Removing modules from ~/.lifebarrc would be the way to go.
But if it's not ok for you I am OK to change it! 😄