1.6 and Extras

[rthorvald]

I did a clean install of Celestia from CVS today - full download.

There are two things i?d like to bring up:

1.
I noticed that the CelestiaResources folder (OSX) had disappeared along with some other stuff, and saw it had been moved to inside the app package. So i thought the AddOns should go in Application Support. The ReadMe confirmed this, so off i went...

No matter what i do, Celestia will not recognize any extras. I tried ~application support/celestiaresources/, with our without subfolders (extras/addons/data etc, all possible confirgurations. Nothing works. So i moved it to Application Support in the root library instead, and tried all the possibilities there too. Will not work. I tried upper case, lower case, etc. Everything i could think of. Nothing works.

The only thing that works is to put my extras inside the application bundle itself, and that is obviously not how it should be. So, either there is a bug in today?s CVS, or there is some naming scheme here i just cannot detect...

2.
I really like the idea of having all the extras in my ~Application Support folder in my user dir, since it makes updating Celestia simpler and also makes my backup scheme easier. Not only that, but it conforms to how all other OSX apps behave, which is simple and neat (as long as it works, that is )

But i think that start.cel, the config file and an example of how to modify solarsys.ssc (a simple texture-swap for a solar system object, for example) should ALSO go in Application Support, for new users to discover. Most people will never think to look inside the App itself, so this very basic functionality will take them a *lot* more time to discover. I can almost guarantee there will be many, many support requests here in the forum from newbies just because these essential items is now hidden.

I realize this will require an installer, but hiding it is a *really* bad idea.

One more thing - a "feature request" for this new scheme:
While it makes sense to have Extras in the App Support folder, i think it would be great if one could tell Celestia - via the Preferences dialog - to look for Addons in any dedicated folder. Have App Support/CelestiaResources as default, but let the user pick any folder to replace it.

- rthorvald

[Cham]

I did a clean install of Celestia from CVS today - full download.
...So, either there is a bug in today?s CVS, or ...

You mean SVN, not CVS.

And don't forget about the scripts folder, which should be user configurable too. The scripts folder should also be of very easy access. To me, the config, start and scripts shouldn't be in the Library folder at all. They should stay next to their app (most of my OS X don't even use the user/library folder, except for their preferences file !).

... and to my opinion, ALL celestia's ressources (textures, models and data) should also be made easily available to any user. A new user (or even an experienced one like myself) would want to study the solarsys.ssc file, for example, to copy some parts, etc. And the lores, medres and hires textures folder should be made of easy access too, for obvious reasons. As I told to the developpers (on their mailing list), I TOTALLY disagree with the directories changes that they made to the OS X version some time ago.

Here's an example why the textures and models folder shouldn't be in the app itself : I'm using about 600 MB of custom hires textures and models (for giant gas, rings, nightlights, normalmaps, clouds, asteroids and comets, etc...). These files are in the default folders, so most of my addons could use them without duplicating the files. If I had to replicate the files for each addon that uses them, I would end with several GB of files on my installation. This is insane.

The default textures and models folders are **basic** folders to place any file a user wants to use with his/her installation. Why hide them in the app itself ? Hiding stuff to the users doesn't help the new user in any way.

[rthorvald]

The default textures and models folders are **basic** folders to place any file a user wants to use with his/her installation. Why hide them in the app itself ? Hiding stuff to the users doesn't help the new user in any way.

Yes, svn, sorry.

But on the point above, i disagree. The default installation of these files are so modest they don?t take up any noticeable space on a modern computer. You can achieve everything you mentioned by cloning solarsys.ssc and insert a Modify at the beginning of each entry.

I really like that i can have the app separated from the extras. But we do agree on the config files etc. They must be visible.

- rthorvald

[Cham]

The default installation of these files are so modest they don?t take up any noticeable space on a modern computer. You can achieve everything you mentioned by cloning solarsys.ssc and insert a Modify at the beginning of each entry.

That's not the point. What if you want to use 600 MB of textures and models for most of your addons ? Will you duplicate them 20 times, if you're having 20 addons which are using the same textures and models for all your asteroids, comets, giant gas, etc ? This will give you a 20*600MB ~ 12 GB of redundant stuff on your installation. With the new directories structure, you'll have to open the app package to add your textures and models, so your app will be a +600MB fat app !

[rthorvald]

With the new directories structure, you'll have to open the app package to add your textures and models, so your app will be a +600MB fat app !

I don?t understand. What is it you cannot do in an external extras folder? Surely you can structure everything the same way there...

- rthorvald

[Cham]

I don?t understand. What is it you cannot do in an external extras folder? Surely you can structure everything the same way there...

No.

Lets say you have two separate addons in your extra folder. Both are using the same asteroid model and texture. You place the model and texture into your standard default models and textures folder (not in the extras), to save disk space. Both addons will load the files from the default directory. Of course, you could also place a copy of the same model and texture into both addons (you then have two times the same files, in the extra folder).

For few files, this isn't a problem. But if you're using +500MB of hires textures for most of your addons, you don't want to duplicate them for each addon, or else you'll fill your HD pretty fast.

I'm currently using 600MB of various models and textures that many of my custom addons are using as "default" textures. Mostly models of hires asteroids, hires textures of giant gas exoplanets and moons, many ring textures, nightlights, normalmaps, etc. Duplicating them for all the addons would be insane. So I need the models/textures folders to be visible and of easy access. I'm sure many other users are using Celestia this way too.

[rthorvald]

Lets say you have two separate addons in your extra folder. Both are using the same asteroid model and texture. You place the model and texture into your standard default models and textures folder (not in the extras), to save disk space. Both addons will load the files from the default directory.

Ok, i see. You can only replicate this by making one super-add-on of everything, which is very messy. The way you set up things, you need the real extras folder. But i am not at all sure anyone that is familiar enough with Celestia to do what you have done will have any trouble with that - strictly speaking, it is just one level further down than before, it?s not harder to get to, just more difficult to find if you aren?t familiar with OSX.

- rthorvald

[t00fri]

Stupid question:

OSX has an underlying UNIX, so you must have support of genuine symbolic links. With this you NEVER need to redouble anything. you just redouble the file names, but NOT their actual content.

Fridger

[Cham]

And there's another point about this directory structure (on OS X). In the config file, the user has the ability to define many stellar textures (which should reside in the default textures folder) :

Code: Select all

StarTextures
{
   # This texture will be used for any spectral type not listed
   # in this block.
   Default "astar.jpg"

   O "bstar.*"
   B "bstar.*"
   A "astar.*"
   F "astar.*"
   G "gstar3.*"
   K "gstar.*"
   M "mstar.*"

   # carbon stars
   C "mstar.*"
   R "mstar.*"  # former subclass of carbon star
   N "mstar.*"  # former subclass of carbon star
   S "mstar.*"  # roughly between M and C

   # Wolf-Rayet stars
   WC "bstar.*"
   WN "bstar.*"
   
   # brown dwarfs
   L "browndwarf.*"
   T "browndwarf.*"
   
   # stellar remnants
   WD "astar.jpg"
   NeutronStar "astar.jpg"
}



With the new Celestia OS X directories hierarchy, this becomes inconsistent. The user can't edit anymore the config code above, which becomes useless !

[rthorvald]

With the new Celestia OS X directories hierarchy, this becomes inconsistent. The user can't edit anymore the config code above, which becomes useless !

I think i wlll have to agree with Cham - the implications of hiding the resources without giving the user other means of accessing them is apparent.

I want the new scheme, as it conforms to the OSX philosophy and (in principle) makes things simpler, but Celestia is not really structured to support it. It would have been different if one could access the config file in a dialog in the program, e.g. the Preferences Dialog, as most people aren?t aware of the Application Package model. Many that are will naturally think the files are hidden for a reason, and will not want to to edit what?s inside for fear of breaking the program.

In effect, it limits the user experience - the ability to explore the program - and will drive people to post questions here instead (how/why can?t i...) for very basic things.

- rthorvald

[rthorvald]

OSX has an underlying UNIX, so you must have support of genuine symbolic links. With this you NEVER need to redouble anything. you just redouble the file names, but NOT their actual content.

But most people are unaware of this. To most people a computer is a sort of household appliance. They have NO idea of it?s underlying powers (you may say they should get to know their machine better, as you usually do ) but most simply will not, so that doesn?t help... Instead, they will complain in the forum or just give up, believing Celestia cannot do what they want. To put it another way, if you hide the resources they need, their learning curve becomes too steep to let them learn...

- rthorvald

[chris]

The new structure was introduced to try to make Celestia more like a standard Mac application and to simplify the installation process. Having to copy the CelestiaResources folder to Library/Application Support is non-obvious and clunky. Users have to open the Readme file in order to find out how to install the app. With the new scheme, this is unnecessary. This is a major improvement for the average user. App installation should be a no-brainer. Also, Celestia may be run directly from a CD or flash drive--nothing needs to be copied to the hard drive. This is great for demos.

Celestia is moving toward a configuration where user added extras exist in a separate location than the core files. This separation will help keep inexperienced users from installing add-ons in places where they'll get overwritten by upgrades. Celestia has features (such as Modify and Replace) that make modifying the core data files unnecessary except in a small number of specialized situations. In such situations--such as Cham's shared textures and models--then yes, there's some added inconvenience because you'll have to mess around in the app folder. But, these situations are not common, and users sophisticated enough to require them also know how to change files in the app folder.

With the packaging changes, DW added support for loading a .celestia.cfg file from the user's home directory. To quote him from the developers list:

No problem, just copy the celestia.cfg file that you have to
".celestia.cfg" inside your home directory, and edit that instead.

Continue putting your custom extras in Library/Application
Support/CelestiaResources/extras, just like before, and Celestia will
pick them up automatically.

The one problem here is that a user will have to find the original celestia.cfg in the app directory and copy it to his or her home directory. This isn't ideal. An installer for Celestia could automatically create .celestia.cfg in the user's home directory, but we'd prefer not to have to use an installer. Perhaps it would be enough to include a sample .celestia.cfg file in the disk image along with a readme? Still not ideal, but at least a user could still run Celestia without having to run the program. And it's perhaps even a bit easier to discover config file when it's sitting right next to the disk image than when it's buried in CelestiaResources.

In future versions of Celestia, we do want to make it possible to set important celestia.cfg options via the GUI.

--Chris

[rthorvald]

Continue putting your custom extras in Library/Application
Support/CelestiaResources/extras, just like before, and Celestia will
pick them up automatically.

Well, the only problem with this is that it does not work... See the first message.

- rthorvald

[Cham]

Chris,


with the new directory structure, nothing is actually working great. The idea may be great, but in real life it isn't at all. It's all clunky now, despite your claims. And it is FAR away from a real OS X experience !

And don't forget about the config file, which now contains some useless options with the new directory structure.

[t00fri]

Chris,


with the new directory structure, nothing is actually working great. The idea may be great, but in real life it isn't at all. It's all clunky now, despite your claims. And it is FAR away from a real OS X experience !

And don't forget about the config file, which now contains some useless options with the new directory structure.

But since Chris has a MAC himself, I bet he has tried out the new scheme, too

Fridger

[ElChristou]

Sorry for the late opinion, I'm still in process of dsl connexion...

As said on the dev mailling list, this scheme is far from being ideal, even for demos as stated by Chris (Chris, I hope you do your demo with better datas than the default package!). Perso I need at least 4 Go to show a stunning version of Celestia...

My main concern is the cfg file is not anymore accessible easily. As there is not (yet) any addons manager, my solution is to use multiples cfg files, each one adapted to what I want to use/show. You can imagine that digging for those files is not that cool.

Anyway, as I do understand the arguments by Chris, the only solution I see would be a complete cfg panel in the GUI. Possible?

[duds26]

I did a clean install of Celestia from CVS today - full download.

There are two things i?d like to bring up:

1.
I noticed that the CelestiaResources folder (OSX) had disappeared along with some other stuff, and saw it had been moved to inside the app package. So i thought the AddOns should go in Application Support. The ReadMe confirmed this, so off i went...

No matter what i do, Celestia will not recognize any extras. I tried ~application support/celestiaresources/, with our without subfolders (extras/addons/data etc, all possible confirgurations. Nothing works. So i moved it to Application Support in the root library instead, and tried all the possibilities there too. Will not work. I tried upper case, lower case, etc. Everything i could think of. Nothing works.

The only thing that works is to put my extras inside the application bundle itself, and that is obviously not how it should be. So, either there is a bug in today?s CVS, or there is some naming scheme here i just cannot detect...

2.
I really like the idea of having all the extras in my ~Application Support folder in my user dir, since it makes updating Celestia simpler and also makes my backup scheme easier. Not only that, but it conforms to how all other OSX apps behave, which is simple and neat (as long as it works, that is )

But i think that start.cel, the config file and an example of how to modify solarsys.ssc (a simple texture-swap for a solar system object, for example) should ALSO go in Application Support, for new users to discover. Most people will never think to look inside the App itself, so this very basic functionality will take them a *lot* more time to discover. I can almost guarantee there will be many, many support requests here in the forum from newbies just because these essential items is now hidden.

I realize this will require an installer, but hiding it is a *really* bad idea.

One more thing - a "feature request" for this new scheme:
While it makes sense to have Extras in the App Support folder, i think it would be great if one could tell Celestia - via the Preferences dialog - to look for Addons in any dedicated folder. Have App Support/CelestiaResources as default, but let the user pick any folder to replace it.

- rthorvald

I really don't like the way you're going.
If you spread files, and extra's from applications in your home directory or anywhere else then in the application folder itself,
it gets really, really messy. And it is really bad for the portability.
(Spreading the files of a program all over the system's directories is one of the stupidest things you can do. Your program gets really fragmented and eventually hard to debug and impossible to keep cross-platform without an insane amount of work.)


Instead of moving everything, make a symbolic link or shortcut in the App Support folder that goes to the celestia application (extra's) folder by the INSTALLER. And make the folder Extra's in the celestia's application bundle itself.
DO NOT make App Support/CelestiaResources as default.
AND let the user pick any folder to ADD to it AND NOT to replace it.
(You can still have your easy backups the way you want, rthorvald)

So users can follow their way of thinking. (And also mention how this works in the celestia user manual.)
Addons should be in the celestia application folder, they are separated by the folder extra's.
The uninstaller should ask to delete also the extra's folder or not. (Default no.)


However I agree with multiple directories for celestia addons. (editable with a GUI)
So keep the extra's folder as default, it really should be and stay the default.
(=good portability handy for e.g.CelestiaPortable and no platform dependencie) but also make default a link to that AppSupport.
(In the installer the default should be on/checked, that is the easiest for people who know less.)

And also the ReadMe is to blame here, good documentation helps a lot.
And bad can really confuse users so badly, that they get rid of apps.


There is something very funny about the assumptions you make if you think about it:
For adding addons to that app. "Most people will never think to look inside the App itself."
(Sadly you are right on this one.) The need for good, correct documentation is high here.
And Most people also don't know how to open a .cfg file.
And aren't good in reading the configuration code, really that isn't very useful.
(Nothing that can't be solved with some documentation on the right place.)


Now about the: But i think that start.cel, the config file and an example of how to modify solarsys.ssc
The start.cel should be in extra's, the config file should stay where it is, and the example should also go in extra's.
(There is a really big need for an addon manager.)

Mayby changing the folder Extra's in celestia (in the application folder) into Content,
where Content can be stored (all the addons) documentations other stuff.
The name content is really clarifying the function of it (But it still should be documented to prevent confusion.
(If you think about it: Content should go there.)
Something to consider for a new version of Celestia (after 1.6) and when there is a new kind of script(format) to describe addons when there will be an addon manager. (and to present it to the user)

[John Van Vliet]

--- edit ---

[Cham]

Here's another argument against the new directory structure for the OS X version :

At my work place, we're setting up a new computers lab for the astronomy and astrophysics courses (there will be a new astrophysics course at my institution, next winter). I'll have to give some config and start files (and possibly several scripts) to the students. Many are using Macs at home. So, with the new hidden files philosophy, this will creates lots of new problems and may even prevent completellly some homeworks to be done properly.

[duds26]

Here's another argument against the new directory structure for the OS X version :

At my work place, we're setting up a new computers lab for the astronomy and astrophysics courses (there will be a new astrophysics course at my institution, next winter). I'll have to give some config and start files (and possibly several scripts) to the students. Many are using Macs at home. So, with the new hidden files philosophy, this will creates lots of new problems and may even prevent completellly some homeworks to be done properly.

How can that be a big issue.

You can explaign how addons work in Celestia during the course. (This doesn't have to take an hour.)
And document it in a separate guide for them.
And document it also in the course documents.

And really, I see astrophysics and astronomy.
You have to be pretty smart to be able to do that.
Then your students shouldn't have the problems you mention.