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

Jakob Reschke jakres+squeak at gmail.com
Thu Dec 30 11:37:45 UTC 2021


Hi Jaromir,

Using the parent of the image directory may be an improvement, but not
an overall solution. I have at least two different locations where I
store subdirectories with images (one cloud-synchronized directory and
one that is not synchronized). But my preferences are the same in both
locations, of course.

Also it might be awkward or not even writable: if you keep your images
in /home/yourname or C:\Squeak without a subdirectory per image, for
example, you would be trying to use a /home/squeak or /home/prefs or
C:\prefs directory (if it goes back into C:\Squeak that might actually
be nice, but it is just a special case). In such cases it would indeed
be better to use the current directory, but a fresh image will not
know how you organize your image files.

I will consider it as an acceptable fallback if we cannot get anything
going with the platform's directories.

Kind regards,
Jakob

Am Mi., 29. Dez. 2021 um 15:49 Uhr schrieb Jaromir Matas <mail at jaromir.net>:
>
> Hi Jakob,
>
>
>
> I’d love to save my preferences once and forget about them!
>
>
>
> Sorry if this sounds too naïve but how about a parent folder of the image folder? In my case I store my all image folders under a Squeak folder somewhere… The general lookup could try more locations, the parent directory being one of them.
>
>
>
> Thanks, I wish you succeed with this ;)
>
>
>
> Jaromir
>
>
>
> From: Jakob Reschke
> Sent: Wednesday, December 29, 2021 14:41
> To: The general-purpose Squeak developers list
> Subject: [squeak-dev] User config directories (was: Merge Request: autoEncloseBeforeSpace.cs)
>
>
>
> 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