Hi Tim,

I have looked into it and it stores the "prefs" directory in the
FileDirectory default, or in SecurityManager default
secureUserDirectory if Preferences startInUntrustedDirectory is
enabled. In my image, both locations depend on the directory of the
running image, so it would not satisfy my requirements as is.

Also the mechanism seems to load preferences on every image startup,
which is not strictly necessary for those preferences we have been
discussing about.

Nevertheless, of course it is good that code for the reading and
writing of preferences is already there. Since there are also the
buttons to export and import preferences manually, I expected that I
would not have to write this from scratch.

Kind regards,
Jakob

Am Mi., 29. Dez. 2021 um 19:25 Uhr schrieb tim Rowledge <tim at rowledge.org>:
>
> We already have some mechanism for this, though I wouldn't claim it is particularly magnificent. See ExternalSettings class>>#preferenceDirectory etc. I use it for work/server preferences, with the file format described being OK but maybe better if we used JSON instead?
>
> The location of the directory can certainly be a pain, but I've already ranted about the location of the sources file and this is a similar case. But let's not get involved in anything to do with the Windows registry; we all know that leads to weakening of the walls between us and the Dungeon Dimensions.
>
>
> > On 2021-12-29, at 5:40 AM, Jakob Reschke <jakres+squeak at gmail.com> wrote:
> >
> > Hi all,
> >
> > Am Do., 23. Dez. 2021 um 13:39 Uhr schrieb Jakob Reschke
> > <jakres+squeak at gmail.com>:
> >>
> >> [...] we should write default
> >> preferences to ~/.config/squeak-default-preferences.dat or so when the
> >> wizard is finished for the first time [...]
> >>
> >
> > I just "quickly" wanted to try this out the other day, but it seems
> > there is no clean way to determine the home directory from a plain
> > Trunk image without third party packages. Sigh!
> >
> > The context: I would like to store some contested preferences
> > externally in a well-known, stable location, so that when you start a
> > new image, these preferences are already pre-set in the preference
> > wizard with your choices from the last time you completed the wizard
> > in a different image. For example, auto-enclose, enclose selection,
> > colorful windows, attach tools to mouse cursor, ... That would allow
> > us to change the default preferences for first-time users without
> > bothering our veterans with behavior to which they are not accustomed,
> > and which they first have to turn off in each new image.
> >
> > SecurityManager>>#primUntrustedUserDirectory comes closest to the
> > user's home directory, but on Unix you would have to go up three
> > directories and on Windows just two. On its own, the SecurityManager
> > default untrustedUserDirectory does not really adhere to the platform
> > rules for storing preferences (at least not on Windows). Also it may
> > be incorrect to use the SecurityManager protocol for this purpose, I
> > have no experience with it.
> >
> > Before I delve too much into getting the home directory, what I really want is
> > - to access a place where some preferences values could be stored
> > - without user input (i. e. they should not have to choose a file or
> > directory first)
> > - independent of the location of the current image file.
> > - The place must be writable.
> > - It must work eventually in a fresh image without extra plugins or
> > packages loaded.
> >
> > Ideally the place would adhere to the rules and conventions of the
> > platform. So if it is a directory to store configuration files:
> > - On Windows this could be %APPDATA% (e. g. C:\Users\Jakob\AppData\Roaming)
> > - On Linux this could be $XDG_CONFIG_HOME, with a fallback of $HOME/.config [1]
> > - On the Mac I don't really know, but according to [2]
> > $HOME/Library/Preferences might be it.
> > (In all the cases above, a Squeak subdirectory should be created, of course.)
> > - SqueakJS in the web browser could arbitrarily define a simulated
> > directory in the local storage.
> > - As a last resort, FileDrectory default could be used, although in
> > general it does not fulfill the requirements (e. g. being indepent of
> > the image location).
> >
> > I suppose it would make sense to implement the lookup of the path in
> > the VM (or a plugin that is included by default). Otherwise, the
> > minimum requirement would be that getenv() functionality is available
> > without installing OSProcess first. It looks like Pharo has done
> > something like that: `Smalltalk os environment` answers a dictionary
> > of environment variables and this is used in FileSystem to retrieve
> > preferences and home directories.
> >
> > Alternatively, we could outsource this to the VM completely by
> > specifying a key-value store protocol of primitives for simple
> > preferences. Then the VM could even implement it using
> > platform-specific API (e. g. the Windows Registry, Mac NSUserDefaults
> > [2]). But I have the feeling that this may not be the most popular
> > choice in the community. ;-)
> >
> > What are your thoughts about the matter?
> >
> > [1] https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html
> > [2] https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/UserDefaults/AboutPreferenceDomains/AboutPreferenceDomains.html
> >
> > Kind regards,
> > Jakob
> >
> >
>
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Strange OpCodes: DSO: Do Something or Other
>
>
>