>>> >>> >> 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? >> >> >> > 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 :)
> >> >>> 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, >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >> >> >> >> > > > -- Mariano http://marianopeck.wordpress.com
