Support running multiple/different bar configurations about taffybar HOT 9 CLOSED

@kwshi This is already supported, through the more advanced bar configuration interface (BarConfigGetter on Context). I don't think that having multiple taffybar processes is a good approach anyway.

Basically the way you use it is by writing a taffybar io action that returns a List of BarConfigs. This interface is admittedly complex and perhaps somewhat difficult to use but it allows a lot of flexibility.

from taffybar.

On further inspection, if this were to be implemented, it would have to be slightly more complicated than simply passing a CLI argument to taffybar-- the bar executable itself needs to also know where to find its own source to recompile. So one would have to customize the default dyreTaffybar arguments, something like this:

import qualified Config.Dyre as Dyre
import System.Taffybar

dyreTaffybar :: TaffybarConfig -> IO ()
dyreTaffybarAlt = Dyre.wrapMain $ taffybarDyreParams { Dyre.projectName = "taffybar-alt" }

Another caveat to this is that Dyre seems to be designed with only single instances in mind-- this approach would require the two configurations to be located in different folders as well: one under $XDG_CONFIG_HOME/taffybar/taffybar.hs, the other at $XDG_CONFIG_HOME/taffybar-alt/taffybar-alt.hs. This isn't totally a dealbreaker, but it's not very ergonomic and also makes it harder to reuse helper code across the two configurations.

from taffybar.

Why not just use an environment variable to decide which configuration to use?

from taffybar.

Also @purefn 's suggestion would also work for something like what you want.

from taffybar.

However, taffybar hardcodes launching from $XDG_CONFIG_HOME/taffybar/taffybar.hs,

This is only true if you aren't use the project approach.

from taffybar.

Aha! I think I've figured out how to do it with the BarConfigGetter interface. Here's a rough sketch of how I did it:

-- bar unique ID (needed for passing into StrutConfig) -> monitor index -> configuration record
type BarDefinition = Data.Unique.Unique -> GHC.Int.Int32 -> BarConfig

bar1 :: BarDefinition
bar1 barId monitor =
  -- see <https://hackage.haskell.org/package/taffybar-3.3.0/docs/System-Taffybar-Context.html#t:BarConfig>
  defaultBarConfig
    { -- see <https://hackage.haskell.org/package/taffybar-3.3.0/docs/src/System.Taffybar.SimpleConfig.html#toStrutConfig>
      strutConfig = defaultStrutConfig { strutMonitor = Just monitor },
      startWidgets = [ {- stuff -} ],
      endWidgets = [ {- other stuff -} ],
      {- other overrides -}
    }

bar2 :: BarDefinition
bar2 = _ {- another definition -}

-- for displaying on all monitors, see <https://hackage.haskell.org/package/taffybar-3.3.0/docs/src/System.Taffybar.SimpleConfig.html#useAllMonitors>
getMonitors :: IO [GHC.Int.Int32]
getMonitors = do
  screen <- GI.Gdk.screenGetDefault
  monitorCount <-
    maybe (pure 0)
      (GI.Gdk.screenGetDisplay >=> GI.Gdk.displayGetNMonitors) screen
  pure [0 .. monitorCount - 1]

withIds :: BarDefinition -> [GHC.Int.Int32] -> IO [BarConfig
withIds defn = mapM (withId f)
  where
    withId f monitor = f <$> Data.Unique.newUnique <*> pure monitor

getBars :: IO [BarConfig]
getBars = do
  monitors <- getMonitors
  top <- withIds topBar monitors
  bottom <- withIds bottomBar monitors
  pure $ top <> bottom

main :: IO ()
main =
  dyreTaffybar $
    defaultTaffybarConfig
      { getBarConfigsParam = lift getBars }

By the way, I noticed that the existing SimpleConfig makes use of MVars to generate multiple bar instances, but I can't tell/understand why that's necessary/how that achieves anything really different from a List.map (which is why I've defined my example above using only list fmaps). My code above seems to work as expected for me; am I missing out on something/doing something wrong by not doing this with MVars?

Edit: on second thought, maybe it has something to do with hotplug/unplugging monitors, and updating bar instances on-the-fly? I'm not sure.

from taffybar.

on second thought, maybe it has something to do with hotplug/unplugging monitors, and updating bar instances on-the-fly? I'm not sure.

Yes exactly. This was perhaps a misguided attempt to allow you to avoid recreating bars by giving them a unique Id. This bar config getter is really only called on initialization and when the monitor configuration changes. For what you want to do it shouldn't matter too much.

from taffybar.

on second thought, maybe it has something to do with hotplug/unplugging monitors, and updating bar instances on-the-fly? I'm not sure.

Yes exactly. This was perhaps a misguided attempt to allow you to avoid recreating bars by giving them a unique Id. This bar config getter is really only called on initialization and when the monitor configuration changes. For what you want to do it shouldn't matter too much.

from taffybar.

Wonderful, thanks so much! I'll close this now.

from taffybar.