Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make some landscape variables static, and properties of LandscapeMgr #3951

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

gzotti
Copy link
Member

@gzotti gzotti commented Oct 15, 2024

Description

PeakFinder can export a rich landscape gazetteer for Stellarium now, 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

- also movable label angle
- also user-configurable polygon color
- rearrange GUI
@gzotti gzotti added the enhancement Improve existing functionality label Oct 15, 2024
@gzotti gzotti self-assigned this Oct 15, 2024
Copy link

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.

Copy link

Hello @gzotti!

Thank you for the suggested improvement.

@10110111
Copy link
Contributor

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

@gzotti
Copy link
Member Author

gzotti commented Oct 15, 2024

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
Copy link
Contributor

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
Copy link
Member Author

gzotti commented Oct 15, 2024

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".
  • I am not sure whether polygonal landscape color should be user-settable or should remain in control of landscape authors. We already have the auto-colored polygonal/zero landscape for worldmap-clicked locations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improve existing functionality
Development

Successfully merging this pull request may close these issues.

2 participants