Support DPI-dependent units

[jonhoo]

Currently, properties such as width and height only support pixel values or percentages. However, this is pretty limiting for users who wish to use the same bar across different monitors. To give a specific use-case, I have three setups I switch between regularly:

• Bar is on a high-DPI (144) monitor with resolution 2560x1440
• Bar is on a regular-DPI (96) monitor with resolution 1920x1080
• Bar is on a rotated regular-DPI (96) monitor with resolution 1200x1920

Picking a single value for height here becomes really difficult: a pixel value will cause the bar to either be way too small when the DPI is high, or way too tall when the DPI is low, but a percentage value will cause the bar to be really strangely sized on the rotated monitor. Even if the monitor isn't rotated, different aspect ratios can cause a height of 3% to look very different (compare 1920x1080 and 1920x1200 for example).

It would be very useful to have a DPI-dependent unit for these properties to complement the existing two attributes. We can probably draw some inspiration from CSS length units here, and add a unit like em, which is scaled relative to the current font size, which in turn is affected by the DPI (or should be if it isn't already). Alternatively, we could go with in/mm, though this would break with CSS, in which 1in == 96px.

[patrick96]

This is definitely something I would want to do in the future (and the other as well probably). Right now just defining multiple bars for different monitors isn't too much of a hassle (it's not perfect though). We will try to come back to this at some point but right now we have our hands full.
I will leave this open though.

[jonhoo]

The issue with defining multiple bars is that I'd have to have my launcher script decide which bar to launch depending on the EDID (unique identifier) of the currently connected screen, or something among those lines. While it's true that this won't require all that much duplication in the config (every EDID config would just inherit from the main bar), it would add significant complexity to the launch process.

[tamirzb]

I'm not sure new units are necessary here, you can also convert the logical amount of pixels in the config file to the corresponding amount of physical pixels on the display (e.g. 2 pixels on a 96 DPI display would be 4 pixels on a 192 DPI display). This is what many programs already do (i3 for example) and polybar already does this with font sizes.

[patrick96]

I agree with @EmilyBjoerk when we support DPI dependent units, they will have to be specified explicitly.

I have written something over at #1651 about supporting px and pt units for spacing in labels and similar places which could be helpful in implementing support for pt units for width and height.