Oculars: ability to mark "Active" telescope, eyepiece, etc.

[blakesphere]

hello,

With the addition of many more telescopes, camera sensors, and eyepieces in the oculars list, it makes switching in the Oculars tool cumbersome or slow. I have an idea or feature request for easing or improving usage.

When I help or train people with the feature, I recommend deleting all non-relevant entries in the lists. Only include items in your kit. Then switching is quick and easy.

I am reminded on Software Bisque's TheSky. They have an "active" Boolean checkbox on each item. So while there's long lists of 'scopes and eyepieces, you can designate an active combination and only those are used or available for the session.

So could a "active" Yes/No checkbox be added to the Oculars sections for the equipment lists? In Eyepieces, it could sit below the "Binoculars" and "cross=hairs" checks, in the Telescopes tab, below the "Equatorial Mount."

regards, Blake

[github-actions[bot]]

Thanks for adding your first issue to Stellarium. If you have questions, please do not hesitate to contact us.

[github-actions[bot]]

Thanks to @blakesphere for suggesting this enhancement.

[axd1967]

Note that if items can be made "inactive", they could also be omitted from the Ocular popup (Alt-O),making this menu easier to use?

[treaves]

Whereas I understand the intent here, I'm not sure this is something that should ever be added. The majority of users are not going to have huge lists of equipment where they want to enable/disable particular pieces. And - as I'm trying to get other contributors to understand - just because a feature could be added, does not mean is should be added.

What I do in cases like this is to have multiple ocular.ini files. During development, I can then switch to a particular tailored one for the purpose at hand. You can use a simple shell script / Automator Action to put thee correct ini file in place and then start the app.

If I'm not understanding something, please let me know.

[axd1967]

Whereas I understand the intent here, I'm not sure this is something that should ever be added. The majority of users are not going to have huge lists of equipment where they want to enable/disable particular pieces.

agree!

And - as I'm trying to get other contributors to understand - just because a feature could be added, does not mean is should be added.

generally agree...

What I do in cases like this is to have multiple ocular.ini files. During development, I can then switch to a particular tailored one for the purpose at hand. You can use a simple shell script / Automator Action to put thee correct ini file in place and then start the app.

nice, but might be too technical for some, if not many users. and playing with files outside the app is risky

I'm facing this issue in following scenario: I'm switching between different telescope facilities and would like to see the ocular collection for one facility.

fundamentally, users all want to add/manage more "stuff" and this asks for more powerful ways to organise "stuff". the trivial approach is to provide a list to store things, the next step is to be able to provide trees, and even better, (hyper)tags, to group and filter items. and of course, this demands development efforts and we do understand that this is not a high priority issue. -> for_wishlist

[gzotti]

I also feel the majority of users of this plugin will have one telescope, 1-3 finders/binos, and 2-5 eyepieces. Indeed, the 4 "power users" of such feature can learn to copy/rename their ini files. Given how fast a piece is configured, adding favorite tags may really not add much to the functionality, but much to the inner logic (which must then be maintained).

[blakesphere]

Here's some of the reasoning for my feature request.

I own 4 telescopes. I own over a half-dozen eyepieces. So there's a few permutations there. I totally understand that makes me a bit of a special case.

But here's the really over-to-top reason.

I'm a supervisor at our club observatory. There are about 5 telescopes there that I use, and each has it's own sensors and eyepieces. And sometimes I use my own with a loaner 'scope.

I am an operator at the David Dunlap Observatory. I want to simulate views and camera fields in that somewhat-large 'scope.

And, finally, I use some robotic telescopes, so there are different setups there that I'm trying to mimic.

Oh, and I have access to small through large binoculars.

I leave it to the programmers to prioritise, of course. But I wanted you to understand my perspective. I'd like to load in EVERY 'scope, camera, and eyepiece I have but only show relevant ones for a given observing session. Again, it is nicely implemented in TheSky so I wondered, out loud, about having it in Stellarium.

In the meantime, I just delete all the entries that are not needed.

Blake

[axd1967]

by the way, one inconvenience in separate ocular.ini is that it contains settings that are not relevant to specific oculars.

the file should be split up in at least two files:

• ocular stuff
• personal Stellarium settings (see #856)

[axd1967]

(and I'm quite sure there are more users that have to deal with this kind of permutations :-) )

[treaves]

And - as I'm trying to get other contributors to understand - just because a feature could be added, does not mean is should be added.

generally agree...

@axd1967 See https://www.cloudynights.com/topic/754842-the-sorry-state-of-pc-planetarium-software/page-4#entry10999064 as to why this is the case if you are interested.

[treaves]

I understand the desire, and the use case. I myself have about the same number of things in my inventory. And having inventory that could be tied to a 'site' may be handy. One of the things I will be doing is completely changing the ini file; how it's structured, and what is in it. I may also change how the equipment is handled to begin with, as it is now cumbersome with all the permutations. Perhaps once I've done that, something like this may be easier. I'll revisit it then.

[blakesphere]

Indeed, Greg Crinklaw added that to the latest version of SkyTools. The ability to associate a telescope and accessories with a location. But that's a whole different beast! :-)

[treaves]

Actually the location affinity may make it easier to implement.

[axd1967]

One of the things I will be doing is completely changing the ini file; how it's structured, and what is in it. ... Perhaps once I've done that, something like this may be easier. I'll revisit it then.

Do consider using the Yaml format. It is a very user friendly format, and also makes versioning easier (less merge conflict issues when one wants to merge files from e.g. other users).

There is however currently no support for Yaml inside Qt (which is strange because Qt itself uses it), nor is it being used yet in Stellarium (except for the CI / GitHub stuff).

[10110111]

It is a very user friendly format

This is a superficial impression. Having significant whitespace—even line breaks—makes it quite error-prone, more so than Python. I had been using YAML in a project at work for a couple of years, and had too many times where a seemingly insignificant mistake made a radical change in interpretation. After all this, the project was switched to XML, with the additional bonus of input validation via XSD and a much more developed tooling ecosystem.

[axd1967]

It is a very user friendly format

This is a superficial impression. Having significant whitespace—even line breaks—makes it quite error-prone, more so than Python.

Understand, but disagree; YAML is explicitly designed for human use as the first goal (ref). (https://yaml.org/), while INI originates from Windows ("_a usable format for configuration files that do not require much greater complexity. WP_").

The so-called inconvenience of YAML (which is soon detected by the user, nevertheless see also StrictYAML) is outweighed by the convenience of readability as well as versioning.

A major issue with INI is the key/value construct, which makes it difficult to modify (e.g. reorganising, versioning); if I'm not mistaken, this is the result of using QSettings. In fact, the choice for QSettings results in a difficult to manually edit file (which - agreed - was probably not the intention anyway).

https://github.com/Stellarium/stellarium/blob/c98b3c934109fb179e690b5dc935db7b2657cf2e/plugins/Oculars/resources/default_ocular.ini#L14-L29

I had been using YAML in a project at work for a couple of years, and had too many times where a seemingly insignificant mistake made a radical change in interpretation. After all this, the project was switched to XML, with the additional bonus of input validation via XSD and a much more developed tooling ecosystem.

Anyone not sufficiently mastering a format (be it INI or YAML) can cause problems. IMHO YAML will be less error-prone than INI.

In the list of INI/XML/YAML, XML is the least user friendly: lots of typing, quite difficult to read for the average Stellarium user, let alone XSD.

One could argue whether end users should be given the possibility to directly manipulate such files; IMHO this extends the flexibility of Stellarium.But I have the impression that many Stellarium users are quite familiar with editing configuration files.

[gzotti]

XML was only mentioned as less error prone than YAML in some project unrelated to Stellarium. We have no intention of switching from INI to XML.

These requests for place-dependent lists, versioning of easy-to-enter data, user data exchange in formats not native to the program, ... for a small handful of very advanced users who appear to have profound knowledge in those formats and how to develop software sound like justifying development of third-party programs to be executed before running Stellarium (as preparatory step, like driving to the observatory), or some program wrappers that do exactly what they need. It may take a minute to understand that oculars etc. need to be prepended by index number in the .ini file. If this makes the .ini format too hard to understand, sorry.