Hi, I'm the one Samuel talked to on the linked issue. I wanted to quickly chime in to give the viewpoint of the polybar team and explain our priorities on the sample config.
While I did express interest in auto-generating config files, this is not a priority right now (and it likely won't be for a while). I also don't see a good way to do this in the current codebase without duplicating a lot of logic around what options a module supports. So I encourage you not to go with option D. I think C is a good option to go for even in the long-term, but unfortunately it is also the one that will give you the most work, Samuel, because you need to create a generic config. I would do it for you, but unfortunately I really don't have the time right now. This still doesn't really solve the font issue, I would suggest either trying to create a config without using any fancy font icons and using ASCII characters only, this would almost guarantee that the bar displays correctly for everyone. Otherwise you're not getting around some icon or emoji font. I see that debian has a package named `fonts-font-awesome` that seems to be providing FontAwesome4 which is very popular and could well be used for such a config. I would also suggest using `ttf-unifont` which has a good coverage of the first two unicode planes. Another option would also be to not ship any config at all. If you need any help feel free to reach out. Regards, Patrick On 3/22/20 7:48 PM, Samuel Henrique wrote: > Hello Antoine, > > On Mon, 2 Mar 2020 at 20:13, Antoine Beaupré <anar...@debian.org> wrote: >> I tried the package available here: >> >> https://salsa.debian.org/debian/polybar >> >> It works well! One unfortunate problem I have found, however, is that it >> requires the siji font to work in its default configuration. That font >> is not available in Debian right now (#894413) but worse, even if it >> would be, it's a bitmap font which requires enabling those across the >> board (`rm /etc/fonts/conf.d/70-no-bitmaps.conf`) which, in turns, means >> that bitmap fonts *will* be used everywhere. > I briefly discussed with upstream about having a default config for > polybar in here: > https://github.com/polybar/polybar/issues/2016#issuecomment-589976084 > > And the summary is that there is no such thing as a default > configuration right now, > we are shipping an example config file that is not supposed to be used > by people as > it contains specifics from the machine used to build the package, this > also means that > the package is non-reproducible at this point. > > Upstream seems to be interested in having an option to autogenerate a > config file at > runtime if none is found, the user is currently supposed to either > have the file or generate > it using upstream: https://github.com/polybar/polybar#configuration > > You do raise a valid point, I agree that we should make the example > config as working out-of-the-box > as possible, > > There are multiple ways we can approach this issue: > > A) Patch the example file with some font that comes on Debian per default, > this > will not solve the reprobuild issue and the file will probably still > be broken for some > users, but at least is closer to a working one. > > B) Provide a config generator and mention it in the docs, can be > upstream's one, assuming > that it will not require the user to install the build-deps. Solves > the reprobuild issue as we > can ship a hardcoded non-working example. > > C) Provide a hardcoded generic example, it will have to omit some > functionality but > at least they can be commented out so the user might fill in with their specs. > > D) Wait for upstream to add a feature to auto generate the config when > none is found. > A new issue has to be created to track this, as the other one was more > about the config > location. It will also take an unknown amount of time until someone > works on that. > > I believe either B,C or D would properly solve the issue but I don't > mind doing A meanwhile. > In case you would like to have A, could you suggest a font that comes > preinstalled that > worked for you? I'm afraid we're gonna have to rely on some extra font > and add it to the > package's Recommends because the font has to have the needed symbols. > > I appreciate input/help towards any of those solutions. > >> Also note that I previously mentioned the problems with that font in >> this bug report... > I have missed that, thanks for the heads up. > > Regards, >
