Leftwm: Comments requested: Leftwm-theme: Continue with up/down or use theme.toml?

[mautamu]

Howdy all,

I've been trying to build up the leftwm-theme theme manager and have been trying to figure out how to redefine theme.toml. Currently, a basic theme.toml might look like this:

border_width = 4
margin = [10, 10]
default_border_color = "#1E272B"
floating_border_color = "#1E272B"
focused_border_color = "#78824B"

The dev branch of leftwm/leftwm-theme attempts to add a way to remove the up and down files in favor of definitions in the theme.toml file. Is this something we want to carry forward with the leftwm-theme implementation? The theme.toml proposed in leftwm-theme dev is:

[global]
name = "mytheme"
dependencies = ["polybar", "dunst"]  # Used to check if required packages are installed in the system

# task.program_name.up sets up the program. The following section will spawn `polybar mybar`
[task.polybar.up]
args = ["mybar"]

# defaults to pkill program name if no down script is provided.
[task.polybar.down]
command = "killall"
args = ["-q", "polybar"]

# if program_name in task.program_name.{up,down} does not match any dependency listed, a command value must be provided.
# paths are relative to the current directory of theme.toml file.
[task.notification.up]
command = "/usr/bin/dunst"
args = ["--config", "configs/dunstrc"]

I think a few things need modified to maximize install power with respect to leftwm-theme as implemented in leftwm-theme b27762c0f7ccc30012909908741f2432c52bc03b :

border_width = 4 # define these up here for backwards compatibility with leftwm < 0.2.7
margin = [10, 10]
default_border_color = "#1E272B"
floating_border_color = "#1E272B"
focused_border_color = "#78824B"

[global]
name = "mytheme"
description = "A basic theme"
repository = "https://github.com/mautamu/theme"
commit = "*" # pin at a specific version as a "release"
version = "1.0.0"
leftwm_versions = ">2.6.7" # only install on compatible leftwms
dependencies = ["polybar", "dunst"]  # Used to check if required packages are installed in the system

# task.program_name.up sets up the program. The following section will spawn `polybar mybar`
[task.polybar.up]
args = ["mybar"]

# defaults to pkill program name if no down script is provided.
[task.polybar.down]
command = "killall"
args = ["-q", "polybar"]

# if program_name in task.program_name.{up,down} does not match any dependency listed, a command value must be provided.
# paths are relative to the current directory of theme.toml file.
[task.notification.up]
command = "/usr/bin/dunst"
args = ["--config", "configs/dunstrc"]

[task.polybar.install]
packages = {pacman = ["polybar"], apt =["polybar"], dnf = ["polybar"] }

Which direction do we want to go with?

[AethanFoot]

I think at a minimum you should be able to also define an up and down script (like there currently is) within this structure. E.g.

[task.script.up]
args = ["path_to_up"]

This would allow users to then still have more advanced control over the up and down, and increase compatibility with older themes that haven't been updated. The extra control is essential for me as the predefined up script didn't properly create the polybars on my monitors.
Is it possible to compress the tasks down so that you either define all the ups together or to define, for example, the polybar up and down under one heading. I say this as I can see the file becoming very long, especially compared to the current scripts (I also get this feeling in the config.toml where space is taken up by similar bindings, such as the movement keys).

[VuiMuich]

I like how this is kinda in line with the configuration style of polybar.
In that mind I think that an option to have the [task.bar.{up,down}] (maybe better to even generalize this task a bit more) call a customscript.

As a use-case I'd like to mention how I launched polybar, back in the day before I switched to leftwm. I was regularily switching between i3 and xmonad, but wanted to have the same look of my polybar. So I had a polybar.config with bars configured for both WMs and a small polybarlaunch.sh which checked $GDMSESSION and launched polybar with the mathing bar.
Not that I intend to use any other WM anymore, but someone might wan to :roll_eyes:

I also like the auto-install idea. Not sure how this was intended to behave, but I think this should launch a terminal for the install process (opposed to happen in the background), so it's clear to the user that something is getting installed and easier (install) error handling, right?

On a side-note: in this context I'd like to ask if it would be would be helpfull to have also a general up/down script outside the theme. For example some tray-utilities like udiskie or nm-applet that should start regardless the chosen theme. Or do you think this should be started ouside of leftwm's scope?

[AethanFoot]

On a side-note: in this context I'd like to ask if it would be would be helpfull to have also a general up/down script outside the theme. For example some tray-utilities like udiskie or nm-applet that should start regardless the chosen theme. Or do you think this should be started ouside of leftwm's scope?

I agree, I would think this could be implemented into the config.toml in a similar way. Maybe have a section for a list of apps like:

[task.applications.up]
args = ["dunst", "nm-applet"]

[VuiMuich]

I was thinking of the config.toml as well.
Though I'd keep the syntax more in line with mautamus proposition
[task.applications.up] command1 = ["dunst"] command2 = ["udiskie"] args2 = ["-t"]
Maybe have config.tom and theme.toml should even share all the syntax so they are basically interchangable.
So maybe the config gets overridden by the theme and provides fall back for things not set by the theme? (Or should the config override the theme?)

Edit:
On a second thought instead of command{1,2,...} a structure like this might be even more consistent and easier to parse:
```
[task.application.up]
command = ["dunst"]

[task.application.up]
command = ["udiskie"]
args = ["-t"]
```

[VuiMuich]

I like the proposal of your comment in issue 226.
Maybe it would useful if the parser could handle a file url as well as the (multi-)string.