warn for multiple running instances

[axd1967]

Is your feature request related to a problem? Please describe. I have this recurring issue that from time to time I (usually accidentally, in various desktops/activities) launch multiple instances of Stellarium (Linux, custom keyboard shortcut), and I'm never sure how these instances interact with each other. Usually this is because I don't remember if Stellarium is already running somewhere.

Maybe this is not necessary - but I don't think it is a good idea to tweak settings via different instances, let alone have the app update some JSON files in parallel...

Describe the solution you'd like Possible options:

• add a warning dialog when an instance is already running - optionally before (and include a go/no go option) or after launching Stellarium
• introduce a user setting that prevents launching Stellarium more than once

Maybe a lockfile in user-directory should be introduced?

This should be a low prio and not to complicated issue.

Describe alternatives you've considered Once launched, put Stellarium in windows mode (F11) and check the title bar - that might show the number of instances:

Additional context Add any other context or screenshots about the feature request here.

[gzotti]

I sometimes start several instances deliberately to compare changes. The last to close writes the config.ini, otherwise parallel instances should be rather harmless. Just be more careful which apps are running.

[alex-w]

I sometimes start couple instances to compare changes too...

[axd1967]

I also suspect that the last instance will "win". but I'm not convinced that the final state will be valid.

e.g. state changes happen in e.g. tle*.txt , ssystem_minor.ini, recentObjectSearches.json or especially config.ini. some of those files (especially the last one) are vital for Stellarium, and are dynamically/often updated.

maybe there is no danger of ending up in an inconsistent state, but one guaranteed danger is that the user might not be aware that changes made in one instance will be overwritten by the "last" instance.

and if config.ini is shared between these instances, I bet that this will give issues.

so as a minimum, so kind of warning should be provided to the user (eg a confirmation dialog can ask if the user wants to proceed - with caution - when launching more instances).

but if you state that nothing can possibly go wrong, everybody is happy :-)

[axd1967]

I sometimes start couple instances to compare changes too...

(I do this with separate instances that run with separate user directories.)

[gzotti]

config.ini is written only if you ask for it in the settings dialog. Downloading satellite ephemeris or other extra data by two instances even at the same time should still result in one valid data file stored. Even if you change things like gridline colors (which are stored immediately), not too much breaks if the other instance overwrites a color setting. I cannot say whether downloading an extra star catalog with one instance, close that and then close the instance which is not aware of the download will lead to the download not being recognized at next startup. There are worse problems in expensive payware...

Of course, running e.g. 0.20.* and 0.12.* in parallel with the same user data directory may lead to some things breaking. Most config.ini keys are still compatible, though. But honestly, the handful of users in the world who are doing this should know what they are doing and should clearly call the highly different versions with different user data directories.

I see no necessity to add warning popups or even lockfiles.

[axd1967]

good inputs.

the main reason of this issue is to (at least) warn for multiple running instances of the same version, and optionally (at user discretion, on by default) prevent launching the same version multiple times. a user that knows the consequences should be allowed to proceed, a user that doesn't should accept the default of aborting the launch (of the second instance).

obviously running different versions on the same config env is guaranteed to cause issues (e.g. unwanted upgrading or backward incompatibility issues).

so that is an excellent input that needs to be taken into account : the mechanism should be aware of the version that is running, to protect the app from inadvertently accessing a wrong config version. the logic is already present to deal with the automatic upgrading of an older version, so this feature should not only protect against duplicate instances of the same version, but also (maybe optionally?) block the user from running an older version on a config that is more recent, which is very likely to cause problems.

fact is that I hit this issue regularly. it is not urgent and should not be too difficult; if I have time I will try to solve it.

[gzotti]

OK. I leave that to you then. Please also add an option in the popup "Don't warn me in the future." Similar to the "insufficient OpenGL level" warning ("Ignore&continue" option) which appears only once.

[github-actions[bot]]

Thank you @axd1967 for suggesting this feature.

[axd1967]

Those are nice additions, but separate issues:

• memorize the choice (which then also begs for "reset that choice"). this is not blocking for this issue, as the dialog will not pop up that often with most users; it could, however, block automated tests
• apply this to OpenGL warning (is there an issue for this?)

[gzotti]

Issue #1409 has nothing to do with the OpenGL warning which we introduced many years ago and which is visible on systems too old to run the program without problems. I wrote "Similar to the "insufficient OpenGL level" warning ("Ignore&continue" option) which appears only once." because I mean that this warning for "Do you really want to run a second instance" (or similar) should be permanently suppressible when I press "Suppress future warnings". I find such a panel annoying, you want to see it. So it must be permanently suppressible.

[axd1967]

(I'm removing my assignment for now because it belongs in the pool of wishlist issues, so that anyone can take it if needed.)

[github-actions[bot]]

Thank you @axd1967 for suggesting this.

[gzotti]

(Postponed to Tibb's Eve then... Unsubscribing from this issue.)

[axd1967]

(Postponed to Tibb's Eve then... Unsubscribing from this issue.)

@gzotti you should not write such things. because if you are consequent, you ought to add that comment to all issues in the wishlist.

[gzotti]

I try to be consequent to my own agenda. You are the one to have problems running multiple instances, and if even you unassign yourself, this will have to wait. Anyone has not shown up in a decade.

[alex-w]

@axd1967 this "issue" is definitely not "wishlist", because this you YOUR synthetic problem for YOU. Nobody has't this problem, except you. Now you want resolving this problem by hands of someone, but not by you.

[axd1967]

I'm sure I'm not the only one having this from time to time, but it is not a big or high or priority issue.

I never stated anywhere that I WANT someone else to solve it, that I DON'T want to solve it. I could solve it, it is quite trivial, but for various reasons I have no time to do it.

by keeping the assignment, i might block some other dev that would want to tackle this issue, because that dev might think I am busy with it. that's why I remove my assignment, as a clear signal that anyone that wishes to do so, can tackle it; should I find the time, I can still work on it.

this is a nice issue for someone who wants to start developing with a small issue.

please stop being so negative? I've re-read the entire issue and cannot find a reason for such tone. I'd appreciate if someone else, a neutral and objective person, could corroborate this, so that we can bury the war axe. thank you.

[alex-w]

I never stated anywhere that I WANT someone else to solve it, that I DON'T want to solve it.

This is your synthetic problem and you do not want resolve it, so, who should "resolve" it? Developers, who doesn't have it and use this feature? Someone else?

I could solve it, it is quite trivial, but for various reasons I have no time to do it.

If this is trivial for all operating system, where is your solution?

by keeping the assignment, i might block some other dev that would want to tackle this issue, because that dev might think I am busy with it. that's why I remove my assignment, as a clear signal that anyone that wishes to do so, can tackle it; should I find the time, I can still work on it.

Both developers already said that we will not touch this "issue", because this is not issue. But you right now wrote, that this "problem" should solve someone else. Where is logic?

this is a nice issue for someone who wants to start developing with a small issue.

Why not you?

please stop being so negative? I've re-read the entire issue and cannot find a reason for such tone. I'd appreciate if someone else, a neutral and objective person, could corroborate this, so that we can bury the war axe. thank you.

Because you ignore any sentences or explanations and see only that parts of phrases, which you want to see (includes phrases, which we do not said). This is really annoying when opponent see only self opinion and nothing else.

[axd1967]

sigh. can someone please help us out here?