elkowar / eww

ElKowars wacky widgets
https://elkowar.github.io/eww
MIT License
8.8k stars 364 forks source link

[FEATURE] eww instance ID #244

Open VuiMuich opened 2 years ago

VuiMuich commented 2 years ago

Description of the requested feature

Introduce simple ID for each running instance of eww and add subcommand eww instances to list all running instances.

This would help a lot when eww is run with a flag defined config path and when running multiple eww instances.

Proposed configuration syntax

Command example

> eww instances
ID   |   config path
0    |   [default] ~/.config/eww/
1    |   ~/.config/leftwm/themes/current/eww/
2    |   ~/Git-Repos/axarva-dotfiles/config/eww-1920/

Additionally a config option (defid <int>) might be helpful to purposefully set IDs explicitly for various config files so it is easier to access them in scripts.

Maybe access the instances with a flag like eww -i 1 windows or eww --id 2 logs

legendofmiracles commented 2 years ago

The command should not contain any visual noise like speration pipes, so that it's easier to script with

VuiMuich commented 2 years ago

Oh right, that's a good point. Also the flag could be used when launching a daemon in order to assign the id at this point: eww daemon -i 2 -c ~/.config/leftwm/themes/current/eww/ (dedicatedly used ID differing from the above output example).

elkowar commented 2 years ago

what would having an ID system add over sticking to just providing the configuration directory, and then still having an instances command to list all running instances? As I see it, having IDs doesn't add any information. The only real benefit I could see would be that you'd not need to fully type the config dir when using it from the CLI,.... In which case you probably only have a set number of configs, so you could also just set up an alias.

Having IDs would mean that eww would have two redundant ways of identifying a daemon, which I'm not necessarily a fan of.

Definitely do like the idea of eww instances as a command tho

VuiMuich commented 2 years ago

Indeed the idea sparked, when for testing purposes I started several different config (sometimes parallel, sometimes one after another) and I kept forgetting to add -c <path> when checking logs, state or opening/closing windows. So yes the main idea was kind of a qol feature with cli usage.

Another benefit might be that if calls like (button :onclick "eww -i 0 toggle some-window" "🔴") with a single instance running would work regardless the instance running from default or custom path. This could also be achieved if eww would default to the first instance running if sub commands are used without -c flag.

For the eww instances command a -v | --verbose flag might be nice, that lists additional fields like used sub commands e.g. logs, or process IDs (though this might be a bit redundant as well).

elkowar commented 2 years ago

For onclicks i'd argue a cleaner solution would be to alternatively allow setting the config path via an environment variable EWW_CONFIG_DIR, and setting that to the current config dir when executing commands from within the eww config (onclicks, scripts, etc).

Outside of interactive use while testing I see very little utility in having those IDs - and there i'd argue setting up an alias is probably cleaner. Having IDs that need to be looked up and provides a second identifier for instances is rather icky imo

VuiMuich commented 2 years ago

Ooh, an environment variable makes tons of sense here.

The more I think of possibilities to use eww instances in outside scripts, eg. awk-ing the path, the more I like it.