Hi guys. After playing a little bit with StartupPreferences, and continuing the effort of Ben (thanks Ben for yet another great tool), I generate a improved (from my point of view) version of the tool.
The main changes are: a) Previously the tool searched files 1) first in image directory, 2) then in the preference folder and 3) finally in the general preference folder. As soon as it found at least one file, I didn't continue with the rest of the places. Now, it starts the other way around, from the most general to the most spceific. Starts in 3), then 2) and finally 3). Moreover, it does not stop when it finds files in any of them. So all are searched and executed. It works or or less the same way as variables in UNIX with .bashrc /etc/envirorment, etc... b) I have created several class side methods (addAtStartup*) to create given actions into the current directory. Previously, files were created in 2 folders at the same time and there were only the possibility to create only in one place. Now you can add startup actions in any of the 3 places mentioned in a) c) Added a whole protocol (remove* and clean*) to remove script files from all folders of a) and also to clean the internal stored actions. d) Lots of internal refactors to reuse code and less hardcoding. Does someone want to take a look to the slice ? Slice in inbox: http://code.google.com/p/pharo/issues/detail?id=5835 Cheers, -- Mariano http://marianopeck.wordpress.com |
mariano
how can you override a general behavior without redoing it? Stef On May 7, 2012, at 10:21 PM, Mariano Martinez Peck wrote: > Hi guys. After playing a little bit with StartupPreferences, and continuing the effort of Ben (thanks Ben for yet another great tool), I generate a improved (from my point of view) version of the tool. > > The main changes are: > > a) Previously the tool searched files 1) first in image directory, 2) then in the preference folder and 3) finally in the general preference folder. As soon as it found at least one file, I didn't continue with the rest of the places. Now, it starts the other way around, from the most general to the most spceific. Starts in 3), then 2) and finally 3). Moreover, it does not stop when it finds files in any of them. So all are searched and executed. It works or or less the same way as variables in UNIX with .bashrc /etc/envirorment, etc... > > b) I have created several class side methods (addAtStartup*) to create given actions into the current directory. Previously, files were created in 2 folders at the same time and there were only the possibility to create only in one place. Now you can add startup actions in any of the 3 places mentioned in a) > > c) Added a whole protocol (remove* and clean*) to remove script files from all folders of a) and also to clean the internal stored actions. > > d) Lots of internal refactors to reuse code and less hardcoding. > > Does someone want to take a look to the slice ? > Slice in inbox: http://code.google.com/p/pharo/issues/detail?id=5835 > > Cheers, > > -- > Mariano > http://marianopeck.wordpress.com > |
On Tue, May 8, 2012 at 9:59 AM, Stéphane Ducasse <[hidden email]> wrote: mariano What I mean by override is exactly redoing. So if in /Users/mariano/.config/pharo/general you have a script that does: UITheme currentSettings fastDragging: true. and then in /Users/mariano/.config/pharo/2.0 (or in startup.st in the image directory) I have a script that does UITheme currentSettings fastDragging: false. then it will be false the value, beacuse the order of execution is from the most general to the most specific. Cheers Stef -- Mariano http://marianopeck.wordpress.com |
In reply to this post by Mariano Martinez Peck
Hi Mariano,
On Mon, May 7, 2012 at 10:21 PM, Mariano Martinez Peck <[hidden email]> wrote: > Hi guys. After playing a little bit with StartupPreferences, and continuing > the effort of Ben (thanks Ben for yet another great tool), I generate a > improved (from my point of view) version of the tool. your changes make sense. Nevertheless, I thought that looking into the preferences folder was disabled. Did you fix that? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry |
In reply to this post by Mariano Martinez Peck
On May 8, 2012, at 11:34 AM, Damien Cassou wrote: > Hi Mariano, > > On Mon, May 7, 2012 at 10:21 PM, Mariano Martinez Peck > <[hidden email]> wrote: >> Hi guys. After playing a little bit with StartupPreferences, and continuing >> the effort of Ben (thanks Ben for yet another great tool), I generate a >> improved (from my point of view) version of the tool. > > your changes make sense. Nevertheless, I thought that looking into the > preferences folder was disabled. Did you fix that? > It is enabled now for all platform but windows. Marcus -- Marcus Denker -- http://marcusdenker.de |
On Tue, May 8, 2012 at 11:36 AM, Marcus Denker <[hidden email]> wrote:
Yes Damien, as Marcus said I put it back and only disabled it for Windows until it is fixed. I also solved a problem in which actions defined as "runOnce" were actually executed each time ;) I wrote a blog post about StartupLoader but I will publish it when the changes are integrated ;) otherwise it doesn't make sense. -- Mariano http://marianopeck.wordpress.com |
Administrator
|
In reply to this post by Mariano Martinez Peck
Should be "/Users/mariano/.pharo/config/general", no?
Cheers,
Sean |
On Tue, May 8, 2012 at 3:03 PM, Sean P. DeNigris <[hidden email]> wrote:
No, the directory is actually /Users/mariano/.config/pharo/general Of course it can be changed if that's what people want. I have no idea, StartupPreference was like this before I touch it ;) It seems in linux they are stored that way so to avoid lots of .xxx in the $HOME. So you use one directory for all your conf ;) (thanks Pavel) Cheers
-- Mariano http://marianopeck.wordpress.com |
Administrator
|
Oh, I see, thanks. I was thinking like ~/.jenkins, but I checked Ubuntu and OS X and it looks like ~/.config is a well-known convention. Sean
Cheers,
Sean |
On Tue, May 8, 2012 at 3:54 PM, Sean P. DeNigris <[hidden email]> wrote:
> Oh, I see, thanks. I was thinking like ~/.jenkins, but I checked Ubuntu and > OS X and it looks like ~/.config is a well-known convention. This is part of a specification: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry |
In reply to this post by Mariano Martinez Peck
Mariano Martinez Peck wrote:
> Hi guys. After playing a little bit with StartupPreferences, and continuing > the effort of Ben (thanks Ben for yet another great tool), I generate a > improved (from my point of view) version of the tool. > > The main changes are: > > a) Previously the tool searched files 1) first in image directory, 2) then > in the preference folder and 3) finally in the general preference folder. > As soon as it found at least one file, I didn't continue with the rest of > the places. Now, it starts the other way around, from the most general to > the most spceific. Starts in 3), then 2) and finally 1) > Moreover, it does > not stop when it finds files in any of them. So all are searched and > executed. It works or or less the same way as variables in UNIX with > .bashrc /etc/envirorment, etc... > Did it actually work like that? I thought it had worked for me processing more than one file from each preferences folders. It seemed only the image folder was restricted to a single specific file 'startup.st' I assume this was to avoid processing any other random .st files that might happen appear in the image folder. I had been considering a refactoring like your #lookInFolder, but was concerned about picking up random .st files in the image folder. I haven't gone through the your new methods in detail, but I've expanded your changes to the existing architecture to also resolve the issue with Windows. Basically I've thrown away what I was trying to do putting the configs into standard Microsoft locations. That was mainly to deal the location of config folders being hardcoded at two level down from root, which I have now removed this constraint. The config folder can now be located anywhere in the parent path from the image up to root. The key addition is #ascendingSearchForDirectory for which you can try these out... FileDirectory default ascendingSearchForDirectory: 'mariano' FileDirectory default ascendingSearchForDirectory: 'Users' FileDirectory default ascendingSearchForDirectory: 'Contents' "Valid for one-click image" FileDirectory default ascendingSearchForDirectory: FileDirectory configFolderLocalName FileDirectory preferencesGeneralFolder FileDirectory preferencesFolder > b) I have created several class side methods (addAtStartup*) to create > given actions into the current directory. Previously, files were created in > 2 folders at the same time and there were only the possibility to create > only in one place. Now you can add startup actions in any of the 3 places > mentioned in a) > > c) Added a whole protocol (remove* and clean*) to remove script files from > all folders of a) and also to clean the internal stored actions. > > d) Lots of internal refactors to reuse code and less hardcoding. > > Does someone want to take a look to the slice ? > Slice in inbox: http://code.google.com/p/pharo/issues/detail?id=5835 > > Cheers, > > |
On Tue, May 8, 2012 at 7:21 PM, Ben Coman <[hidden email]> wrote: Mariano Martinez Peck wrote: yes I thought it had worked for me processing more than one file from each preferences folders. No. See the previous version: PreferenceHandler >> perform actions do: [:each | each value ifNotNil: [:res | ^ res ] ]. ^#() then the value was not nil (therefore, when there were found files), the method just returned. It seemed only the image folder was restricted to a single specific file 'startup.st' I assume this was to avoid processing any other random .st files that might happen appear in the image folder. I had been considering a refactoring like your #lookInFolder, but was concerned about picking up random .st files in the image folder. I copy paste here part of my future blog post (once this is integrated I will publish it). This is how it works NOW in ORDER:
I haven't gone through the your new methods in detail, but I've expanded your changes to the existing architecture to also resolve the issue with Windows. Excellent. So it means that then it is working for Windows also?
-- Mariano http://marianopeck.wordpress.com |
Mariano Martinez Peck wrote:
> On Tue, May 8, 2012 at 7:21 PM, Ben Coman <[hidden email]> wrote: > > >> Mariano Martinez Peck wrote: >> >> >>> Hi guys. After playing a little bit with StartupPreferences, and >>> continuing >>> the effort of Ben (thanks Ben for yet another great tool), I generate a >>> improved (from my point of view) version of the tool. >>> >>> The main changes are: >>> >>> a) Previously the tool searched files 1) first in image directory, 2) then >>> in the preference folder and 3) finally in the general preference folder. >>> As soon as it found at least one file, I didn't continue with the rest of >>> the places. Now, it starts the other way around, from the most general to >>> the most spceific. Starts in 3), then 2) and finally 1) >>> >>> >> Moreover, it does >> >>> not stop when it finds files in any of them. So all are searched and >>> executed. It works or or less the same way as variables in UNIX with >>> .bashrc /etc/envirorment, etc... >>> >>> >>> >> Did it actually work like that? >> > > > yes > > > >> I thought it had worked for me processing more than one file from each >> preferences folders. >> > > > No. See the previous version: > > PreferenceHandler >> perform > > actions do: [:each | > > each value ifNotNil: [:res | ^ res ] > ]. > > ^#() > > > then the value was not nil (therefore, when there were found files), the > method just returned. > > > > >> It seemed only the image folder was restricted to a single specific file ' >> startup.st' I assume this was to avoid processing any other random .st >> files that might happen appear in the image folder. I had been considering >> a refactoring like your #lookInFolder, but was concerned about picking up >> random .st files in the image folder. >> >> >> > I copy paste here part of my future blog post (once this is integrated I > will publish it). This is how it works NOW in ORDER: > > > 1. The image folder: The startup only searches for a file called ‘ > startup.st’. So if you have such a file in the same directory where the > image is, then such script will be executed automatically. This type of > startup is usually used to do something that is application-specific or > something that only makes sense for the specific image you are using. > 2. Preference folder: This is a specific folder for a specific Pharo > version. This folder is in the $HOME (kind of) of the current OS’ user. > Therefore, this folder is shared for all the images you open. To know the > real value, print the result of “FileDirectory preferencesFolder”. In my > case (in MaxOSX) and Pharo 2.0, it is ’/Users/mariano/.config/pharo/2.0′. > In this place, StartupLoader will load ALL existing .st files. This type of > startup is useful when we have something to execute for all images of a > specific Pharo version. > 3. General preferences folder: this is similar to the previous one with > the difference that it is general for all Pharo versions. To know the > value, print “FileDirectory preferencesGeneralFolder”, which in my case is > ‘/Users/mariano/.config/pharo/general’. This type of startup is useful when > we have something to execute for all images of any Pharo version. > > > > > >> I haven't gone through the your new methods in detail, but I've expanded >> your changes to the existing architecture to also resolve the issue with >> Windows. >> Basically I've thrown away what I was trying to do putting the configs >> into standard Microsoft locations. That was mainly to deal the location of >> config folders being hardcoded at two level down from root, which I have >> now removed this constraint. The config folder can now be located anywhere >> in the parent path from the image up to root. >> >> The key addition is #ascendingSearchForDirectory for which you can try >> these out... >> FileDirectory default ascendingSearchForDirectory: 'mariano' >> FileDirectory default ascendingSearchForDirectory: 'Users' >> FileDirectory default ascendingSearchForDirectory: 'Contents' "Valid >> for one-click image" >> FileDirectory default ascendingSearchForDirectory: FileDirectory >> configFolderLocalName FileDirectory preferencesGeneralFolder >> FileDirectory preferencesFolder >> >> >> > > Excellent. So it means that then it is working for Windows also? > > > >> b) I have created several class side methods (addAtStartup*) to create >> >>> given actions into the current directory. Previously, files were created >>> in >>> 2 folders at the same time and there were only the possibility to create >>> only in one place. Now you can add startup actions in any of the 3 places >>> mentioned in a) >>> >>> c) Added a whole protocol (remove* and clean*) to remove script files from >>> all folders of a) and also to clean the internal stored actions. >>> >>> d) Lots of internal refactors to reuse code and less hardcoding. >>> >>> Does someone want to take a look to the slice ? >>> Slice in inbox: http://code.google.com/p/**pharo/issues/detail?id=5835<http://code.google.com/p/pharo/issues/detail?id=5835> >>> >>> Cheers, >>> >>> >>> >>> >> >> > > > |
Yes. It works for Windows - now with the same (modified) logic as Unix. Ok, so I will re-do the slice adding your stuff and I will put it as FixToInclude :)
-- Mariano http://marianopeck.wordpress.com |
Free forum by Nabble | Edit this page |