From: F. C. <fab...@go...> - 2008-12-04 08:28:20
|
Perfect! Thanks :) Fabien On Thu, Dec 4, 2008 at 12:12 AM, Mike Storm <oop...@gm...> wrote: > Oops, that one might be broken. Use this one instead. > > On Wed, Dec 3, 2008 at 5:02 PM, Mike Storm <oop...@gm...> wrote: >> Ah, I understand now. Thanks for the explanation. I've attached a >> patch, against revision 4070. >> >> On Wed, Dec 3, 2008 at 4:39 AM, Matthew Gates <mat...@gm...> wrote: >>> The basic idea is for the StelFileMgr to provide a sort of virtual file >>> system which allows the coder to search just within the Stellarium file >>> /structure/ (landscapes directory, skycultures, textures etc.), and let the >>> StelFileMgr decide a /policy/ about which area (user data, installation >>> directory, perhaps even removable media) to take a file from. >>> >>> As it stands now, the policy is that users should be able to override any >>> installed file by making their own copy in the user data directory. This >>> policy is informed by the idea that the installation directory is probably >>> not writable by the user, and that there may be multiple users who will >>> share an installation, but want their own customised version of some files, >>> e.g. custom copies of "data/ssystem.ini" which can be saved in the <ser >>> directory>/data/ssystem.ini for each user. >>> >>> I think it is somewhat similar the union filesystem, if you are familiar >>> with that - some base copy exists and is not modified - all modifications >>> are put in a separate area and the view the user gets is base + >>> modifications. In Stellarium the view the StelFileMgr gives is installation >>> directory + user directory. To revert to the original view, all that needs >>> to be done is to remove the modifications in the user directory. The >>> installation area can be left untouched, and this way we also do not need >>> for the installer worry about overwriting user files when Stellarium is >>> upgraded/reinstalled. >>> >>> I wrote a document trying to describe it, here: >>> >>> http://stellarium.org/wiki/index.php/File_and_Directory_Structure >>> >>> Mike, I had meant to write you to point you at it, but I forgot. Sorry about >>> that! >>> >>> As for the structure within the installation directory and user directory, >>> StelFileMgr does not try to know about this. It cannot know for third party >>> modules, and does not try for the core modules. Thus a programmer provides a >>> partial path which is enough to describe the location in the structure. >>> >>> The structure is not very consistent across different modules/file types, so >>> you need to know the structure for each type file file you want to manage >>> (e.g. landscape files or star catalogues). The structure for a given type of >>> file may be different because sometimes we have a sub-structure as is the >>> case for landscapes, or know about the versions which the star catalogues >>> use. >>> >>> For the downloader, the task is a bit more complicated than when just >>> searching for a file, as you must work out the best location to save new >>> files. The best policy is not totally settled in my mind about the best >>> place to put downloaded files. In general I think user downloaded files >>> should be put in the user directory, but there is a case for wanting to put >>> something very large like a big star catalogue in the installation directory >>> because different users will likely not want to download a separate copy of >>> these files per user... This is complicated because the install directory >>> may not be writable by the Stellarium process. >>> >>> To keep it simple, I would recommend always saving downloaded files in the >>> user directory. If there is a multi-user system (e.g. a classroom setting), >>> a sysadmin can always move a downloaded file to the installation directory >>> manually if they want to make it available to all users and minimise disk >>> usage / bandwidth utilisation. >>> >>> Matthew >>> >>> On Wednesday 03 December 2008, Fabien Chéreau wrote: >>> >>>> OK, Sorry, I was quite confusing myself ;) >>> >>>> What I meant is that the file manager should remain generic in the >>> >>>> sense that we don't want to add a new possible search paths for each >>> >>>> directory we have files into (Matthew correct me if I am wrong!). >>> >>>> Practically instead of looking for <search_dirs>/star5.cat , you >>> >>>> should look for <search_dirs>/stars/default/star5.cat. >>> >>>> Cheers >>> >>>> Fabien >>> >>>> >>> >>> ------------------------------------------------------------------------- >>> 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 > > |