[TR] - Many applications need to remember things about themselves, like GUI appearance, default values, last opened files and so on. Since [Tcl] is cross-platform, once a program is deployed on different platforms, you want to handle this point in different ways. There are several places, where you can or should store data. A short and simple procedure is described in: [Application-specific RC files]. I don't describe here, ''how'' you should store the data. This is dicussed in: [Techniques for reading and writing application configuration files]. ---- '''Unix''' User specific settings normally go in the home directory in a dotted file (or directory) like ... file join $env(HOME) .configFile [[And by convention, named something like .'''appname'''''rc'' [RJ] ]] [BR]: You can just write that as ~/.''appname''rc or ~/.''appname''rc.tcl. GUI appearance is normally configured via the [option database]. The directory can be something like /usr/lib/X11/app-defaults/ but I am unsure, whether all Unix systems use this very directory. '''Windows''' Windows knows several places. First there is the same location as in Unix: file join $env(HOME) configFile.dat The ''$env(HOME)'' part seems always to be there, also when the HOME variable is not set in the autoexec.bat file (see: [HOMEPATH]). But is this true for all incarnations of Windows (95,98,ME,XP,2000, ...)? [BR]: Tcl insures that $env(HOME) is present, creating it from other environment vars if necessary. Again you can just write it as ~/.''appname''rc.tcl. Then there is the registry. You don't seem to need to know the location of the registry, just use the [registry] package: package require registry Simple name-value pairs might appear in '''HKEY_CURRENT_USER/Software/Me/MyApp''' or '''HKEY_LOCAL_MACHINE/Software/Me/MyApp'''. Many programs just store their data along with the installation directory, often in the same directory as the executable. So you would need to know this location from inside the script. This depends on using a simple [script] or a [starkit] or another kind of wrapped application like [freewrap]. Here are some references: * [Determining the Applications Root Directory] Good style would be to use the user profile to store such data on WinNT/2k/XP. It can be found with the help of [TWAPI]'s get_user_account_info or get_shell_folder commands (the latter only if the program is running as that user). [MG] notes that on his Win XP SP2 computer, '''~''' and '''$env(HOME)''' are both his user-folder, which for him is ''C:/Documents and Settings/Griffiths''. So [[file join ~ "Application Data"]] is the place where many other (commerical) programs seem to store data. [EKB] Yes, I use "Application Data" as well. Here's my usual code: set USERDIR [file dirname $argv0] if {$tcl_platform(os) == "Windows NT"} { if {[info exists env(USERPROFILE)]} {set USERDIR $env(USERPROFILE)} } if {$tcl_platform(os) == "Windows 95"} { if {[info exists env(windir)] && [info exists env(USERNAME)]} { set USERDIR [file join $env(windir) Profiles $env(USERNAME)] } } set USERDIR [file join $USERDIR "Application Data" "Your App Name"] set USERPREFS [file join $USERDIR prefs.tcl] This defaults to the application directory in case none of the environment variables work. Then on either NT or Win95 it finds the user's directory. (Hm... and I don't use HOME... maybe that's better?) Then I append: [file join $USERDIR "Application Data" "Your App Name"] It's polite to put your config files not only in "Application Data" but also in a subfolder just for your software. (The application name, or your company name, etc.) '''Macintosh''' This might depend on the version of the [Mac OS] you have. Newer Tcl versions are [Mac OS X] only, but older applications may be for [MacOS Classic]. I don't konw about these, because I don't have a Mac. Can someone fill the information here? [Zarutian]: I think you use '''[[file join $env(HOME) Library ]]''' but I am not sure. [BR]: [Mac OS X] is a Unix. You can just use the Unix conventions. You can also use ~/Library/Preferences/''appname''.tcl, that is a convention that comes from the NextSTEP inheritance of [Mac OS X]. [slebetman] On Mac OS, you should use /Preference/''appname'' to store preferences. If there are multiple preferences then do what Adobe does: /Preference/''appname_feature''. The Preference folder was not only inherited from NeXT but from the old MacOS. Also note that the application should create preference file with default preferences if one is not already there. It is a common Mac debugging technique to delete corrupted preference files for misbehaving programs. Mac users will expect this. I think this is also a nice behavior for other platforms. [BR]: I don't have a folder "/Preference" on my 10.3 system. I have "/Library/Preferences" but that is of course is a global folder. It is a bad place to put user-specific preferences by definition. Mac OS Classic was essentially single-user, while Mac OS X is a multi-user system, so there is a good reason to change to a user-specific directory. Of course if you want to have global defaults or settings, "/Library/Preferences" is a possibility. The directory might be write-protected on a secured system, so you might need admin authorization to write there. An application should IMO only create a preference file if any option has been set to a non-default value. And of course an application should keep generated files (stuff that is generated from UI dialogs) separate from user-written files. Tcl was started as a language for configuration files. For me, having the ability to tweak an application with handwritten code in a configuration file is still a very strong point of the language. [anoved]: The conventional Mac OS X preferences folder location is ~/Library/Preferences, where ~ represents the user's home folder. Supplemental files (resources needed by but external to the application, not user-created documents) may be stored in ~/Library/Application Support/''appname''. Apple provides some commentary and canonical guidelines for software installation at [http://developer.apple.com/tools/installerpolicy.html]; the ''Which Should You Use?'' section provides a good overview. For what it's worth, the ''defaults'' command line program provides a simple mechanism for reading, writing, and manipulating the XML "property list" files commonly used to store preferences on Mac OS X. It is documented here: [http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/defaults.1.html] Incidentally, if you use ''defaults'' to write preferences to the same ''domain'' specified by the CFBundleIdentifier property of a standalone Wish shell's ''Info.plist'' file [http://tk-components.sourceforge.net/tk-bundle-tutorial/index.html], the preferences you write and those managed by the operating system (open/save dialog locations, ''etc.'') will be collected in a single preferences file. Of course, property name collisions may be possible in this case. ---- '''Storing data in the executable files''' For the popular and wonderful approach of storing the configuration data in the executable itself using [starkit]s and [starpack]s, you need to know this: only mechanisms designed for the usage of the virtual filesystem that make starkits/starpacks can be used. So you can use plain files that are handled by Tcl's core commands ([open], [read], [gets], and so on) and files that build upon the [vfs]. You can not use extensions like [SQLite], which is not vfs-aware. ''Starkit'' You need to make the starkit writable, if the data stored inside it must be changeable. This is done when the [sdx] command builds the starkit. Note that it currently is not possible to access a [metakit] db residing inside a starkit directory [http://groups-beta.google.com/group/comp.lang.tcl/browse_frm/thread/7446befc19ad75c5?lr=&rnum=3&prev=/groups%3Fq%3Dstarkit%2Bmetakit%2Bmk4vfs%26hl%3Dde%26lr%3D%26selm%3Dc7ar6q%25241q9tp%25241%2540ID-102549.news.uni-berlin.de%26rnum%3D3]. So to have a metakit db in a starkit/starpack, the only way is to use the metakit db, which is the kit/pack itself. A starkit is a metakit db with a view named "dirs". You can just create new views as you like and use them along with the "dirs" view. Like this (taken from the [Book Practical Programming in Tcl and Tk, Fourth Edition]): set db [lindex [vfs::filesystem info $starkit::topdir] 1] mk::view layout $db.myView {what you need} ''Starpack'' It is not possible to change the contents of a starpack from inside it. This is a limitation of the operating system as it does not allow changes to the executable file while being executed. So you need to do that from outside the starpack, i.e. with another program. You can, of course, when the starpack is running, make a copy of yourself, modify that copy, and then delete the original somehow. ---- [Category Deployment] | [Category Application] | [Category File]