tim Rowledge uploaded a new version of PreferenceBrowser to project The Inbox:
http://source.squeak.org/inbox/PreferenceBrowser-tpr.98.mcz ==================== Summary ==================== Name: PreferenceBrowser-tpr.98 Author: tpr Time: 24 December 2019, 11:56:24.390074 am UUID: 686fff60-db2c-4f95-a3f4-486b0e3c68db Ancestors: PreferenceBrowser-mt.97 Possible change to allow users to save preferences to other than the default directory and with names other than 'my.prefs'. =============== Diff against PreferenceBrowser-mt.97 =============== Item was changed: ----- Method: PreferenceBrowser>>loadFromDiskSelected (in category 'preferences search') ----- + loadFromDiskSelected + "Ask the user to select a saved preference file to load. If none is chosen then do nothing. If there is an error during the loading inform the user; this may leave the preferences in a messy state as we aren't tracking where the erro ocurred" + (Project uiManager chooseFileMatching: '*.prefs' label: 'Select a preferences file to load') + ifNotNil: [:fname | Cursor wait + showWhile: [[preferences loadPreferencesFrom: fname] + on: Error + do: [:ex | self inform: 'there was an error restoring the preferences from ' , fname]]] ! - loadFromDiskSelected - - (Project uiManager - confirm: 'Do you really want to restore your\personal preferences from disk?\\The file ''my.prefs'' will be loaded.' translated withCRs - title: 'Restore Preferences from Disk') ifFalse: [^ self]. - - preferences restorePreferencesFromDisk! Item was changed: ----- Method: PreferenceBrowser>>saveToDiskSelected (in category 'preferences search') ----- + saveToDiskSelected + "save the current preferences settings to file; the default is 'my.prefs' in the current default directory. Allow the user to choose where they should go" + (Project uiManager saveFilenameRequest: 'Save prefernces to file' initialAnswer: 'my.prefs') + ifNotNil: [:fname | Cursor wait + showWhile: [[preferences storePreferencesIn: fname] + on: Error + do: [:ex | self inform: 'there was an error storing your preferences to disk']]]! - saveToDiskSelected - - (Project uiManager - confirm: 'Do you really want to overwrite your\personal preferences on disk?\\The file ''my.prefs'' will be updated.' translated withCRs - title: 'Save Preferences to Disk') ifFalse: [^ self]. - - preferences storePreferencesToDisk! |
Hi Tim, looks good. Would you fix the typo and add #translated calls? 'Select a preferences file to load' translated 'There was an error restoring the preferences from file {1}.' translated format: {fname} Best, Marcel
|
In reply to this post by commits-2
Hi Tim, Why? Preferences are specific to users. An individual user concerned enough to want their own preferences is going to want their own directory to work out of. As with the new Image "Save as...", on machines with magnetic HD's and lots of directories, having to scan the directory just to present this unwanted UI immensely slows down and complicates the normal use-case for that. Even more frustrating is that it encourages a bad habits, manual configuration. Please add a new button to render and "Select..." your desired preference file instead. That way, the existing buttons can maintain the quick-access we've enjoyed all these years. Best, Chris On Tue, Dec 24, 2019 at 1:56 PM <[hidden email]> wrote: tim Rowledge uploaded a new version of PreferenceBrowser to project The Inbox: |
On Thu, Dec 26, 2019 at 05:58:28PM -0600, Chris Muller wrote:
> Hi Tim, > > Why? Preferences are specific to users. An individual user concerned > enough to want their own preferences is going to want their own directory > to work out of. An individual user may work with more than one directory. For example, I have a ./squeak/squeak5.2 directory that holds stuff I have been doing since since the 5.2 release, and a ./squeak/squeak3.8 folder for things I was doing back in that era, plus a folder for VM work, and so forth. > > As with the new Image "Save as...", on machines with magnetic HD's and lots > of directories, having to scan the directory just to present this unwanted > UI immensely slows down and complicates the normal use-case for that. Even > more frustrating is that it encourages a bad habits, manual configuration. > > Please add a new button to render and "Select..." your desired preference > file instead. That way, the existing buttons can maintain the quick-access > we've enjoyed all these years. Saving preferences to disk is (for me) a rare operation, I find Tim's enhancement to be helpful and easy to understand. It also saves time for me, because I don't have to stop and think about out where the file is being saved. Dave > > Best, > Chris > > On Tue, Dec 24, 2019 at 1:56 PM <[hidden email]> wrote: > > > tim Rowledge uploaded a new version of PreferenceBrowser to project The > > Inbox: > > http://source.squeak.org/inbox/PreferenceBrowser-tpr.98.mcz > > > > ==================== Summary ==================== > > > > Name: PreferenceBrowser-tpr.98 > > Author: tpr > > Time: 24 December 2019, 11:56:24.390074 am > > UUID: 686fff60-db2c-4f95-a3f4-486b0e3c68db > > Ancestors: PreferenceBrowser-mt.97 > > > > Possible change to allow users to save preferences to other than the > > default directory and with names other than 'my.prefs'. > > > > =============== Diff against PreferenceBrowser-mt.97 =============== > > > > Item was changed: > > ----- Method: PreferenceBrowser>>loadFromDiskSelected (in category > > 'preferences search') ----- > > + loadFromDiskSelected > > + "Ask the user to select a saved preference file to load. If none is > > chosen then do nothing. If there is an error during the loading inform the > > user; this may leave the preferences in a messy state as we aren't tracking > > where the erro ocurred" > > + (Project uiManager chooseFileMatching: '*.prefs' label: 'Select a > > preferences file to load') > > + ifNotNil: [:fname | Cursor wait > > + showWhile: [[preferences > > loadPreferencesFrom: fname] > > + on: Error > > + do: [:ex | self inform: > > 'there was an error restoring the preferences from ' , fname]]] ! > > - loadFromDiskSelected > > - > > - (Project uiManager > > - confirm: 'Do you really want to restore your\personal > > preferences from disk?\\The file ''my.prefs'' will be loaded.' translated > > withCRs > > - title: 'Restore Preferences from Disk') ifFalse: [^ self]. > > - > > - preferences restorePreferencesFromDisk! > > > > Item was changed: > > ----- Method: PreferenceBrowser>>saveToDiskSelected (in category > > 'preferences search') ----- > > + saveToDiskSelected > > + "save the current preferences settings to file; the default is > > 'my.prefs' in the current default directory. Allow the user to choose where > > they should go" > > + (Project uiManager saveFilenameRequest: 'Save prefernces to file' > > initialAnswer: 'my.prefs') > > + ifNotNil: [:fname | Cursor wait > > + showWhile: [[preferences > > storePreferencesIn: fname] > > + on: Error > > + do: [:ex | self inform: > > 'there was an error storing your preferences to disk']]]! > > - saveToDiskSelected > > - > > - (Project uiManager > > - confirm: 'Do you really want to overwrite your\personal > > preferences on disk?\\The file ''my.prefs'' will be updated.' translated > > withCRs > > - title: 'Save Preferences to Disk') ifFalse: [^ self]. > > - > > - preferences storePreferencesToDisk! > > > > > > > |
> On 2019-12-27, at 7:44 AM, David T. Lewis <[hidden email]> wrote: > > On Thu, Dec 26, 2019 at 05:58:28PM -0600, Chris Muller wrote: >> Hi Tim, >> >> Why? Preferences are specific to users. An individual user concerned >> enough to want their own preferences is going to want their own directory >> to work out of. > > An individual user may work with more than one directory. For example, I > have a ./squeak/squeak5.2 directory that holds stuff I have been doing > since since the 5.2 release, and a ./squeak/squeak3.8 folder for things > I was doing back in that era, plus a folder for VM work, and so forth. And may well have many images in a single directory, making many-to-many the case. I do quite like the suggestion to store individual preferences via monticello instead of explicitly in a file. I think the actual preferences mechanism might need some (long over due) changes to work well that way. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Fractured Idiom:- ICH LIEBE RICH - I'm really crazy about having dough |
Am Fr., 27. Dez. 2019 um 20:47 Uhr schrieb tim Rowledge <[hidden email]>:
If only Monticello could track things other than code... Squot can track and store other objects (in Git in files), but not reliably as of now, that's why I didn't announce it officially yet. Hence there are also no commands in the Git Browser to invoke this feature. |
On Dec 29, 2019, at 6:49 AM, Jakob Reschke <[hidden email]> wrote:
+1000. Whenever I talk with Colin Putney about this he wants to radically reimplement. I just want an incremental improvement towards versioning files. One issue is that while the container is ideal for saving files (an mcz is a zip file), a package is not its container. I suppose that if we evolved PackageInfo to include an optional directory (just one to start with, but make it a one element sequence for subsequent extensibility) and file manifest/patterns for the files therein, it would be a step in the right direction, one that would require us to improve the file dialog to allow picking directories and files to be included. But a commit diff for files and directories is a big job. I don’t have time to participate but I’d love to see this. However, I don’t want to see Monticello negatively impacted. Bert, how does the suggestion make you feel? Does it sit right in your gut or raise alarm bells? |
Am So., 29. Dez. 2019 um 16:11 Uhr schrieb Eliot Miranda <[hidden email]>:
Another thing I did differently in Squot than in Monticello is to not make packages the containers of everything and shapers of versions. Rather I treat a package as a package of code that can be tracked, among other objects. So you add a package to a working copy, rather than creating a working copy for each package. |
In reply to this post by Jakob Reschke
> On 2019-12-29, at 6:49 AM, Jakob Reschke <[hidden email]> wrote: > > Am Fr., 27. Dez. 2019 um 20:47 Uhr schrieb tim Rowledge <[hidden email]>: > > I do quite like the suggestion to store individual preferences via monticello instead of explicitly in a file. I think the actual preferences mechanism might need some (long over due) changes to work well that way. > > If only Monticello could track things other than code.. Well I'm sure there must be at least a dozen ways to work with that. - noting that many preferences are already code, simply make the preferences tool change that code and have a package for them. I think there are also pragma based preferences I've seen somewhere? - passivate the dictionary of current preference values, create a suitable method to evaluate it and save in a package - as above but put a literal in the preamble or postscript of an otherwise (probably) empty package - modify MC to track non-code stuff ok, so maybe not a dozen. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim If it was easy, the hardware people would take care of it. |
Free forum by Nabble | Edit this page |