Introduce theming facilities

[unode]

Currently the calendar widget code assumes that fg and bg are available in notification_preset which may not be true if a custom table is passed by the user.

Example of failing code:

lain.widget.calendar({
    attach_to = { mytextclock },
    notification_preset = {
        fg = beautiful.fg_focus,
        font = beautiful.font_name .. " " .. beautiful.font_size,
    },
})

It fails complaining that bg is nil. Other widgets may also be affected if the default can be replaced a user provided table and assumptions are made.

Also as a side-note, is there any reason why beautiful isn't used for default values instead of hardcoding a specific font (Monospace 10 in this case)?

[lcpz]

fg and bg are evidently both necessary, and this precondition must be met by the user. Instead of bloating the widgets with failsafe checks, another line of user code sounded reasonable to me.

It doesn't for you?

Also as a side-note, is there any reason why beautiful isn't used for default values instead of hardcoding a specific font (Monospace 10 in this case)?

beautiful has been completely removed from the module in order for it to be loaded at any point in the process, even in beautiful itself. The reason is modularity.

As written in the wiki notes, a monospaced font is required for the notifications, and monospace is just the default monospaced font available in every distro or almost, AFAIK.

[unode]

I ran into the problem while simply setting fg. I wanted to keep the default bg. But there is no default if I pass another notification_preset.
I agree that extra failsafe checks are annoying but personally I consider them good practice and they reduce the burden on the user.

As for beautiful, I don't quite understand your argument. Isn't beautiful supposed to be the standard way of storing theme preferences in awesome? It's a bit cumbersome if I have to override defaults for every single widget, even if I already set most options on beautiful.
Again I don't quite understand your point but if you don't want to rely on beautiful internally would perhaps some internal theme'ing module be more suitable? I would rather define something like lain.theme settings and not have to do it per widget.

Assuming Monospace 10 is available is reasonable. Still, perhaps this should be added upstream.
I.e. beatiful.font_monospaced to be set to any monospaced font.

[lcpz]

I ran into the problem while simply setting fg. I wanted to keep the default bg. But there is no default if I pass another notification_preset.

So... what about you just write that bg again?

As for beautiful, I don't quite understand your argument. Isn't beautiful supposed to be the standard way of storing theme preferences in awesome?

From the user point of view, beautiful is just a table. To tell the truth, the whole beautiful independency thing started here, when it was asked me to do a proper modularization of my themes, so to make them more manageable and debuggable.

But it's not only that: I do believe it's a go that the module needs to be independent from stuff which is bounded to a loading order. For instance, vicious doesn't use beautiful too.

I would rather define something like lain.theme settings and not have to do it per widget.

The per widget settings needs to remain, because users might want to be specific, but having the possibility to set or fallback to a global lain.theme is a good idea. It will be very simple, and also could be a pointer to beautiful, so that we can have any possibility.

I never thought about it, but hey, this is what feedbacks are also for. 😃

I.e. beatiful.font_monospaced to be set to any monospaced font.

You can already define whatever you want in beautiful: like I said above, it's a table.

But being just a table means that how to use it is decided elsewhere.

[unode]

So... what about just write that bg again?

hehe, that's what I'm doing at the moment, just thought the function was lacking some safety measure :)

I would rather define something like lain.theme settings and not have to do it per widget.

The per widget settings needs to remain, because users might want to be specific, but having the possibility to set or fallback to a global lain.theme is a good idea. It will be very simple, and also could be a pointer to beautiful, so that we can have any possibility.

Yes that's what I meant. Keep everything as is but add the possibility of shared/global settings.
Glad you like the idea.

[lcpz]

This is a good implementation to use: https://github.com/paoloap/bosch#about-configlua

[lcpz]

Another thing which could fall under the theming bracket is naughty notification.

Some widget like fs and bat have notifications on by default.

If a user does not want them he/she has to set notify = "off" as argument.

It would be better to move them to a theming submodule and lighten the widgets code from redundancy.

[lcpz]

Threshold should be configurable too (i.e. #398).

[lcpz]

See also comment at line 62 here.