Feature Request: User data files (solarsysu.ssc, etc.)

[don]

Christophe, I think you misunderstood what I wrote. I'm the one who started this thread, with the intent of making it possible to modify Celestia data files WITHOUT having to edit the base files.

NO, a user should NEVER have to modify the base files, but right now, they HAVE TO in certain cases. They have no choice. Which is why I suggested this enhancement in the first place.

-Don G.

[Christophe]

Sorry Don, I got a bit carried away here, I don't even remember how this thread started :-)

Anyway, can we agree on what to do next?

My proposition:
1 - Allow absolute path and ~ extension (Unix) in extras directory definition in celestia.cfg.
2 - Add apropriate user specific default extras directory in addition to the current installation specific one.
3 - Add a per-object definition mode with the possible values: add (default), replace, override.
4 - Add an undef value, to allow removal of properties in override mode
5 - Add a celestia-maintained (user level) list of installed add-ons. Add-ons are loaded in the list order, new add-ons are added at the end of the list. This list is restricted to directory-type add-ons.

Let's keep it at that for now, there is no need to specify more of it until this is done.

[don]

Since it's directly in the add-on ssc file and not 'burried' in celestia.cfg, I think it's in fact less confusing (but maybe that's just me).

Just remember that non-Unix users are not normally as "techie" as Unix users are <smile>.

I'd rather go directly to something extendable to a full blown add-on manager than having to throw this away and restart from scratch in six months.

Throw it away? Why would we want to do that? This idea is one that needs to be considered for the add-on manager anyway -- as a first step -- in addition to defining the manifest file, rules, etc. So, the implementation of this idea (in whatever form) should become part of the add-on manager.

Yes, but I think the current mixture of supported add-on formats is the main culprit, we should only support extras sub-directories and drop the older standard.

Agreed. ONE "official" way to provide an add-on would be a welcome relief for all beginners to Celestia.

It wouldn't have to be a full GUI at first. A simple text file listing the add-on directories in their loading order would be a first step.

This sounds like a good first step. In order to create this list, there will also need to be a function in Celestia that the user can access, to generate the file based on the current extras directory content.

Then we can proceed to the creation of UI components (dialogs, widgets, etc.) for each UI.

Now, getting back to the reason for this thread, do we have any kind of agreement as to HOW Celestia should handle additional data files?

-Don G.

[Christophe]

Since it's directly in the add-on ssc file and not 'burried' in celestia.cfg, I think it's in fact less confusing (but maybe that's just me).

Just remember that non-Unix users are not normally as "techie" as Unix users are <smile>.

Yes, but only add-on creators will have to deal with that. It just seems logical to me that he has to chose when writing his ssc file wether it's a new object or if he is merely editing some of its properties.

Having this setting in celestia.cfg means the add-on creators have no control over it and that a given add-on will work with only one given value of this parameter. Two add-ons written for two different settings won't be able to work on the same installation. So I think it has to be at the object level.

[don]

My proposition:
1 - Allow absolute path and ~ extension (Unix) in extras directory definition in celestia.cfg.
2 - Add apropriate user specific default extras directory in addition to the current installation specific one.
3 - Add a per-object definition mode with the possible values: add (default), replace, override.
4 - Add an undef value, to allow removal of properties in override mode
5 - Add a celestia-maintained (user level) list of installed add-ons. Add-ons are loaded in the list order, new add-ons are added at the end of the list. This list is restricted to directory-type add-ons.

1. What is "~"? Is this relating to Harald's request to allow an OS-specific "home" directory to be used?

2. Not sure what you mean here. Like "/celestia/donextras"?

3. Please specify conditions for these, as they are confusing to me. How is replace different from override? In Harald's initial suggestion, Replace is related only to a complete-object. In other words, Replace=true would replace the ENTIRE object with a new specification. Replace=false would add an additional object of the same name with a new specification. When Replace is NOT specified, existing LINES in the specification would be replaced with the new data.

4. Agreed.

5. Agreed. Just a thought ... Celestia could generate this list ever time it loads, since it is in fact already accessing the files .. very much like a "load log".

-Don G.

[don]

Having this setting in celestia.cfg ...

Not sure where you got this idea. Harald suggested it for the .ssc files, not for the .cfg file. And I agree.

-Don G.

[Christophe]

Having this setting in celestia.cfg ...

Not sure where you got this idea. Harald suggested it for the .ssc files, not for the .cfg file. And I agree.

Sorry, now I understand, that's because Harald used the generic term 'config file' for the catalog files. I assumed he was refering to celestia.cfg instead... My proposed 'Mode' and Harald's 'Replace' are in fact the same thing and a simple implementation detail.

[Christophe]

1. What is "~"? Is this relating to Harald's request to allow an OS-specific "home" directory to be used?

Yes, on Unix ~ is a shorthand for the current user's home directory. Allowing variable expension could be useful to. I think on Windows the current user's Document directory location is available in an environment variable (%HOMEPATH%).

2. Not sure what you mean here. Like "/celestia/donextras"?

Yes, more or less. On Windows we could have:

Code: Select all

ExtrasDirectories    [ "extras" "%HOMEPATH%\Celestia\extras" ]

and on Unix

Code: Select all

ExtrasDirectories    [ "extras" "~/Celestia/extras" ]

3. Please specify conditions for these, as they are confusing to me. How is replace different from override? In Harald's initial suggestion, Replace is related only to a complete-object. In other words, Replace=true would replace the ENTIRE object with a new specification. Replace=false would add an additional object of the same name with a new specification. When Replace is NOT specified, existing LINES in the specification would be replaced with the new data.

See my previous message, Replace and Mode are the same thing.

4. Agreed.

5. Agreed. Just a thought ... Celestia could generate this list ever time it loads, since it is in fact already accessing the files .. very much like a "load log".

Yes, that's what I intended.

[don]

Thanks for your answers Christophe.

I'm not sure about %HOMEPATH% but I'm sure there is something in Windows defined for it. It all sounds good to me. Where do we go from here?

Other developers out here: Are you okay with this enhancement?

Does someone now add this to a Celestia to-do list, or just to the Add-On Manager to-do list, or? I don't yet understand the full process.

Cheers,

-Don G.

[David]

I think Christophe's plan is a good one. I think the word override is a bit ambiguous though.

How about:

Mode = Add (default)
Create a new object without affacting others with the same name.

Mode = Replace
Delete all objects with the same name, so this is the only one.
(but others can be added later)

Mode = Update
All objects with this name get the changes.