Geometry as a percent of screen width

[GregorySchwartz]

Is it possible to implement the geometry as screen percents? For instance, having the width be 1/10 the screen width, centered at 5/10 of the screen width, at 1/10 the screen height, etc.? This would be helpful to have identical configurations across many different sized screens and DPIs.

[fwsmit]

This should definitely be possible. Do you have a suggestion for what the configuration syntax should look like?

This issue is blocked by #989, since you'll need to be sure what the display size is before using this feature.

[GregorySchwartz]

The relevant options impacted by this feature would be width, height, and offset. There are two ways to go about this I think. Basically, for each of these options, if the value is a (1) decimal or has a (2) percentile suffix, use relative values based on the screen size rather than number of pixels. Basically:

width = 100  # Pixels
width = 0.1  # 10% of screen width
width = 10%  # 10 % of screen width

I vote for (2), percentiles, as it is less ambiguous and opens the door for other units like cm so we can have literally a consistent size independent of screen or pixel size in the future.

[fwsmit]

I vote for (2), percentiles, as it is less ambiguous and opens the door for other units like cm so we can have literally a consistent size independent of screen or pixel size in the future.

Seems good. But the width syntax is a little more complex than that. You can select ranges of widths with:

width = (0, 200)

Where the left value should be smaller than the right value. Should we then allow:

width = (500, 50%) # When screen size is less than 1000, this will result in a maximum value smaller than the minimum.

There are a few ways to solve this:

• Give a runtime warning when this happens and fall back to either the smallest or the biggest value.
• Give a warning when mixing percentages and constants. We could then ignore the setting entirely or allow it anyways and do the above.

[GregorySchwartz]

Yes, I think you should allow mixing of units in the tuple, so I would do your second warning, allow it, and then fall back with a warning if the result makes no sense.

[ShadiestGoat]

Heya! Is there any progress/pr connected with this?

[fwsmit]

Not that I know of

[bynect]

I vote for (2), percentiles, as it is less ambiguous and opens the door for other units like cm so we can have literally a consistent size independent of screen or pixel size in the future.

Seems good. But the width syntax is a little more complex than that. You can select ranges of widths with:

width = (0, 200)

Where the left value should be smaller than the right value. Should we then allow:

width = (500, 50%) # When screen size is less than 1000, this will result in a maximum value smaller than the minimum.

There are a few ways to solve this:

• Give a runtime warning when this happens and fall back to either the smallest or the biggest value.
• Give a warning when mixing percentages and constants. We could then ignore the setting entirely or allow it anyways and do the above.

I would say that we can warn the user and make the min size equal to the max size if the latter is smaller.

This seems an easy task so I may do it