[squeak-dev] User config directories (was: Merge Request: autoEncloseBeforeSpace.cs)

Jakob Reschke jakres+squeak at gmail.com
Wed Dec 29 13:40:44 UTC 2021


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


More information about the Squeak-dev mailing list