Config simplification

[LBCrion]

Sfwbar configuration is beastly. Partly this comes from the feature set growing over time and config evolving to accommodate it, partly it's the price we're paying for flexibility.
I would like to explore ideas of making the config simpler without sacrificing the flexibility.

Ultimately, I think users who just want to use the bar and some default (or 3rd party) widgets, should be able to configure the bar without having to learn too much of the config language (i.e. include("widget") { option1 = x, option2 = y } level of complexity), with widget development involving more code.

I would love to hear what users see as pain points and what they see as a "nice" config format that can accommodate the features they need.

[LBCrion]

I think one of the basic design issues making config fiddly is the single namespace shared by every expression. With every variable shared by all expressions/files/widgets, pretty much every widget is a singleton. I.e. we can't have a clock widget that we add to the config twice with different timezones or different faces (as @01micko has shown recently!). With multiple namespaces, we could in theory have a clock widget that had a variable for a timezone and face that could be overridden from the main config, something like:

layout {
  include("clock.widget") {
    timezone = "America/New York"
    face = "simple"
  }
  include("clock.widget") {
    timezone = "Europe/London"
    face = "fancy"
  }
}

Another idea in a similar vein is user defined functions. Currently, any complex calculation is limited to a specific set of variables, i.e. if we have: Set VarC = Map($VarD, "1", "one", "2", "two", "3", "three", "more");, we can't apply the same transformation to VarA from VarB without duplicating the entire expression (easy enough with one line but messy if you have a dozen expressions linking to one another". Being able to define that Map function as a user define function MyMap would allow Set VarC = MyMap($VarD); Set VarA = MyMap($VarB)

[01micko]

This sound good! The clock project though did teach me quite a bit about timezones and now I've got that sorted, albeit a little messy.

[Consolatis]

Having include("whatever.widget") with the optional arguments sounds great.

I also think being able to define functions (at least in widgets) would help. Something like

function diff(x) {
    return x - x.pval;
}

And also some way to get rid of repetitive lines like

define MemUsedHuman = Pad(Str(MemUsed / 1024 / 1024, 2) + " GiB", 9)
define MemAvailHuman = Pad(Str(MemAvail / 1024 / 1024, 2) + " GiB", 9)
[..]

An old system-monitor.widget of mine

scanner {
        # Extract memory usage information
        file("/proc/meminfo") {
                MemTotal = RegEx("^MemTotal:[\t ]*([0-9]+)[\t ]")
                MemFree = RegEx("^MemFree:[\t ]*([0-9]+)[\t ]")
                MemCache = RegEx("^Cached:[\t ]*([0-9]+)[\t ]")
                MemBuff = Regex("^Buffers:[\t ]*([0-9]+)[\t ]")
                SwapTotal = RegEx("^SwapTotal:[\t ]*([0-9]+)[\t ]")
                SwapFree = RegEx("^SwapFree:[\t ]*([0-9]+)[\t ]")
        }

        # Add up CPU utilization stats across all CPUs
        file("/proc/stat") {
                CpuCountTotal = Regex("^cpu([0-9]+)", Last)
                CpuUserTotal = RegEx("^cpu [\t ]*([0-9]+)",Sum)
                CpuNiceTotal = RegEx("^cpu [\t ]*[0-9]+ ([0-9]+)",Sum)
                CpuSystemTotal = RegEx("^cpu [\t ]*[0-9]+ [0-9]+ ([0-9]+)",Sum)
                CpuIdleTotal = RegEx("^cpu [\t ]*[0-9]+ [0-9]+ [0-9]+ ([0-9]+)",Sum)
        }

        file("/proc/loadavg") {
                LoadAvg1Str = Regex("^([0-9.]+)", Last)
                LoadAvg5Str = Regex("^[0-9.]+[\t ]([0-9.]+)", Last)
                LoadAvg15Str = Regex("^[0-9.]+[\t ][0-9.]+[\t ]([0-9.]+)", Last)
        }
}

define CpuCount = (CpuCountTotal.count)
# TODO: these cry for figuring out how to use functions
define CpuUser = (CpuUserTotal - CpuUserTotal.pval)
define CpuNice = (CpuNiceTotal - CpuNiceTotal.pval)
define CpuSystem = (CpuSystemTotal - CpuSystemTotal.pval)
define CpuIdle = (CpuIdleTotal - CpuIdleTotal.pval)

define LoadAvg1 = Val(LoadAvg1Str)
define LoadAvg5 = Val(LoadAvg5Str)
define LoadAvg15 = Val(LoadAvg15Str)
define LoadAvgScale = If(LoadAvg1 > CpuCount, LoadAvg1, CpuCount)

define CpuTotal = (CpuUser + CpuNice + CpuSystem + CpuIdle)
define CpuUsage = ((CpuTotal - CpuIdle) / CpuTotal)
define SwapUsed = (SwapTotal - SwapFree)
# TODO: Does MemBuff really count as free-able?
define MemAvail = (MemFree + MemCache + MemBuff)
define MemUsed = (MemTotal - MemAvail)
define DiskUsed = (Disk("/", "total") - Disk("/", "avail"))

# TODO: these cry for figuring out how to use functions. also: is there some kind of format string?
define MemUsedHuman = Pad(Str(MemUsed / 1024 / 1024, 2) + " GiB", 9)
define MemAvailHuman = Pad(Str(MemAvail / 1024 / 1024, 2) + " GiB", 9)
define MemTotalHuman = Pad(Str(MemTotal / 1024 / 1024, 2) + " GiB", 9)
define SwapUsedHuman = Pad(Str(SwapUsed / 1024 / 1024, 2) + " GiB", 9)
define SwapFreeHuman = Pad(Str(SwapFree / 1024 / 1024, 2) + " GiB", 9)
define SwapTotalHuman = Pad(Str(SwapTotal / 1024 / 1024, 2) + " GiB", 9)
define DiskUsedHuman = Pad(Str(DiskUsed / 1024 / 1024 / 1024, 2) + " GiB", 11)
define DiskAvailHuman = Pad(Str(Disk("/", "avail") / 1024 / 1024 / 1024, 2) + " GiB", 11)
define DiskTotalHuman = Pad(Str(Disk("/", "total") / 1024 / 1024 / 1024, 2) + " GiB", 11)

layout {
        style = "monitorlayout"
        chart {
                style = "cpu"
                interval = 2000
                value = CpuUsage
                tooltip = "<tt><b>CPU</b>\n" + Str(CpuUsage * 100, 2) + "% All " + Str(CpuCount, 0) + " core usage</tt>"
        }
        chart {
                style = "memory"
                interval = 2000
                value = (MemUsed / MemTotal)
                tooltip = "<tt> <b>Memory</b>\n" + MemTotalHuman + " Total\n" + MemUsedHuman + " Used\n" + MemAvailHuman + " Available</tt>"
        }
        chart {
                style = "swap"
                interval = 2000
                value = (SwapUsed / SwapTotal)
                tooltip = "<tt><b> Swap</b>\n" + SwapTotalHuman + " Total\n" + SwapUsedHuman + " Used\n" + SwapFreeHuman + " Free</tt>"
        }
        chart {
               style = "disk"
               interval = 2000
               value = (Disk("/", "%used") / 100)
               tooltip = "<tt><b> Disk</b>\n" + DiskTotalHuman + " Total\n" + DiskUsedHuman + " Used\n" + DiskAvailHuman + " Available</tt>"
        }
        chart {
               style = "load"
               interval = 2000
               value = (LoadAvg1 / LoadAvgScale)
               tooltip = "<tt><b> Load</b>\n" + Pad(Str(LoadAvg1, 2), 5) + " Average  1 minute\n" + Pad(Str(LoadAvg5, 2), 5) + " Average  5 minutes\n" + Pad(Str(LoadAvg15, 2), 5) + " Average 15 minutes\n\nCurrent scale: " + Str(LoadAvgScale, 2) + "</tt>"
        }
}

#CSS

chart {
        background-color: black;
        color: yellow;
        min-width: 50px;
        min-height: 28px;
        margin: 0 1px;
        border: 1px inset rgba(128, 128, 128, 0.5);
}

chart#cpu {
        color: blue;
        color: #42b2b2;
}

chart#memory {
        color: green;
        color: #339933;
}

chart#swap {
        color: purple;
        color: #7f007f;
}

chart#disk {
        color: yellow;
        color: #505000;
}

chart#load {
        color: red;
        color: #990000;
}

Widgets might not be that relevant for casual users so them being more complicated actually sounds fine to me. It might be more relevant to look at the default configs to see where they can be reduced to as little as possible, either with sane(ish) defaults (that are then removed from the config) or potentially by splitting the CSS part out of them. One config could then include all defaults so users are able to quickly look up something while having an example they can modify rather than looking through the docs.

[LBCrion]

CSS can already be split from the config. By default sfwbar would read a .css file with the basename as the config. This can also be overridden with -c command line option.

[01micko]

Being able to use variables like Set = Some_Var in an Exec() would be nice (if possible). For now this doesn't work:

Set City = "New_York"

Exec("/bin/sh -c 'find /usr/share/zoneinfo/ -type f -name ' + $City + ' -exec tail -n1 {} \\;'") {
  TZ = Grab()
}

Works fine if I don't use a variable.

[01micko]

this works too Exec("find /usr/share/zoneinfo/ -type f -name New_York -exec tail -n1 {} \\;")

[LBCrion]

This is something on my radar. It's fiddly as it can result in nasty circular references, i.e.:

file("/proc/foo" + $VarX) {
VarA = ...
}
file("/proc/bar" + $VarY) {
VarB = ...
}

Set VarX = VarB + "x"
Set VarY = VarA + "y"

would result in recursive attempts to scan the two files. That said, we already have a mechanism to guard against the circular references in variables, we could build something similar for the scan sources.

[LBCrion]

I've made decent progress with a new expression parser that compiles expressions into bytecode and runs them in a simple vm. It should be reasonably easy to expand this to handle user functions, since the vm has a stack. It should also allow for abstracting widget options into local variables, i.e.

label {
value = $VarX
style = "mystyle"
}
widget("userwidget") {
someoption = True
otheroption = "Foo"
}

We can treat the {} as a block of local variable declarations for both the builtin and user defined widgets. The widget can then have an init function that would use these variables to customize the widget instance.

The tricky style question would be the variable dichotomy. Currently, variables in sfwbar hold an expression and their value is dynamically updated with the result of the expression. I.e. they behave more like cells in a spreadsheet than the typical variables.

If we introduce user defined functions with local variables, these local variables will need to behave more like traditional variables, i.e. their expressions only get evaluated as the function is executed. This make sense, since these variables by definition are transient and only exist while the function is being executed.
We may also need an explicit declaration of local variables, since the global variables can appear at any time (i.e. created via a piperead or config action).

Finally, if we do create more complex functions, it's probably worth merging the actions and the expression functions. Currently the two are separate with expression functions used to query the state of the world and actions attempting to influence this state, but user defined functions, may need to do both at the same time, so the distinction becomes somewhat moot.

[LBCrion]

@01micko, have a look at 311b6ac. This commit updates the calendar widget to a new config language.

[scruffidog]

First, I want to say this is probably one of the most responsive and useful projects that checks quite a few of my personal preferences. It is a deceptively significant amount of functionality and configurability from such a tight code base. With respect to the topic at hand, I believe the following:

Early *nix philosophy of just doing one thing, ie: separate out parameters/variables from visuals/presentation aspects and actions/trigger functions.

Override by order precedence, ie: the initialization process of the some components like systemd, gnome, xorg; regardless of my personal opinion of their bloat.

Define layout of where and how your configs are stored:
/usr/share/sfwbar/: defaults as the project/distro intends
/etc/{,conf.d}/sfwbar{,.d}/: defaults as host/environment/infrastructure deploys
~/.config/sfwbar/: user customization
/run/user/${UID}/sfwbar/ instance customization (probably won't work for non-systemd systems)

Lower levels overrides/augments the previous higher levels. You could also implement a non-override facility (like a key-word) in the scenario that a particular setting remains non-volatile, by permission. Obviously, security implications etc, etc...

For modularity sake: you can utilize the Arch libalpm/pacman approach: specific file extensions for defining things in paragraph 2, ie: [0-9]-.{conf, ini}, *.trig, *.func, *.css, *.widget, etc, etc. There's a certain amount of simpilicity in file handling logic. In keeping with this approach, you can tie foo.{conf,ini} to foo.trig, foo.func, foo.css, etc., so as to override/localize behavior/settings. This separation can allow the flexibility to just create links to modify some aspect of bar w/o that doing too much work. Again, security, etc, etc. Although if you do some fullscreen sized, crazy million item dashboard that monitors the health of spawned VMs....