Is your feature request related to a problem? Please describe.

First time users of polybar might have difficulty in generating a config file that works for them, especially if they are not compiling it themselves. The implications of this is that polybar could lose possible users because they didn't want to perform the "extra" task of configuring polybar; either because they didn't have time, or because they just wanted to try it out and commit to personalizing the config later.

We briefly discussed this on #2016 (comment) and so I'm opening this issue to track this specific feature request.

Why does polybar need this feature?

To lower the friction for polybar adoption and make it easier for first timers to try it out. This would make polybar even with its competitors like i3status (which has a working default configuration).

Describe the solution you'd like

The issues related to having a generic configuration can be classified into two categories:

1. Depends on something being installed in the system, eg.: fonts
   This issue could be solved by compromising for some value that is generic enough, or that could be easily installed on the system, in such way that packagers could make this a dependency of the package, and that it could be written in polybar's userguide/readme for users wanting the default config.

2. Hardcoded values based on the hardware
   Somethings like battery name and network card IDs needs to be hardcoded into polybar's configuration.
   This could be addressed by an abstraction at the configuration level, having polybar perform the translation to a specific resource ID/name at runtime. I reckon this would be the biggest challenge in this FR.
   Another alternative would be to skip this info altogether on the default configuration, although this will probably degrade the user experience too much as crucial information could be missing from the bar.

Describe alternatives you've considered

To provide a script that autogenerates the configuration for the user without needing the install the build dependencies, such that it could be automatically run on the system when the user installs polybar's package (or on the first start).
This would also be a good solution, but I think the other one proposed is better as it would also simplify the configuration file in general.

Additional context

I understand what I'm asking here might not be doable due to the complexity of abstracting the configuration to that level, and so the alternative solution would be good enough.
I won't be able to submit a PR for this due to time constraints but I can try helping on the design of the solution if needed.

Thanks for working on polybar :)