observing list DOES store RA/DEC despite deselecting the option while adding an object

[axd1967]

Expected Behaviour

Actual Behaviour

Describe or maybe attach a screenshot?

Steps to reproduce

1. create a new observing list
2. select an object
3. make sure that "also store; RA?DEC" is NOT set
4. add object
5. save the list
6. observe that RA/DEC ARE saved

IIRC this bug report has already been mentioned (created by be) but I cannot find it.

This component of Stellarium deserves the most attention from devs as well as debuggers.

System

• Stellarium version: 25.2

Logfile

If possible, attach the logfile log.txt from your user data directory. Look into the Guide for its location.

[gzotti]

There must have been a reason to store RA/Dec mentioned either in source code or in a comment from around 2022. If you don't need the data, do not check "load". Can you elaborate why storing a few characters is so bad? And no, other places still deserve more attention. And BTW, we don't have debuggers. The 2-3 people involved develop their own stuff, review contributions which rarely are maintained by contributors for more than a few weeks, and maintain others'. And they decide what to do.

[10110111]

This component of Stellarium deserves the most attention from devs

Who decided that this is the most important component? I don't think there's a project director who decides on this and allocates staff to work on the most important parts. Stellarium is still a free software project and is still developed by a handful of people who aren't paid to do this most of the time.

[axd1967]

This component of Stellarium deserves the most attention from devs

Who decided that this is the most important component?

Who said it was an important component? Nevertheless, it is a valuable component. But flawed. (That's what I mean with "it deserves much attention"... like a baby.))

I don't think there's a project director who decides on this and allocates staff to work on the most important parts. Stellarium is still a free software project and is still developed by a handful of people who aren't paid to do this most of the time.

I'm fully aware of this.

Long time ago I tried to argue that the premature release of this component should be reconsidered (even the original developer agreed on that).

See

• https://github.com/Stellarium/stellarium/pull/1826
• https://github.com/Stellarium/stellarium/pull/1826/commits/f84be7578f63098563b810f93ec2d4f137d9b419#r681619109
• https://github.com/Stellarium/stellarium/pull/1816)
• https://github.com/Stellarium/stellarium/compare/master...axd1967:contrib/review/1816/1?expand=1
• https://github.com/Stellarium/stellarium/compare/master...axd1967:contrib/review/1816/2?expand=1

[10110111]

That's what I mean with "it deserves much attention"... like a baby.

You said "deserves the most attention", which differs quite a bit from "deserves much attention".

In any case, any issue that hasn't been closed as Wontfix and has no assignee is open for any potential contributor, including you.

[axd1967]

Unfortunately, I will not be able to contribute in a significant way in the near future.

[axd1967]

There must have been a reason to store RA/Dec mentioned either in source code or in a comment from around 2022. If you don't need the data, do not check "load". Can you elaborate why storing a few characters is so bad? And no, other places still deserve more attention.

It's not a matter of a few characters. It's a bug: the location data should not be stored if the checkbox was clear. (One can indeed wonder why there is a need to not store the data anyway.) And even if it is stored (which is a bug), it should not be recalled for highlighting when the checkbox is clear.

Because this is the result currently:

These columns should be left empty if the location checkbox off.

Also, for highlighting: if the date and location checkboxes are off, the object's current position should be shown; in that case, it is important to not repeatedly highlight the same object.

Date checkbox	Location checkbox	highlight
off	off	current position
off	on	stored position
on	off	location at that date (probably the stored position?)
on	on	idem

To simplify the logic:

• highlight current position if both checkboxes are off
• otherwise, highlight position extracted from stored data

Please note also that "there must have been a reason" is a weak argument, as a use case might not have been thought through by the analyst/developer, and "that reason" might not exist at all.