I am trying to figure my proper environment Preferences. I'm grateful for your suggestions. Here's my list so far...
enable <Update from server at startup> enable <Open Tools Attached to Mouse Cursor> enable <Use colorful windows> enable <Click on label to edit> enable <Extra debugger buttons> disable <Use Soft Drop Shadow>
-- ••• rabbit ❤️🔥🐰
Hi rabbit,
Here are the preferences that I tend to change from the defaults:
enable <Use colorful windows> enable <Mouse over for keyboard focus> disable <Scroll bars without arrow butttons> disable <Scroll bars without menu button> disable <Scroll bars narrow> disable <Windows raise on any click> (though I sometimes change my mind about this) enable <Windows' contents are always active> enable <Open Tools Attached to Mouse Cursor> enable <Reuse windows>
I prefer the soft window shadows, and not updating at startup. The scrollbar settings I make for the occasion that I use a graphics tablet with a pen instead of the mouse. I also have the extra debugger buttons on at the moment because it is sometimes more convenient with the pen.
Kind regards, Jakob
Am Sa., 12. Aug. 2023 um 15:24 Uhr schrieb rabbit <rabbit@callistohouse.org
:
I am trying to figure my proper environment Preferences. I'm grateful for your suggestions. Here's my list so far...
enable <Update from server at startup> enable <Open Tools Attached to Mouse Cursor> enable <Use colorful windows> enable <Click on label to edit> enable <Extra debugger buttons> disable <Use Soft Drop Shadow>
-- ••• rabbit ❤️🔥🐰
Sweet! I do not use a tablet, but I will definitely check out your suggestions.
Thanks, Jakob! - rabbit
On 8/13/23 04:40, Jakob Reschke wrote:
Hi rabbit,
Here are the preferences that I tend to change from the defaults:
enable <Use colorful windows> enable <Mouse over for keyboard focus> disable <Scroll bars without arrow butttons> disable <Scroll bars without menu button> disable <Scroll bars narrow> disable <Windows raise on any click> (though I sometimes change my mind about this) enable <Windows' contents are always active> enable <Open Tools Attached to Mouse Cursor> enable <Reuse windows>
I prefer the soft window shadows, and not updating at startup. The scrollbar settings I make for the occasion that I use a graphics tablet with a pen instead of the mouse. I also have the extra debugger buttons on at the moment because it is sometimes more convenient with the pen.
Kind regards, Jakob
Am Sa., 12. Aug. 2023 um 15:24 Uhr schrieb rabbit rabbit@callistohouse.org:
I am trying to figure my proper environment Preferences. I'm grateful for your suggestions. Here's my list so far...
enable <Update from server at startup> enable <Open Tools Attached to Mouse Cursor> enable <Use colorful windows> enable <Click on label to edit> enable <Extra debugger buttons> disable <Use Soft Drop Shadow>
-- ••• rabbit ❤️🔥🐰
-- ••• rabbit ❤️🔥🐰
I think it would be cool and welcoming to have a standard set of saved preferences for various environments. Perhaps ooffer them in a drop selector in the Preferences window? I dunno. I'm just an idea man. Your's is for Tablet environments, Jakob. I am immer curious about Squeak on my iPhone, once I replace the batt'ry and get it running again. Sigh.
I'm sad. So many folks have no clue about creating in Squeak. They don't realize our joie de vivre in our pursuits. Do they not see the endurance? How many decades now? Still blue book. Hah!
We will prevail. - rabbit
On 8/13/23 04:40, Jakob Reschke wrote:
Hi rabbit,
Here are the preferences that I tend to change from the defaults:
enable <Use colorful windows> enable <Mouse over for keyboard focus> disable <Scroll bars without arrow butttons> disable <Scroll bars without menu button> disable <Scroll bars narrow> disable <Windows raise on any click> (though I sometimes change my mind about this) enable <Windows' contents are always active> enable <Open Tools Attached to Mouse Cursor> enable <Reuse windows>
I prefer the soft window shadows, and not updating at startup. The scrollbar settings I make for the occasion that I use a graphics tablet with a pen instead of the mouse. I also have the extra debugger buttons on at the moment because it is sometimes more convenient with the pen.
Kind regards, Jakob
Am Sa., 12. Aug. 2023 um 15:24 Uhr schrieb rabbit rabbit@callistohouse.org:
I am trying to figure my proper environment Preferences. I'm grateful for your suggestions. Here's my list so far...
enable <Update from server at startup> enable <Open Tools Attached to Mouse Cursor> enable <Use colorful windows> enable <Click on label to edit> enable <Extra debugger buttons> disable <Use Soft Drop Shadow>
-- ••• rabbit ❤️🔥🐰
-- ••• rabbit ❤️🔥🐰
Am So., 13. Aug. 2023 um 13:29 Uhr schrieb rabbit <rabbit@callistohouse.org
:
I think it would be cool and welcoming to have a standard set of saved preferences for various environments. Perhaps ooffer them in a drop selector in the Preferences window?
Have you considered the "save", "load", and "save to disk" and "load from disk" buttons in the Preference browser?
Yes, I use them. I was thinking in terms of offering presets.
Primarily I have a base.image setup with GitBrowser, VMMaker, but without Crypto. I regularly fork a remote-promises.image (crypto.image for two-stepping) and rebuilt Crypto from scratch; run tests.
On 8/13/23 08:19, Jakob Reschke wrote:
Am So., 13. Aug. 2023 um 13:29 Uhr schrieb rabbit rabbit@callistohouse.org:
I think it would be cool and welcoming to have a standard set of saved preferences for various environments. Perhaps ooffer them in a drop selector in the Preferences window?
Have you considered the "save", "load", and "save to disk" and "load from disk" buttons in the Preference browser?
-- ••• rabbit ❤️🔥🐰
My personal preferences are pretty small (ordered by descending priority):
enable <Focus follows mouse> enable <Windows always active> enable <Attach tools to mouse> enable <Use colorful windows> disable <File-out workspace contents on accept>
Best, Christoph
--- Sent from Squeak Inbox Talk
On 2023-08-13T10:40:27+02:00, jakres+squeak@gmail.com wrote:
Hi rabbit,
Here are the preferences that I tend to change from the defaults:
enable <Use colorful windows> enable <Mouse over for keyboard focus> disable <Scroll bars without arrow butttons> disable <Scroll bars without menu button> disable <Scroll bars narrow> disable <Windows raise on any click> (though I sometimes change my mind about this) enable <Windows' contents are always active> enable <Open Tools Attached to Mouse Cursor> enable <Reuse windows>
I prefer the soft window shadows, and not updating at startup. The scrollbar settings I make for the occasion that I use a graphics tablet with a pen instead of the mouse. I also have the extra debugger buttons on at the moment because it is sometimes more convenient with the pen.
Kind regards, Jakob
Am Sa., 12. Aug. 2023 um 15:24 Uhr schrieb rabbit <rabbit(a)callistohouse.org
:
I am trying to figure my proper environment Preferences. I'm grateful for your suggestions. Here's my list so far...
enable <Update from server at startup> enable <Open Tools Attached to Mouse Cursor> enable <Use colorful windows> enable <Click on label to edit> enable <Extra debugger buttons> disable <Use Soft Drop Shadow>
-- ••• rabbit ❤️🔥🐰
And of course: enable <Shout styling in Workspace>
--- Sent from Squeak Inbox Talk
On 2023-08-17T09:29:10+02:00, christoph.thiede@student.hpi.uni-potsdam.de wrote:
My personal preferences are pretty small (ordered by descending priority):
enable <Focus follows mouse> enable <Windows always active> enable <Attach tools to mouse> enable <Use colorful windows> disable <File-out workspace contents on accept>
Best, Christoph
Sent from Squeak Inbox Talk
On 2023-08-13T10:40:27+02:00, jakres+squeak(a)gmail.com wrote:
Hi rabbit,
Here are the preferences that I tend to change from the defaults:
enable <Use colorful windows> enable <Mouse over for keyboard focus> disable <Scroll bars without arrow butttons> disable <Scroll bars without menu button> disable <Scroll bars narrow> disable <Windows raise on any click> (though I sometimes change my mind about this) enable <Windows' contents are always active> enable <Open Tools Attached to Mouse Cursor> enable <Reuse windows>
I prefer the soft window shadows, and not updating at startup. The scrollbar settings I make for the occasion that I use a graphics tablet with a pen instead of the mouse. I also have the extra debugger buttons on at the moment because it is sometimes more convenient with the pen.
Kind regards, Jakob
Am Sa., 12. Aug. 2023 um 15:24 Uhr schrieb rabbit <rabbit(a)callistohouse.org
:
I am trying to figure my proper environment Preferences. I'm grateful for your suggestions. Here's my list so far...
enable <Update from server at startup> enable <Open Tools Attached to Mouse Cursor> enable <Use colorful windows> enable <Click on label to edit> enable <Extra debugger buttons> disable <Use Soft Drop Shadow>
-- ••• rabbit ❤️🔥🐰
Obviously, turn off swap mouse buttons - because only savages would accept the menu button being on the right of the halo button.
And turn on legacy keyboard shortcuts because I have 40 years of muscle memory to cope with. So turn off auto enclose.
We don't actually have any easy way of listing preferences we've changed, do we?
On 2023-08-17, at 5:17 AM, christoph.thiede@student.hpi.uni-potsdam.de wrote:
And of course: enable <Shout styling in Workspace>
Sent from Squeak Inbox Talk
On 2023-08-17T09:29:10+02:00, christoph.thiede@student.hpi.uni-potsdam.de wrote:
My personal preferences are pretty small (ordered by descending priority):
enable <Focus follows mouse> enable <Windows always active> enable <Attach tools to mouse> enable <Use colorful windows> disable <File-out workspace contents on accept>
Best, Christoph
Sent from Squeak Inbox Talk
On 2023-08-13T10:40:27+02:00, jakres+squeak(a)gmail.com wrote:
Hi rabbit,
Here are the preferences that I tend to change from the defaults:
enable <Use colorful windows> enable <Mouse over for keyboard focus> disable <Scroll bars without arrow butttons> disable <Scroll bars without menu button> disable <Scroll bars narrow> disable <Windows raise on any click> (though I sometimes change my mind about this) enable <Windows' contents are always active> enable <Open Tools Attached to Mouse Cursor> enable <Reuse windows>
I prefer the soft window shadows, and not updating at startup. The scrollbar settings I make for the occasion that I use a graphics tablet with a pen instead of the mouse. I also have the extra debugger buttons on at the moment because it is sometimes more convenient with the pen.
Kind regards, Jakob
Am Sa., 12. Aug. 2023 um 15:24 Uhr schrieb rabbit <rabbit(a)callistohouse.org
:
I am trying to figure my proper environment Preferences. I'm grateful for your suggestions. Here's my list so far...
enable <Update from server at startup> enable <Open Tools Attached to Mouse Cursor> enable <Use colorful windows> enable <Click on label to edit> enable <Extra debugger buttons> disable <Use Soft Drop Shadow>
-- ••• rabbit ❤️🔥🐰
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Immune from any serious head injury.
Tim Rowledge tim@rowledge.org schrieb am Do., 17. Aug. 2023, 19:19:
We don't actually have any easy way of listing preferences we've changed, do we?
At least none known to me. If the export files happen to be text, I guess one could have diffed them. But I compared checkboxes between a fresh image and a working image...
On 2023-08-17, at 11:15 AM, Jakob Reschke jakres+squeak@gmail.com wrote:
Tim Rowledge tim@rowledge.org schrieb am Do., 17. Aug. 2023, 19:19:
We don't actually have any easy way of listing preferences we've changed, do we?
At least none known to me. If the export files happen to be text, I guess one could have diffed them. But I compared checkboxes between a fresh image and a working image...
We really should do better than that.
A trivial doit to read a prefs file - |fName stream | fName := '/home/pi/Documents/Squeak/my.prefs'. stream := ReferenceStream fileNamed: fName. params := stream next. dict := stream next. stream close. {params. dict}
The content is a bit baroque. What exactly is PersonalDictionaryOfPreferences and why is it ignored when loading prefs? Since it is removed on load, how come my prefs file even has such an entry? (OK, looks likely that my prefs file is so old it predates that being removed?)
We have a dictionary of 'parameters' that is a list of named objects that are used as preferred things - fonts, mostly. Then a dictionary of actual preference objects. It almost seems as if a project wasn't actually completed to make Preferences for everything?
This all seems a bit broken to me so perhaps I'm missing something here. If one sets some preferences and uses the plain 'save', those choices (actually the entire set of items in the preferencesDictionary, so not the font etc choices) are copied to the PersonalDictionaryOfPreferences in the parameters dictionary. You can then use the 'default' button, or make more choices and then 'load' to return to your previous set. *However* if you 'save to disk' - which seems like a pretty sensible thing to do - then loading that file will *not* include your personal choices set.
Pretty sure there are more helpful possibilities.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Non curo. Si metrum non habet, non est poema = I don't care. If it doesn't rhyme, it isn't a poem.
It would be cool to store the personal preferences in a method like ReleaseBuilder>>setPreferences so we could version it with Monticello.
We could have a class like PersonalPreferences. All I had to do to sync preferences to different computers would be to load PersonalPreferences-kfr.1.mcz
Best, Karl
On Thu, Aug 17, 2023 at 11:31 PM Tim Rowledge tim@rowledge.org wrote:
On 2023-08-17, at 11:15 AM, Jakob Reschke jakres+squeak@gmail.com
wrote:
Tim Rowledge tim@rowledge.org schrieb am Do., 17. Aug. 2023, 19:19:
We don't actually have any easy way of listing preferences we've
changed, do we?
At least none known to me. If the export files happen to be text, I
guess one could have diffed them. But I compared checkboxes between a fresh image and a working image...
We really should do better than that.
A trivial doit to read a prefs file - |fName stream | fName := '/home/pi/Documents/Squeak/my.prefs'. stream := ReferenceStream fileNamed: fName. params := stream next. dict := stream next. stream close. {params. dict}
The content is a bit baroque. What exactly is PersonalDictionaryOfPreferences and why is it ignored when loading prefs? Since it is removed on load, how come my prefs file even has such an entry? (OK, looks likely that my prefs file is so old it predates that being removed?)
We have a dictionary of 'parameters' that is a list of named objects that are used as preferred things - fonts, mostly. Then a dictionary of actual preference objects. It almost seems as if a project wasn't actually completed to make Preferences for everything?
This all seems a bit broken to me so perhaps I'm missing something here. If one sets some preferences and uses the plain 'save', those choices (actually the entire set of items in the preferencesDictionary, so not the font etc choices) are copied to the PersonalDictionaryOfPreferences in the parameters dictionary. You can then use the 'default' button, or make more choices and then 'load' to return to your previous set. *However* if you 'save to disk' - which seems like a pretty sensible thing to do - then loading that file will *not* include your personal choices set.
Pretty sure there are more helpful possibilities.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Non curo. Si metrum non habet, non est poema = I don't care. If it doesn't rhyme, it isn't a poem.
On 2023-08-18, at 2:54 AM, karl ramberg karlramberg@gmail.com wrote:
It would be cool to store the personal preferences in a method like ReleaseBuilder>>setPreferences so we could version it with Monticello.
We could have a class like PersonalPreferences. All I had to do to sync preferences to different computers would be to load PersonalPreferences-kfr.1.mcz
Ye-es, maaaybe? A parent class 'DefaultPreferences' that is all the defaults preferences (duh) and 'Preferences' that would be empty by default so all senders would pick up the defaults until something is changed. Saving your preferences to MC is an interesting idea; keep it local, keep it on a personal squeaksource, the public one... yeah, could be helpful
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Both.." said Pooh, as the guillotine came down
Am Fr., 18. Aug. 2023 um 11:54 Uhr schrieb karl ramberg < karlramberg@gmail.com>:
It would be cool to store the personal preferences in a method like ReleaseBuilder>>setPreferences so we could version it with Monticello.
While I see the practicality, it makes me sad to see everything turned into a nail so that we can reuse our hammer instead of looking for another tool or extending the hammer...
nails = Smalltalk methods in this case
We seem to have drifted away from this but I think it deserves more discussion.
Keeping preferences in methods in thus potentially in MC packages has some attraction because it immediately makes it trivial to share your preferences at various levels - personal, group, global - and of course the change detection in MC makes it easy to see what ... changed. So +quite a lot for usefulness, -a little for the 'everything is a nail' approach.
It's probably worth remembering that MC can store stuff other than methods, though so far as I know it can't do change detection on anything else.
We shouldn't forget that we also have an external preferences mechanism that has been sitting there for twenty years with minimal actual use; see ExternalSettings. I use that for a work related project and my MC login. I don't think it gets a lot of use otherwise. We could certainly beef it up. For example, make it able to search a bit more widely for the directory it reads from so one could have the same local, group, global storage hierarchy. Or actually improve the very simplistic format of the preference values, maybe using json?
I would suggest that we should only save preferences that are changed from the defaults, rather than the current 'save everything including several copies of some kitchen sinks I found lying around'.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The downside of being better than everyone else is that people tend to assume you're pretentious
Hi Tim --
I would suggest that we should only save preferences that are changed from the defaults, rather than the current 'save everything including several copies of some kitchen sinks I found lying around'.
When carrying over those saved preferences between Squeak releases, those original defaults might have changed. Thus, a complete export seems to make more sense... as it will be more robust?
Best, Marcel Am 01.09.2023 19:23:08 schrieb Tim Rowledge tim@rowledge.org: We seem to have drifted away from this but I think it deserves more discussion.
Keeping preferences in methods in thus potentially in MC packages has some attraction because it immediately makes it trivial to share your preferences at various levels - personal, group, global - and of course the change detection in MC makes it easy to see what ... changed. So +quite a lot for usefulness, -a little for the 'everything is a nail' approach.
It's probably worth remembering that MC can store stuff other than methods, though so far as I know it can't do change detection on anything else.
We shouldn't forget that we also have an external preferences mechanism that has been sitting there for twenty years with minimal actual use; see ExternalSettings. I use that for a work related project and my MC login. I don't think it gets a lot of use otherwise. We could certainly beef it up. For example, make it able to search a bit more widely for the directory it reads from so one could have the same local, group, global storage hierarchy. Or actually improve the very simplistic format of the preference values, maybe using json?
I would suggest that we should only save preferences that are changed from the defaults, rather than the current 'save everything including several copies of some kitchen sinks I found lying around'.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The downside of being better than everyone else is that people tend to assume you're pretentious
Save unchanged preferences with an additional flag so the user can decide how to merge changes in the Trunk on file-in?
--- Sent from Squeak Inbox Talk
On 2023-09-04T10:22:09+02:00, marcel.taeumel@hpi.de wrote:
Hi Tim --
I would suggest that we should only save preferences that are changed from the defaults, rather than the current 'save everything including several copies of some kitchen sinks I found lying around'.
When carrying over those saved preferences between Squeak releases, those original defaults might have changed. Thus, a complete export seems to make more sense... as it will be more robust?
Best, Marcel Am 01.09.2023 19:23:08 schrieb Tim Rowledge <tim(a)rowledge.org>: We seem to have drifted away from this but I think it deserves more discussion.
Keeping preferences in methods in thus potentially in MC packages has some attraction because it immediately makes it trivial to share your preferences at various levels - personal, group, global - and of course the change detection in MC makes it easy to see what ... changed. So +quite a lot for usefulness, -a little for the 'everything is a nail' approach.
It's probably worth remembering that MC can store stuff other than methods, though so far as I know it can't do change detection on anything else.
We shouldn't forget that we also have an external preferences mechanism that has been sitting there for twenty years with minimal actual use; see ExternalSettings. I use that for a work related project and my MC login. I don't think it gets a lot of use otherwise. We could certainly beef it up. For example, make it able to search a bit more widely for the directory it reads from so one could have the same local, group, global storage hierarchy. Or actually improve the very simplistic format of the preference values, maybe using json?
I would suggest that we should only save preferences that are changed from the defaults, rather than the current 'save everything including several copies of some kitchen sinks I found lying around'.
tim
tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim The downside of being better than everyone else is that people tend to assume you're pretentious
Please, keep it simple. As long as I have a way of loading my startup script, I can choose how to update my preferences.
Keeping all the preferences in a separate file doesn't seem more robust from the point of view of backwards compatibility. Setting preferences up different from the defaults, has the expected downside you have to be vigilant of breaking changes.
A segunda, 4/09/2023, 12:21, christoph.thiede@student.hpi.uni-potsdam.de escreveu:
Save unchanged preferences with an additional flag so the user can decide how to merge changes in the Trunk on file-in?
Sent from Squeak Inbox Talk
On 2023-09-04T10:22:09+02:00, marcel.taeumel@hpi.de wrote:
Hi Tim --
I would suggest that we should only save preferences that are changed
from the defaults, rather than the current 'save everything including several copies of some kitchen sinks I found lying around'.
When carrying over those saved preferences between Squeak releases,
those original defaults might have changed. Thus, a complete export seems to make more sense... as it will be more robust?
Best, Marcel Am 01.09.2023 19:23:08 schrieb Tim Rowledge <tim(a)rowledge.org>: We seem to have drifted away from this but I think it deserves more
discussion.
Keeping preferences in methods in thus potentially in MC packages has
some attraction because it immediately makes it trivial to share your preferences at various levels - personal, group, global - and of course the change detection in MC makes it easy to see what ... changed. So +quite a lot for usefulness, -a little for the 'everything is a nail' approach.
It's probably worth remembering that MC can store stuff other than
methods, though so far as I know it can't do change detection on anything else.
We shouldn't forget that we also have an external preferences mechanism
that has been sitting there for twenty years with minimal actual use; see ExternalSettings. I use that for a work related project and my MC login. I don't think it gets a lot of use otherwise. We could certainly beef it up. For example, make it able to search a bit more widely for the directory it reads from so one could have the same local, group, global storage hierarchy. Or actually improve the very simplistic format of the preference values, maybe using json?
I would suggest that we should only save preferences that are changed
from the defaults, rather than the current 'save everything including several copies of some kitchen sinks I found lying around'.
tim
tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim The downside of being better than everyone else is that people tend to
assume you're pretentious
Wait, I thought I was replying to a message sent to the Cuis mailing list. Never mind, ignore my previous message since I don't know enough about Squeak to share an opinion on setting it's preferences.
A segunda, 4/09/2023, 14:14, Ezequiel Birman ebirman77@gmail.com escreveu:
Please, keep it simple. As long as I have a way of loading my startup script, I can choose how to update my preferences.
Keeping all the preferences in a separate file doesn't seem more robust from the point of view of backwards compatibility. Setting preferences up different from the defaults, has the expected downside you have to be vigilant of breaking changes.
A segunda, 4/09/2023, 12:21, christoph.thiede@student.hpi.uni-potsdam.de escreveu:
Save unchanged preferences with an additional flag so the user can decide how to merge changes in the Trunk on file-in?
Sent from Squeak Inbox Talk
On 2023-09-04T10:22:09+02:00, marcel.taeumel@hpi.de wrote:
Hi Tim --
I would suggest that we should only save preferences that are changed
from the defaults, rather than the current 'save everything including several copies of some kitchen sinks I found lying around'.
When carrying over those saved preferences between Squeak releases,
those original defaults might have changed. Thus, a complete export seems to make more sense... as it will be more robust?
Best, Marcel Am 01.09.2023 19:23:08 schrieb Tim Rowledge <tim(a)rowledge.org>: We seem to have drifted away from this but I think it deserves more
discussion.
Keeping preferences in methods in thus potentially in MC packages has
some attraction because it immediately makes it trivial to share your preferences at various levels - personal, group, global - and of course the change detection in MC makes it easy to see what ... changed. So +quite a lot for usefulness, -a little for the 'everything is a nail' approach.
It's probably worth remembering that MC can store stuff other than
methods, though so far as I know it can't do change detection on anything else.
We shouldn't forget that we also have an external preferences mechanism
that has been sitting there for twenty years with minimal actual use; see ExternalSettings. I use that for a work related project and my MC login. I don't think it gets a lot of use otherwise. We could certainly beef it up. For example, make it able to search a bit more widely for the directory it reads from so one could have the same local, group, global storage hierarchy. Or actually improve the very simplistic format of the preference values, maybe using json?
I would suggest that we should only save preferences that are changed
from the defaults, rather than the current 'save everything including several copies of some kitchen sinks I found lying around'.
tim
tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim The downside of being better than everyone else is that people tend to
assume you're pretentious
On 2023-09-04, at 1:22 AM, Marcel Taeumel via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
I would suggest that we should only save preferences that are changed from the defaults, rather than the current 'save everything including several copies of some kitchen sinks I found lying around'.
When carrying over those saved preferences between Squeak releases, those original defaults might have changed. Thus, a complete export seems to make more sense... as it will be more robust?
Hmm. Well for that case I'd suggest a) save all those prefs b) tag ones changed by the user
Then when loading, compare and list a) the ones changed in-system b) the ones changed by the user
Offer a simple way to accept them to build a new set for that release/version.
I wonder how other systems handle this? If you have a file of settings in *nix-land it would typically just have the settings you change, I think. If the system gets updated to have different defaults I think you just have to work it out. Are there any interesting examples of doing thins stuff that people like?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ESBD: Erase System and Burn Documentation
Not exactly preferences, but in the server software that I take part in developing at work, the system configuration in several cases works like this: If there is a new setting, it displays that during a migration and asks for a value or whether to accept a default. If the default of a setting has changed, it displays that during a migration and asks which value to use from now on. Untouched settings are not prompted for again, only during the first installation there is a prompt for all settings.
Note that this is a terminal-based procedure, no GUI. A straight-forward translation into modal dialog boxes would certainly be annoying.
Am Di., 5. Sept. 2023 um 11:32 Uhr schrieb Tim Rowledge tim@rowledge.org:
On 2023-09-04, at 1:22 AM, Marcel Taeumel via Squeak-dev squeak-dev@lists.squeakfoundation.org wrote:
I would suggest that we should only save preferences that are changed from the defaults, rather than the current 'save everything including several copies of some kitchen sinks I found lying around'.
When carrying over those saved preferences between Squeak releases, those original defaults might have changed. Thus, a complete export seems to make more sense... as it will be more robust?
Hmm. Well for that case I'd suggest a) save all those prefs b) tag ones changed by the user
Then when loading, compare and list a) the ones changed in-system b) the ones changed by the user
Offer a simple way to accept them to build a new set for that release/version.
I wonder how other systems handle this? If you have a file of settings in *nix-land it would typically just have the settings you change, I think. If the system gets updated to have different defaults I think you just have to work it out. Are there any interesting examples of doing thins stuff that people like?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ESBD: Erase System and Burn Documentation
squeak-dev@lists.squeakfoundation.org