Fix: bottom bar fontsize adaptations

[gzotti]

This should fix a few issues which have become more apparent around the now default-visible font selection and font size switches. A preliminary fix was attempted in #3014.

GUI help text did not follow font and font size changes.
A non-default font and font size may lead to a visible (1-pixel) peek of the sliding buttons. The bottom bar must be properly reconstructed whenever font/size change.

A few other little quirks as I find them.

Description

Fixes #3014 (issue)

Screenshots (if appropriate):

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• This change requires a documentation update

How Has This Been Tested?

Test Configuration:

• Operating system: Windows 11
• Graphics Card: Geforce

Checklist:

• My code follows the code style of this project.
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (header file)
• I have updated the respective chapter in the Stellarium User Guide
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching src/**/*.cpp:

• Are possibly unused includes removed?

This is an automatically generated QA checklist based on modified files.

[gzotti]

I had to change quite a bit in the bottom bar to allow even larger fonts. Also, the rescaling has to be called twice to catch all boundingbox updates. Now you can try mousewheeling the font setting in the config dialog and should hopefully always see text&buttons well arranged.

What I don't know is why bounding boxes returned previously were 1 pixel narrower than the actual tested&combined geometries. I also changed this.

I left a few dev parts commented out. These I will clean up before an eventual merge.

[10110111]

The FOV field is now too close to the FPS one, which makes it harder to parse. It used to be like

FOV 80.3°       29 FPS      date

But now it's more like

FOV 80.3° 30 FPS  date

The 80.3° 30 is hard to decypher compared to the way it used to be. Here're the screenshots: old, new.

[10110111]

Another problem is that, when frame rate becomes an integer, like 29 FPS instead of 29.3 FPS, the FOV field jumps a bit to the right. This used to look nicer when the fields had fixed positions.

Maybe the positions should be calculated not from the current text, but from the expected widest possible contents (e.g. 000.0 FPS), possibly with a max(largestExpectedWidth, currentWidth) to catch unusual contents.

[gzotti]

Ah yes, this used to be like that before, just with too narrow field width. The jumping is indeed bad.

[alex-w]

At least 2 digits after comma need for decimal FOV.

Important note: the format of FOV may be changed via config.ini file (gui/flag_fov_dms) - I hope you're checked it too (includes changes in date & time - gui/flag_time_jd)

[10110111]

The jumps are still present, though they are a bit smaller.

[gzotti]

May depend on your font settings. Can you please experiment: StelGuiItems.cpp, LL 1070-72.
The "MMM" are placeholders. Maybe we need more. However, at some point it is too much to be pretty with only few buttons.

[10110111]

OK, my experiments say that "3" is wider than "1", so when I have 34.2 FPS real-life value, it appears wider than the 12.3 placeholder, so this dominates the max(), while 34 FPS is narrower. This results in the jumps. I suggest that W or M be used instead of the digits, as these seem to be the widest characters in all fonts (recall the "m dash").

[gzotti]

OK, my experiments say that "3" is wider than "1", so when I have 34.2 FPS real-life value, it appears wider than the 12.3 placeholder, so this dominates the max(), while 34 FPS is narrower. This results in the jumps. I suggest that W or M be used instead of the digits, as these seem to be the widest characters in all fonts (recall the "m dash").

Ah yes, the 12.3 in the placeholder 'loses' against your 34.2. Will switch to 'M's (and yes, those are meant as m-dash...)

[gzotti]

@alex-w Do you know why the boundingrects for some GUI items are set on purpose to be 1 pixel smaller than their childrenRects? See e.g. BottomStelBar::boundingRect() const. I have fixed that in some places, but not in all (like CornerButtons::boundingRect() const)

[alex-w]

@alex-w Do you know why the boundingrects for some GUI items are set on purpose to be 1 pixel smaller than their childrenRects? See e.g. BottomStelBar::boundingRect() const. I have fixed that in some places, but not in all (like CornerButtons::boundingRect() const)

Sorry, no. But maybe @xalioth can explains why…

[github-actions]

Hello @gzotti!

Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[github-actions]

Hello @gzotti!

Please check the latest stable version of Stellarium:
https://github.com/Stellarium/stellarium/releases/latest