November 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] mac menus in Pharo

by Adrian Lienhard

nice! I noticed: - Most items in the submenu System>Preferences>... do not do anything when being selected - testMenuHandlesCount and testCountsMacOnly fail To integrate these changes, you could just give us a change set (I assume the current Unnamed changeset in the image contains all relevant changes already), and we will then deal with MC. Adrian On Nov 1, 2008, at 05:59 , John M McIntosh wrote: > > On Oct 31, 2008, at 1:28 PM, Marcus Denker wrote: > >> >> On 31.10.2008, at 21:18, John McIntosh wrote: >> >>> I'm wondering if there is any interest in having mac menus in Pharo. >>> This was done for Sophie >>> and Scratch, and attempted for 3.10. I could drag the required >>> change >>> sets out of storage to >>> implement the proper file/edit menu in Pharo and have it respond to >>> cmd-Q etc if there is >>> any interest... >> >> Yes! I want all the things that are in the new simple world-menu in >> a "real" menu. >> >> Marcus > > > Done (I think) > > Next time I'm at ESUG I must stay more than 5 hours so that people > can buy me some beer. > > I've posted pharo10124WithMacMenus.1.image to my idisk > in the /experimental/Pharo/ folder > found via http://www.smalltalkconsulting.com/squeak.html > > Macintosh users can take it for a spin. > > I note we should have a more *generic* way to convert morphic menus > to the structure needed for macintosh menus > but it took me a couple of hours to figure out how to make the > hierarchy mac menus since I've not done that before, plus > I wasted some time looking at the complicated target, argument, > selector mess on the morphic menu item before > discovering *doButtonAction* did the required menu activation trick > on the mophic menu item. > > Perhaps someone clever can figure out how to read all the morphic > menus and build the require mac menus. > > I did a bit of hand coding instead. > > Once everyone is happy, could someone take the > pharo10124WithMacMenus.1.image and promote to the proper MC > server, I'm not quite sure how that is done, and rather not risk > screwing things up quite yet. > > Normally macintosh application also have Windows menu for multiple > host windows. Once we actually get to having multiple > host windows, why turning that menu on is lurking in the code base... > > disableHideMenuCmd disables the cmd-H for hide squeak VM. Some > people might like that, personally in some images I prefer the > hierarchy browser to come up... Anyway people can decide. > > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 1, 2008

[Pharo-project] about timesRepeat: changes?

by StÃ©phane Ducasse

Hi one person is saying the following in the seaside mailinglist "In Pharo, some OmniBrowser functionality was broken and as I said timesRepeat: was broken. It had a '<' rather than '<=' for the loop comparison so the loop ran one too few times. I ran an update which fixed both problems. " Does one of you remember that we got a change changing timesRepeat: I have serious doubts this is why I"m asking. stef

Nov. 1, 2008

Re: [Pharo-project] How to load OmniBrowser into Pharo

by Alexandre Bergel

Excellent David, Cheers, Alexandre On 30 Oct 2008, at 10:12, David RÃ¶thlisberger wrote: > Hi, > > > during the recent days we worked hard on OmniBrowser to extend, > improve and stabilize it. > > We also improved the loading process of all required packages to run > OmniBrowser (system and package browser). > > In the latest version of ScriptLoader you will find three load > methods for OB: > > #loadOB > loads the latest stable version linked in Universe. Use this to be > on the safe side > > #loadOBAlpha > loads the latest development version of all required packages stored > in source.wiresong.ca/ob. Use this if you want to be on the cutting > edge. ;) > > #loadSuperOB > does the same as #loadOBAlpha, but also loads additional packages, > for instance to get visualizations directly in OB. You use this to > get everything. ;) > > > Cheers, > David > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 1, 2008

Re: [Pharo-project] RBParser

by Lukas Renggli

On Fri, Oct 31, 2008 at 10:42 AM, Gwenael Casaccio <mrgwen(a)gmail.com> wrote: > I've commit a new version I've removed all the RB*Token I've loaded your changes, but it seems to break the refactoring browser. All literals (numbers, symbols, true, false, nil, ...) are printed as strings ('123', '#foo', 'true', 'false', ...). Did I forget to load something, or is this a bug? Cheers, Lukas > > On 10/29/08 6:21 PM, Lukas Renggli wrote: >>> >>> As I've said to you Marcus, I've worked on the RBParser/RBScanner. I've >>> fixed these classes and now you can parse the entire image. At this >>> moment >>> the refactoring is not yet finished but I've made some good progress. >> >> Good news. >> >> I was not aware that you were working on RBParser. Stef told me that >> you also improved the refactorings. I think you should commit and work >> on the public repository to get more attention. I guess there were >> many other changes going on in RB codebase in the meantime. >> >> Cheers, >> Lukas >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 1, 2008

[Pharo-project] Preferences should be optional: aka towards reall OOP preferences

by StÃ©phane Ducasse

Hi all Here is a call for good design sharing. I already posted a mail on that design issue but I want to restate it. I really want in the future to be able to remove Preferences (we need preferences but not the way they are). right now when I'm LittApp an application and run my little flow I will suddenly invoke the HUGE Global center (Preferences) to see what **I** have to do.... So at the end of the day we got, debugger, compiler, Morphic.... depending on preferences and this is WRONG. What we should have (illustrated really well with the MC sorting menu) is LittApp is responsible for its own preferences So it runs, and check **Itself**: "oh how should I behave, let me see ***my own*** state tell me to turn right, to be novice friendly... and I do it. Notice how little application does NOT reference to the HUGE Preference Global Now the BIG Preferences setter will just change the configuration of the little app. Preferences>>sortingLittleApp LittleApp sortTop Now of course, littApp could be a bit smarter and say BIGPreferenceSetter here are my preferences we could use pragmas to define preferences that BIGPreferences would gather and present to the user. Stef

Nov. 1, 2008

Re: [Pharo-project] mac menus in Pharo

by StÃ©phane Ducasse

>> > Done (I think) > > Next time I'm at ESUG I must stay more than 5 hours so that people > can buy me some beer. Oh Yes! The next ESUG can really be a huge hacking camp so please book the dates :) > I've posted pharo10124WithMacMenus.1.image to my idisk > in the /experimental/Pharo/ folder > found via http://www.smalltalkconsulting.com/squeak.html > > Macintosh users can take it for a spin. > > I note we should have a more *generic* way to convert morphic menus > to the structure needed for macintosh menus > but it took me a couple of hours to figure out how to make the > hierarchy mac menus since I've not done that before, plus > I wasted some time looking at the complicated target, argument, > selector mess on the morphic menu item before what you are criticizing this piece of art :) > > discovering *doButtonAction* did the required menu activation trick > on the mophic menu item. > > Perhaps someone clever can figure out how to read all the morphic > menus and build the require mac menus. > > I did a bit of hand coding instead. > > Once everyone is happy, could someone take the > pharo10124WithMacMenus.1.image and promote to the proper MC > server, I'm not quite sure how that is done, and rather not risk > screwing things up quite yet. > > Normally macintosh application also have Windows menu for multiple > host windows. Once we actually get to having multiple > host windows, why turning that menu on is lurking in the code base... > > disableHideMenuCmd disables the cmd-H for hide squeak VM. Some > people might like that, personally in some images I prefer the > hierarchy browser to come up... Anyway people can decide. > > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 1, 2008

Re: [Pharo-project] mac menus in Pharo

by StÃ©phane Ducasse

+ 100 Stef On Oct 31, 2008, at 10:47 PM, Lukas Renggli wrote: > Yes, I would like to have that too. > > Lukas > > On Fri, Oct 31, 2008 at 9:28 PM, Marcus Denker <denker(a)iam.unibe.ch> > wrote: >> >> On 31.10.2008, at 21:18, John McIntosh wrote: >> >>> I'm wondering if there is any interest in having mac menus in Pharo. >>> This was done for Sophie >>> and Scratch, and attempted for 3.10. I could drag the required >>> change >>> sets out of storage to >>> implement the proper file/edit menu in Pharo and have it respond to >>> cmd-Q etc if there is >>> any interest... >> >> Yes! I want all the things that are in the new simple world-menu in >> a "real" menu. >> >> Marcus >> >> >> >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 1, 2008

Re: [Pharo-project] We will not accept any changes using initials anymore

by StÃ©phane Ducasse

> I was looking around at the Author class when issue: 209 was created. > I noticed there was inconsistency with the way it tests whether the > initials were present or not (string vs nil). I have a changeset for > that which I was planning to upload. Are you going to deprecate the > whole class or just the use of initials? > > My thoughts were to deprecate the concept of initials, and just put > the full name in the same place in the method timestamp. That way you > would not impact too much at once. There is a full name, but from > what I saw that was only related to projects, and you're going to kill > projects right? > > what do you think? yes project out! we should not have initials anymore. The Author class should just be cleaned up a bit and its senders. We can enter first.name -> firstname / name in author and use full name the way we want (camel or not) what lukas did is to make sure that you cannot enter zork@@#$Plys and that MC gets dead because you cannot create a file with one of the given character. Stef > > > cheers > Mike > > On Fri, Oct 31, 2008 at 2:16 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Yes that too. >> but the interface of authors and the senders should be fixed too. >> On Oct 31, 2008, at 2:17 PM, Damien Pollet wrote: >> >>> On Fri, Oct 31, 2008 at 1:03 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> >>>> what lukas did is to make sure that MC convert any non letter >>>> into _ so >>>> that >>> >>> ok. I was thinking of validating what people enter in the dialog (a >>> simple regexp would do) >>> >>>> Now what would be good is to radically fix Author once for all: >>>> - do not use initials at all. >>>> - deprecate it >>>> - fix all the senders >>>> - offer a nice interface >>>> - requestName >>>> - getName (accessor) >>>> - name (with request if necessary) >>>> >>>> Stef >>>> >>>> >>>> On Oct 31, 2008, at 11:58 AM, Damien Pollet wrote: >>>> >>>>> I guess it's best to adopt CamelCase FirstnameLastname, because >>>>> the >>>>> firstname.lastname format conflicts with the naming of MC >>>>> branches. >>>>> I'll update the initials dialog and try to make a more complete >>>>> fix of >>>>> this >>>>> >>>>> On Sat, Oct 25, 2008 at 7:47 PM, StÃ©phane Ducasse >>>>> <stephane.ducasse(a)inria.fr> wrote: >>>>>> >>>>>> done! >>>>>> Stef >>>>>> >>>>>> On Oct 25, 2008, at 8:16 PM, Dan Corneanu wrote: >>>>>> >>>>>>> On Sat, Oct 25, 2008 at 8:08 PM, StÃ©phane Ducasse >>>>>>> <stephane.ducasse(a)inria.fr> wrote: >>>>>>>> >>>>>>>> ascii only no space >>>>>>>> >>>>>>> >>>>>>> Maybe we should state that too on page >>>>>>> http://code.google.com/p/pharo/wiki/HowToContribute >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-project mailing list >>>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Damien Pollet >>>>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Damien Pollet >>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 1, 2008

Re: [Pharo-project] [update] #1025

by StÃ©phane Ducasse

What a good feeling to have methods that were obsolete since 10 years removed from the system (I was idiot to believe that they were used...) Marcus did you change the GC parameters as mentioned by john. Stef On Oct 31, 2008, at 8:23 PM, Marcus Denker wrote: > update1025 > --------- > > Issue 303: TODO: remove profiling methods > Issue 300: unimplemented call in > AlignmentMorphBob1>>acceptDroppingMorph:event: > Issue 299: Mantis 007007 and 007008 correct toggle break on entry > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 1, 2008

Re: [Pharo-project] mac menus in Pharo

by John M McIntosh

On Oct 31, 2008, at 1:28 PM, Marcus Denker wrote: > > On 31.10.2008, at 21:18, John McIntosh wrote: > >> I'm wondering if there is any interest in having mac menus in Pharo. >> This was done for Sophie >> and Scratch, and attempted for 3.10. I could drag the required change >> sets out of storage to >> implement the proper file/edit menu in Pharo and have it respond to >> cmd-Q etc if there is >> any interest... > > Yes! I want all the things that are in the new simple world-menu in > a "real" menu. > > Marcus Done (I think) Next time I'm at ESUG I must stay more than 5 hours so that people can buy me some beer. I've posted pharo10124WithMacMenus.1.image to my idisk in the /experimental/Pharo/ folder found via http://www.smalltalkconsulting.com/squeak.html Macintosh users can take it for a spin. I note we should have a more *generic* way to convert morphic menus to the structure needed for macintosh menus but it took me a couple of hours to figure out how to make the hierarchy mac menus since I've not done that before, plus I wasted some time looking at the complicated target, argument, selector mess on the morphic menu item before discovering *doButtonAction* did the required menu activation trick on the mophic menu item. Perhaps someone clever can figure out how to read all the morphic menus and build the require mac menus. I did a bit of hand coding instead. Once everyone is happy, could someone take the pharo10124WithMacMenus. 1.image and promote to the proper MC server, I'm not quite sure how that is done, and rather not risk screwing things up quite yet. Normally macintosh application also have Windows menu for multiple host windows. Once we actually get to having multiple host windows, why turning that menu on is lurking in the code base... disableHideMenuCmd disables the cmd-H for hide squeak VM. Some people might like that, personally in some images I prefer the hierarchy browser to come up... Anyway people can decide. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 1, 2008