January 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Call for UI gripes

by Lukas Renggli

>> 1) Multiple selection support. > > I would love to have this when generating accessor automatically. VERY often > I would like to only create accessors for some fields, not all. And > sometimes I want create just the setter or the getter, not both of them. So, > yes. I think this would be nice. If you are doing this with OB-Refectory then you can as a workaround actually modify the proposed changes of a refactoring before applying it. Simply select the methods in the change browser you don't want and press Ctrl+x. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 30, 2009

Re: [Pharo-project] Call for UI gripes

by Mariano Martinez Peck

On Fri, Jan 30, 2009 at 7:53 PM, Phil <pbpublist(a)gmail.com> wrote: > On 1/29/09 11:56 AM, Gary Chambers wrote: > > Anything that anyone thinks could be improved? > > Not sure if this is the type of feedback you're looking for but I'd like > to see some UI behavior changed/modernized: > > 1) Multiple selection support. I would love to have this when generating accessor automatically. VERY often I would like to only create accessors for some fields, not all. And sometimes I want create just the setter or the getter, not both of them. So, yes. I think this would be nice. > > > 2) Generally, the context of where the mouse pointer is should be taken > into account when performing an action. Right now the behavior feels > like an uncomfortable cross between Windows 3 and the old X11 pointer > focus behavior. For example: in lists when bringing up the context > menu, it would be nice to have the option of having the current > selection change to the item under the pointer if it is not already > selected (either singly or as part of a multi-selection) and then have > the context menu brought up. > > 3) I would love to see object inspectors behave much more like the > F-Script object browser. I often find myself needing to pull up 2 or 3 > sub-inspectors to get at what I want which is tedious. > > Thanks, > Phil > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 30, 2009

Re: [Pharo-project] Call for UI gripes

by Phil

On 1/29/09 11:56 AM, Gary Chambers wrote: > Anything that anyone thinks could be improved? Not sure if this is the type of feedback you're looking for but I'd like to see some UI behavior changed/modernized: 1) Multiple selection support. 2) Generally, the context of where the mouse pointer is should be taken into account when performing an action. Right now the behavior feels like an uncomfortable cross between Windows 3 and the old X11 pointer focus behavior. For example: in lists when bringing up the context menu, it would be nice to have the option of having the current selection change to the item under the pointer if it is not already selected (either singly or as part of a multi-selection) and then have the context menu brought up. 3) I would love to see object inspectors behave much more like the F-Script object browser. I often find myself needing to pull up 2 or 3 sub-inspectors to get at what I want which is tedious. Thanks, Phil

Jan. 30, 2009

Re: [Pharo-project] Using pharo in a course?

by Noury Bouraqadi

I start using Pharo for my OO course (instead of Squeak used for previous years). I decided to switch to Pharo because it's cleaner (UI, code, ...). Noury On 29 janv. 09, at 18:23, StÃ©phane Ducasse wrote: > Btw if you use pharo please let us know because this is important for > us that we list such use > and also the companies. > > > > Stef > > On Jan 29, 2009, at 5:53 PM, Marco D'Ambros wrote: > >> Hi all! >> >> I will start teaching a course about software engineering and web >> development, and I decided to do it with seaside. >> I was wondering whether to use pharo or squeak... which are the >> benefits and drawbacks of pharo with respect to squeak, in the >> context >> of a bachelor course? >> The students know about object oriented programming but don't about >> smalltalk, so in the first weeks we will teach smalltalk. >> >> Any suggestions? >> >> Thanks and cheers >> Marco D'Ambros >> >> _______________________________________________ >> 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 > Noury Bouraqadi ------------------------------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Responsable de l'enseignement de l'informatique ARMINES - Ecole des Mines de Douai - Dept. I.A. http://vst.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org ------------------------------------------------------------------

Jan. 30, 2009

[Pharo-project] In the way of cleaning etoy

by StÃ©phane Ducasse

Hi guys I'm working on removing etoy. I'm stuck with some methods I checked the references to Player restoreClassInstVars: is for example one of them. Now I would like to know what do you think of project. I think that we should remove it as well as bookmorph but I would like to know what do you think. Stef

Jan. 30, 2009

Re: [Pharo-project] Call for UI gripes

by Adrian Lienhard

On Jan 29, 2009, at 19:15 , Gary Chambers wrote: > Well, a contemporary look will always drive the computer harder... > Don't really find it a problem here though. Main PC is a > 2.8MHzQuadCore, lappie is a 1.7MHz Centrino. > Guess you might benefit from faster hardware. > > The SoftSqueak theme seems to be the fastest overall, curious since > nicer looking than StandardSqueak (which is, essentially, a pass- > through replication of the original code). > > I guess a poll of some kind of benchmark for all on the list may be > in order... We used to measure GUI performance with the "Browser-Bench": time _ 0. saveMorphs _ self currentWorld submorphs. 5 timesRepeat:[ self currentWorld removeAllMorphs. "heh, heh" time _ time + (Time millisecondsToRun: [ 1 to: 10 do: [:i | Browser fullOnClass: SystemDictionary selector: #abandonSources]. self currentWorld submorphs do: [:m | m delete. self currentWorld doOneCycle]]). ]. self currentWorld addAllMorphs: saveMorphs. time/5 asFloat "print it" On my machine I get: Squeak 3.9: 3800ms Pharo #084: 2950ms Pharo #213: 5200ms #084 is before Polymorph was added and #213 is the most recent version. BTW, with OB: 8590ms. Cheers, Adrian > > > Thanks for the support. > > Regards, Gary. > ----- Original Message ----- > From: Mariano Martinez Peck > To: Pharo-project(a)lists.gforge.inria.fr > Sent: Thursday, January 29, 2009 6:06 PM > Subject: Re: [Pharo-project] Call for UI gripes > > > Gary: First of all, thanks for your excellent work. > > I really like Polymorph and I use it as my default "theme". Very > very impressive. > > However, squeak seems to be a bit slower with it. For example, in > SqueakDBX we are 4 developers. Two of them cannot use it because is > slower enough to loose their patient. > > I am still newbie in squeak so I really don't know the resasons of > this. Perhaps this is a morphic thing and nothing about Polymorph. > If this is the case, sorry. > > Please, continue with your work. I really enjoy Polymorph and happy > to be the default in pharo. > > Cheers, > > Mariano > > > On Thu, Jan 29, 2009 at 2:56 PM, Gary Chambers <gazzaguru2(a)btinternet.com > > wrote: > > Anything that anyone thinks could be improved? > Happy to consider things... just would be nice to have a central > point for > moving forward with Polymorph (in particular) or other tools... > > There is a possibility of open-source release of the > PackageListTool > (http://www.flickr.com/photos/12018791@N06/2616669616/in/set-721576016593932… > ) > if there is any interest. > > Regards, Gary. > > > _______________________________________________ > 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

Jan. 30, 2009

Re: [Pharo-project] [Vm-dev] Re: newDelta >0 failed in sqUnixMemory

by John M McIntosh

mmm, let me clarify. I currently use Apple's GCC 4.0.1 <i686-apple- darwin9-gcc-4.0.1> that works fine for macintel, 3.3 is required for decent performance on powerpc. The version that I worked with Michael on was the LLVM GCC 4.2 and or GCC 4.2. Michael I believe tried GCC 4.3 Michael said: "after managing to build the VM with the recommended setup I tried with newer GCCs (3.45 and 4.3), both significantly slower. GCC 3.45 about 50%, GCC 4.3 about 80% of GCC 2.95." With 4.0.1 the compiler optimizations tweaks in the macintosh carbon VM build give it a good 10%? better than the defaults optimizations. However that presupposes -mtune=prescott -march=pentium-m which one can get away with on the macintosh platform, versus the bazillion cpu choices & clones on the Wintel side. On 30-Jan-09, at 9:37 AM, Andreas Raab wrote: > John M McIntosh wrote: >> Yes, I can't recall it was what 50% of the performance of a 3.x >> compile out of the box, and after *much* >> tweaking of compiler flags it was mmm just 20% slower.. Well >> certainly the performance impact was measured in 10 of percent. > > So what do you use today? gcc 4? And how does it stack up > performance-wise against a Windows VM on the same box? I personally > wouldn't mind moving forward but the results in the past were so > godawful that I haven't tried in a long time. > > Cheers, > - Andreas > >> On 30-Jan-09, at 4:33 AM, Michael Rueger wrote: >>> >>> John McIntosh and I actually spent some time a few ago compiling >>> VMs on >>> Windows and MacOS with the newest GCCs and ran into a bunch of >>> problems, >>> especially concerning performance. I had to put the work on the back >>> burner for now, but switching to newer compilers will take a bit of >>> extra work at some point. >>> >>> Michael >> -- >> = >> = >> = >> = >> = >> = >> ===================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> = >> ===================================================================== -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Jan. 30, 2009

Re: [Pharo-project] Call for UI gripes

by Adrian Lienhard

On Jan 30, 2009, at 17:19 , David RÃ¶thlisberger wrote: > >> I meant the two different styles of blue buttons that you see on the >> screenshot below. >> Is this the latest version I am looking at? > > no, can you execute 'ScriptLoader loadOBAlpha' to get the latest > version? yep, that looks nice. Taking the button styles of OB as the standard, the buttons of MC should be swapped. Adrian

Jan. 30, 2009

Re: [Pharo-project] Polymorph and OB Browser Colors Quick Solution

by GARY CHAMBERS

I notice the back/forward buttons are created with a morph as the label. Might be better to refactor OBDraggableButton to be under PluggableButtonMorphPlus (or implement enablement protocol) and use just a string or text, using enablement rather than on/off state - that should help avoid use of the hardcoded font. In Polymorph if the "label" (morph) of a PluggableButtonMorphPlus responds to #enabled: the enablement of the button gets forwarded to the label morph as well. Button bar heights are also a problem if fixed size. Similarly, OBButtonModel might benefit from some attention (hence the "different" style of the instance/class/traits buttons etc.). These buttons also. I guess there's a lot in OB to do with specifying the style of in a rather fixed manner (#styleWith:...) (clearly to make it look good with original Morphic) rather than relying on default behaviour that Polymorph leverages. The Vistary theme seems to highlight problems with button colours/states better while Watery2 highlights any pane colour problems. Getting there, I think though. Regards, Gary ________________________________ From: David RÃ¶thlisberger <squeak(a)webcitas.ch> To: Pharo-project(a)lists.gforge.inria.fr Sent: Friday, 30 January, 2009 3:17:46 PM Subject: Re: [Pharo-project] Polymorph and OB Browser Colors Quick Solution Thanks, Gary, for this new patch. Indeed this works better. :) I adapted some parts and committed it for the moment. >From the Polymorph point of view: Is this what you need? Because I need to adapt it again as OB does not work properly in Squeak now, so I would like to know whether it does what you want for Polymorph or not. It's enough when you load latest OB-Morphic to get it. David > Found the correct one now... attached. > > Regards, Gary. > > ----- Original Message ----- From: "David RÃ¶thlisberger" > <squeak(a)webcitas.ch> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Thursday, January 29, 2009 1:43 PM > Subject: Re: [Pharo-project] Polymorph and OB Browser Colors Quick Solution > > >> Hi Gary, >> >>> Not heard from David since I emailed on 30th Dec about getting OB to be >>> less hardcoded about direct use of model colours, along with having >>> buttons changed to PluggableButtonMorphPlus (to use enablement rather >>> than on/off state to indicate enablement)... >> >> yep, sorry, I was busy with other stuff. >> >> But still I'm not sure about the question I sent to you beginning of >> this year as an >> answer to your mail from the 30th of December: >> >> "Concerning the first issue about #adoptPaneColor: >> In my Squeak 3.9 (and I think also in my latest Pharo) image this >> method is already >> present in Morph. Is your change therefore needed at all, and if so, >> where should we >> commit it? I don't think it should be part of OB." >> >> To give you some more context: You once posted to the mailing list a >> CS-patch >> containing the #adoptPaneColor: as an OB-extension method for Morph. >> But as for me >> this method (with the same source code) is already present in Morph, I >> cannot imagine >> that this patch fixes the problem. >> I therefore think we should fix this color problem differently. >> If you know another solution, please let me know, otherwise I will >> dive into it. >> >> I will in the meantime look at the PluggableButtonMorphPlus issue. >> >> Cheers, >> David >> >> >>> Regards, Gary. >>> >>> ----- Original Message ----- >>> *From:* Rob Rothwell <mailto:r.j.rothwell@gmail.com> >>> *To:* Pharo Development <mailto:pharo-project@lists.gforge.inria.fr> >>> *Sent:* Tuesday, January 27, 2009 11:32 PM >>> *Subject:* [Pharo-project] Polymorph and OB Browser Colors Quick >>> Solution >>> >>> I know OB has some issues with the Polymorph themes such that you >>> are always left with the standard browser window color border in the >>> window panes of an OB Browser. >>> >>> At any rate, a simple "Preferences setPreference: >>> #browserWindowColor toValue: (Color r: 0.815 g: 0.811 b: 0.811)" >>> seems to set it to a decent color for the Watery2 or Watery theme, >>> but I was wondering if there is a better place to set something like >>> this more...dynamically...when different themes are chosen. >>> >>> Thanks, >>> >>> Rob >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 > > ------------------------------------------------------------------------ > > _______________________________________________ > 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

Jan. 30, 2009

[Pharo-project] a couple of issues

by Tudor Girba

Hi, There are a couple of issues I stumbled across in Pharo and I thought of reporting them: - When loading Pier and Seaside there were some Warnings related to some instance variables that blocked the loading. This is a rather strange behavior, especially given that they are warnings. I would rather prefer to have the list of warnings presented to me at the end because like this I can have the code loading without me needing to pay attention. - Apple+B does not work on methods anymore. - Apple+W does not close the window. It seems that the outside window never gets the focus it needs to act on this shortcut. - Spawning a browser takes quite a long time. - Why is mouse swap preference not enabled by default? Otherwise, it looks really nice :) Cheers, Doru -- www.tudorgirba.com "Every successful trip needs a suitable vehicle."

Jan. 30, 2009