Hi Jakob,

Yes, I meant it as a fallback indeed. I use a simple setup:

D:\Squeak\Squeak_image_subdirectory_1\
D:\Squeak\Squeak_image_subdirectory_2\
etc.
So keeping prefs in D:\Squeak would work perfectly for me when a freshly downloaded image folder arrives in
D:\Squeak\Squeak_image_subdirectory_3\

Of course it might not even work if all images were in one directory or if they were in root dirctory :)

And how about to place a forwarding information in the parent directory where to find the prefs directory? (if nothing more elegant is available)?

Thanks,

~~~
^[^    Jaromir

Sent from Squeak Inbox Talk

On 2021-12-30T12:37:45+01:00, jakres+squeak at gmail.com wrote:

> 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
> >
> >
> >
> >
> 
>