Re: [Stellarium-pubdevel] Star data files

[Mike S. <oop...@gm...>]

A restart is required. I looked into dynamically loading them, but I
didn't know enough about how they're drawn, so I focused on getting
the downloader itself implemented. That can be worked on.

Mike

On Tue, Nov 18, 2008 at 4:02 AM, Fabien Chéreau
<fab...@go...> wrote:
> Are the loaded stars files automatically loaded or is a restart required?
> Fabien
>
> On Tue, Nov 18, 2008 at 10:43 AM, Mike Storm <oop...@gm...> wrote:
>> On Mon, Nov 17, 2008 at 9:07 AM, Matthew Gates <mat...@gm...> wrote:
>>> On Monday 17 November 2008, Mike Storm wrote:
>>>
>>>> On Mon, Nov 17, 2008 at 6:36 AM, Matthew Gates <mat...@gm...>
>>>> wrote:
>>>
>>>> > I just tried this for the first time. A few observstions:
>>>> >
>>>> > * While a catalog is still download, I think an attempt to close
>>>> > Stellarium should result in a dialog box telling the user that a
>>>> > download is still in progress.
>>>>
>>>> I can see the concern, but is a dialog box necessary? It's not
>>>> dangerous at all to simply stop the download. And the catalogs are
>>>> downloaded as <catalog>.tmp before being moved to <catalog>.cat, so
>>>> there's no risk of loading a truncated file.
>>>
>>> It's just that the downloads of the larger cats can take a very long time
>>> and I think people will forget they are downloading them, and the download
>>> will be mistakenly aborted before it can be completed unless there is a
>>> reminder when the program is closed.
>>
>> Okay, I agree. As a side note, how would I add another .ui and/or .cpp
>> file to be compiled into Stellarium? I took a look at the cmake
>> documentation, but I'm having trouble sorting out the files I should
>> edit from the automatically generated ones. And I don't want to screw
>> something up.
>>
>>>
>>> I do not mean that the dialog should be visible the whole time, just if the
>>> user tried to quiet before the download is complete.
>>>
>>> By the way, if there is a file which is partly downloaded, will it be
>>> resumed on the next run, or will the download begin from the start?
>>
>> Right now, it's completely restarted. But it doesn't seem hard to
>> resume downloads, so I'll work on that.
>>
>>>
>>>> > * I think downloaded files should go in the
>>>> >
>>>> > <user data directory>/stars/... not the installation directory.
>>>>
>>>> Makes sense. So the standard catalogs and downloaded catalogs would be
>>>> separated, then?
>>>
>>> I think they can be. The purpose of the split is two fold:
>>>
>>> 1. Each user on a multi-user system should not be able to alter the base
>>> install. At the moment the config is copied to the user-specific user data
>>> directory for each user, so they can maintain different settings. Likewise,
>>> I prefer to advise people to install landscapes in the user directory, not
>>> the installation directory to avoid confusion between users.
>>>
>>> 2. The installation directory will not be writeable on many systems where
>>> software is installed only by an admin user. If we assume we can write to
>>> the install directory, admins must make it so, and this is not conducive to
>>> good system management.
>>>
>>>> Another option would be to keep the standard catalogs
>>>> where they are, in <installation>/stars/default/, and stick new ones
>>>> in <installation>/stars/downloaded/. I'm a fan of your idea, though.
>>>> What do you think?
>>>
>>> The original catalogue files will be in the installation directory. Extra
>>> catalogues can go in the user directory. If you use the
>>> StelFileMgr::findFile to locate a path, it will search both, with the user
>>> directory looked at first. Thus if there is an update to the base catalog
>>> file, they can be put in the user directory and will be used in preference
>>> to the original installed ones. If the user then wishes to revert to the
>>> original files, all she need do is remove the new copy in the user
>>> directory.
>>
>> Yup, makes sense. I added getUserDir()+"/data/stars" and
>> getInstallationDir()+"/stars/default" to the search paths of
>> StelFileMgr.
>>
>> Mike
>>
>>>
>>> Matthew
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Stellarium-pubdevel mailing list
>>> Ste...@li...
>>> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>>>
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Stellarium-pubdevel mailing list
>> Ste...@li...
>> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Stellarium-pubdevel mailing list
> Ste...@li...
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>