Re: [Stellarium-pubdevel] cross platform file locations

[Matthew G. <mat...@gm...>]

On Monday 21 May 2007, Rob Spearman wrote:
> I think recorded scripts would be better saved to the .stellarium/script
> directory where they could actually be run.

Yes, I had considered this.  I think we also need an option to name the 
script at the end of recording - stellarium1.sts stellarium2.sts ... are 
not very helpful names.  For planetarium users with only a remote, we need 
to suppress this or have some mechansim to name files with the remote, like 
an on screen keyboard type thing.


> Screenshots are probably OK in the home directory so they are easy to
> find.
>
> Regarding the script filesystem layout, I am having second thoughts
> about the change requiring one directory per script in the script
> directory.
>
> On the plus side it may push people to better organize their assets
> (although it does not actually require this).  
>
> On the minus side
> it adds some redundancy


Do you mean in the file names - that the name is in both the directory and 
the file.sts?  We could make the file name always "main.sts" or something 
like that if you would prefer.


> [adds some] filesystem overhead

I don't think it's that much of an issue, but that is an empirical 
question - can you test a scenario on your hardware with thousands of 
scripts to see if it takes a very long time to scan for them?  We can 
mitigate this problem with some caching of directory contents based on the 
modification date if necessary, although this is very ugly.

I just did a test with 4648 randomly named scripts on my 1.7 GHz machine 
with a 7200rpm disk, and the only noticable impact is about half a second 
delay between pressing 'm' and seeing the TUI menu.

I think long before large number of scripts lead to a performance problem 
there is a serious usability problem with the TUI menu to select a 
script...


> and requires revising existing scripts to get all the paths corrected.  

Yes, that's a serious drawback.


> It also gets in the way of turning the script directory into a tree for 
> when we have too many scripts and need to group similar scripts 
> together in subdirectories.  


Yes.  Did this work before?  I don't think we ever had the functionality to 
descend a tree of directories, nor the TUI contols to navigate such a tree.


> Sharing scripts gets a little more complicated also, if a zip file or
> such is required (maybe we wouldn't require that) on a URL download.  

That is only the case for single-file scripts. Scripts with images or 
sub-scripts are best distributed in a container such as a zip file, and for 
those it makes little difference.


> So I would like to go back unless someone objects?

It should be fairly easy to change it back.  If you would like it that way 
ane no-one else objects I am happy to do the change.


> Also, why do the landscape directory, landscape name, and landscape.ini
> section name ALL have to match?  

They don't.  The landscapes sub-directory must match the section name in the 
landscape.ini file, but the name is free to be different if we wish.

> Seems overly redundant.  I expected the 
> directory to match the ini section, and the name to be a human readable
> name string with spaces possible, but no.

It works like that for me.  I edited the ocean landscape.ini file to have 
the following:

name = Test Name

And it works OK.  see: 

http://www.porpoisehead.net/misc/landscape_name_test.jpg

How did you get it to fail? 


> Actually the ini section name 
> could just be "landscape" and the directory could be the key, couldn't
> it?  Anywhere we can reduce redundancy like this reduces brittleness.

Yes, I agree.  I shall change this.  


>
> Rob
>