Grids: accurate ecliptic calendar marks

[gzotti]

Description

This is an alternative to #2216 with accurate Solar positions labelled above the ecliptic.

Fixes #2175 (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.

[Atque]

I see the dates don't move when changing timezone or even location. Is that intended?

[gzotti]

No, I am just adding such refinements. A problem is DST change. I had thought core->getUTCOffset(jd) would deliver that. No, it doesn't. But I will add signal connections to recreate partitions when timezone changes. Location does not change ticks.

[alex-w]

Maybe using roman numbers for months to avoid misunderstanding the dates (e.g. 20/II for February 20)?

[Atque]

Maybe using roman numbers for months to avoid misunderstanding the dates (e.g. 20/II for February 20)?

Or perhaps Jan, Feb, Mar etc, but only at the 1st each month?

[10110111]

Why does it show dates in format that alternates between DD.MM. and DD.? This looks confusing, and the alignment between these alternations is broken. Also the trailing dots don't make sense to me.

[gzotti]

I see 1/10/20 as "main" labels (which indicate which month the whole area belongs to) and 5/15/25 as "intermediate" labels of lower importance, therefore they are placed lower and have no month attached (avoiding some clutter). I could possibly align them to be in-line with the main row.

The trailing dots may be a reason for Localisation of dates. In my part of the world it is common to write dots to indicate ordinals e.g. in dates. It's mostly a matter of taste. For me slashes would be uncommon, usually indicating alternatives.

[10110111]

have no month attached (avoiding some clutter)

Since the user needs to understand the meaning of a figure from the context, it's not helpful to have half with the month, and another without. It's better to just reduce number of ticks when the clutter would be unavoidable.

The trailing dots may be a reason for Localisation of dates. In my part of the world it is common to write dots to indicate ordinals e.g. in dates.

Well, I have LC_NUMERIC=ru_RU.UTF-8 and LC_TIME=ru_RU.UTF-8. In ru locales it's not common (not even heard of unless one has studied German) to end the numbers with periods to indicate an ordinal. To me it just looks like a C++ way of spelling a double literal with integral value. To non-programmers in similar locales to me it would just look weird (especially after a Roman numeral).

[gzotti]

OK. I did not want to go as far as localizing or even user-customizing those labels as this breaks some of the fov thinning logic. Shall I use Roman numerals for the first of each month, and "Arab" numerals for the other days? This will obviously make users unhappy when they zoom in to see just a couple of days which will then have lost their clear indication of "10.V." etc. There are always compromises to take.

[10110111]

as far as localizing

Well, it would be best to localize, but OTOH, since we are abbreviating to fit into the space, each locale would require a special approach, so I don't think this PR is a good stage for this.

even user-customizing those labels

This is too much IMO.

Shall I use Roman numerals for the first of each month, and "Arab" numerals for the other days?

No, just make it consistent: a single format for each tick, and without the stray period. I might even agree to the period (though it would look weird to most users IMHO), but consistency is a must.
[0-31].[I-XII] seems to be quite unambiguous even for those who are used to mm.dd format for date. So just sticking to this Indo-Arabic + Roman mixture seems to be the best compromise that doesn't require localization or customization.

---

I have now used this line for some time, and it's incomprehensible at high zoom levels when it doesn't have any labels at all, except "Ecliptic of Date". Maybe some refinement could be made, e.g. adding time points in HH:MM format in such cases.

[gzotti]

I have now used this line for some time, and it's incomprehensible at high zoom levels when it doesn't have any labels at all, except "Ecliptic of Date". Maybe some refinement could be made, e.g. adding time points in HH:MM format in such cases.

Adding intermediate values to the lines is another issue. (#1793)

[gzotti]

While I somewhat disagree about showing the month on also the 5-ticks, I can live with them.

[github-actions]

Hello @gzotti!

The enhancement or feature has been merged into source code and you may test it via building Stellarium from source code or wait the weekly development snapshot...

[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