Make some landscape variables static, and properties of LandscapeMgr

[gzotti]

Description

PeakFinder can export a rich landscape gazetteer for Stellarium now (see #3574), and labels may overlap.
This branch is intended to bring tilted labels, and maybe some other improvements.

• movable label angle
• user-configurable polygon color
• rearrange GUI

It occurred to me that some variables should actually static and can be set as properties of LandscapeMgr. A few more are yet to be changed!

Fixes # (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
• Housekeeping

How Has This Been Tested?

Test Configuration:

• Operating system: Win 10/11
• Graphics Card: Geforce, but should not matter

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?

Files matching guide/**:

• Did you remember to update screenshots to match new updates?
• Did you remember to grammar check in changed part of documentation?

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

[github-actions]

Hello @gzotti!

Thank you for the suggested improvement.

[10110111]

If you want the variables to be shared between Landscapes, they'd better reside in LandscapeMgr, rather than be yet another static state.

[gzotti]

One of the two. Having them in Landscape spares us from using them as explicit arguments. We use a similar pattern in Nebula(Mgr) and Satellite(s). Apart from not needing to declare friend, is there any problem, performance or whatever-wise?

[10110111]

spares us from using them as explicit arguments

I expected them to be made properties or simply gettable data members, not be passed around as arguments.

Apart from not needing to declare friend, is there any problem, performance or whatever-wise?

Having such state static and belonging to Landscape seems architecturally wrong. We have a class that manages landscapes, yet we store landscapes-global state in static members of Landscape class.

[gzotti]

Either a Landscape can use its static (class) variable, or it must get a LandscapeMgr property from a Module it first has to grab (or has to keep as own variable). The LandscapeMgr IMO can have privileged (friend) access to the Landscape class, so I prefer this model. The Mgr class is between user/GUI and the managed objects, and it is the Mgr's properties which are synchronized in RemoteSync.

See the previous solution: LandscapeMgr sets current landscape's instance variables, and when switching landscapes, we have to take the variable value from the current landscape and place it in the next landscape's instance variable. I see no real benefit, just a chance to forget one on the next extension.

What I intend to change here?

• IMHO landscape label fontsize, color, angle (new) and polygon color are global properties (user preferences) of LandscapeMgr, applicable to all landscapes, so are best stored as static vars in the Landscape class.
• The polygon color used to be declared in the landscape.ini. Now it can be changed globally and interactively. The color from landscape.ini shall be ignored after this change.
• I may still want to add "draw polygon (if declared)/draw only polygon". --> Solved with allowing linewidth=0

[alex-w]

I didn’t test the feature yet, but some cosmetic changes are needed here to avoid surprises in the future.

[alex-w]

Please add the tooltip for the font size input box.

[gzotti]

Is there a way to use a current UI editor and not create the new syntax? I had to revert all the auto-updated Qt constant names, very annoying.

[alex-w]

Is there a way to use a current UI editor and not create the new syntax? I had to revert all the auto-updated Qt constant names, very annoying.

Sorry, no answer. Which version of QtCreator you are using?

[gzotti]

I updated about 2 weeks ago to Qt6.8 (the new LTS to which we could also update at least on Windows CI). (QtCreator 14.0.2.)

[alex-w]

(the new LTS to which we could also update at least on Windows CI)

not yet, appveyor hasn’t qt 6.8

[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