[Feature Request] Add --config option to Zebar (or something similar)

[quadratech188]

Request

Curently, zebar only reads configs from %userprofile%/.glzr/zebar/config.yaml (for Windows), which can sometimes be a pain for people who store their configs somewhere else. A CLI option to specify a different config file would be a nice QOL feature.

Notes

It seems that read_config_file() in the Rust backend already has a override argument, but it isn't used anywhere in the Client API.

[edelvarden]

@quadratech188, you can use the mklink command in Windows to create a symbolic link that points to a different location for your configuration directory.

Step 1: Move Your Original Config Directory

First, move your original configuration directory .glzr to the preferred destination:

move %userprofile%\.glzr C:\<YOUR DESTINATION>

Replace <YOUR DESTINATION> with the path where you want to move the configuration directory.

Step 2: Create the Symbolic Link

Then create a symbolic link at the original location that points to the new location of the configuration directory. Run the following command:

mklink /D "%userprofile%\.glzr" "C:\<YOUR DESTINATION>"

Replace <YOUR DESTINATION> with the path where you moved the configuration file.

This will ensure that your configuration directory is relocated while maintaining the same path for applications that depend on it.

P.S. Other OS also support symbolic links.

[quadratech188]

I didn't think of that, thanks!

[quadratech188]

I started implementing --config anyway, and found this problem: Zebar only runs with 1 instance, and any further calls are forwarded to the instance that is currently running. So if I open bar C specified in A.yaml, and then open bar D specified in B.yaml I'm not sure what the intended behavior should be. Should the existing instance load both config files (Which would require a lot of restructuring), or should there be a separate instance for each config file?

[lars-berger]

I started implementing --config anyway, and found this problem: Zebar only runs with 1 instance, and any further calls are forwarded to the instance that is currently running. So if I open bar C specified in A.yaml, and then open bar D specified in B.yaml I'm not sure what the intended behavior should be. Should the existing instance load both config files (Which would require a lot of restructuring), or should there be a separate instance for each config file?

Yeah good question. Would you mind holding off on this for a lil bit? Started doing some experiments today that would affect this feature - currently looking into if it's possible to get rid of the start script and launch with a set of defaults on startup

[MoaidHathot]

Btw, I'm using another workaround. I use a PowerShell scripts to override Zebar's default configuration with my own. This also allows me to tinker with styling ZeBar very easily since I can just call Restart-Zebar in PowerShell and it will restart it and apply the changes without affecting GlazeWM. This PowerShell script is part of my PowerShell's profile, so it is available in every PS' instance and is easily added to dotfiles.

function Update-Zebar-Config
{
    $zebarConfigPath = "$env:Moaid_Config_Path/config/glazewm/zebar_config.yaml"
    $zebarDefaultConfigPath = "$env:USERPROFILE/.glzr/zebar/config.yaml"

    Copy-Item -Path $zebarConfigPath -Destination $zebarDefaultConfigPath -Force
}

function Restart-Zebar($overrideConfigs = $true)
{
    if ($overrideConfigs)
    {
        Update-Zebar-Config
    }

    Stop-Zebar
    Start-Zebar
}

function Start-Zebar
{
    $monitors = zebar monitors
    foreach ($monitor in $monitors) {
     Start-Process -WindowStyle Hidden -FilePath "zebar" -ArgumentList "open bar --args $monitor"
    };
}

function Stop-Zebar
{
    Get-Process | Where-Object { $_.ProcessName -eq "zebar" } | Foreach-Object { Stop-Process -id $_.id -Force }
}