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

Re: [Pharo-project] Morph extension

by Marcus Denker

On 16.09.2009, at 10:29, Gary Chambers wrote: > I get a different "top offenders" list of course. > I've managed to refactor the worst offenders. > > Benchmarks for the "opening system browser" below show an improvement. > > Going from patched to unpatched shows that the unpatched takes > between 15% > and 20% longer to complete depending on fonts/theme. > > (Benchmark code) > > | saveMorphs time | > [saveMorphs := World submorphs. > World removeAllMorphs."heh, heh" > time := [1 to: 10 do: [:i | > MorphicToolBuilder new open: > (Browser new setClass: SystemDictionary selector: nil). > World doOneCycleNow]. > World submorphs do: [:m | m delete. World doOneCycleNow]. > ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. > SystemWindow noteTopWindowIn: World. > time > > (end of benchmark code) > > I can make a changeset available for the brave who want to try. Yes, I would like to try! Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Sept. 16, 2009

Re: [Pharo-project] Visual nonsense

by Gary Chambers

Have settled for active window: with Watery2 the taskbar button label is shown with the selection colour. with W2K I have removed the fixed colour, appears darker than others for active window and effectively re-enables custom colour support for buttons (like the SystemBrowser inheritance button). Will release later this week. In the meantime... To see with W2K remove #buttonColorFor: from UIThemeW2K Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, September 16, 2009 3:26 PM Subject: Re: [Pharo-project] Visual nonsense > Gary, > > Whichever you think will work best - changing the background is probably > more win2k-like, now that you mention it, but anything that distinguishes > the active window would be welcome. > > Thanks! > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary > Chambers > Sent: Wednesday, September 16, 2009 4:45 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Visual nonsense > > Do you mean the icon or the button background? > > Regards, Gary > > ----- Original Message ----- > From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Wednesday, September 16, 2009 12:02 AM > Subject: [Pharo-project] Visual nonsense > > >> Gary, especially for the W2k theme, it would be really nice to have a >> distinct look for the selected view's icon in the task bar. >> >> Andy, is there a good place to change the background fill style? When I >> last looked, it seemed to me that it was hard-coded. You mentioned a >> configuration tool you wanted to build, but I would be happy to use a >> do-it chunk to make the change; I just could not find a relevant style. >> >> Sorry to bug you guys with such relative minutia. Thanks to all for the >> lots of stuff that works well enough that I notice these things. >> >> Bill >> >> >> >> _______________________________________________ >> 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

Sept. 16, 2009

[Pharo-project] Usability improvements for the class browser: buttons

by Stephan Eggermont

Hello, When I open a class browser in a Pharo Image (10418 updated to 10451) with the default Watery 2 theme, the window is visually dominated by the button bar. Compared to the other parts of the window, it has too much vertical height and there is not enough white space around the buttons. The problem with vertical height can be illustrated by looking at the precision needed to select a class category versus that needed to click the browse button. The button has about twice the vertical height. That would be ok when clicking the button would be the more common operation, but I don't find that to be the case. The kind of button used in Watery 2 only works well visually when it has a rather large white space around it. The button bar of the preference browser already works much better than that of the class browser, but even that has too little space above and below. The buttons in the button bar of the class browser feel very heavy because they don't have enough horizontal separation. With the default window size, there is not enough space for the needed separation. When the window is grown, instead of growing the separation first, and then the button width, only the button width is grown. Some operating systems have introduced a better solution for this problem, a dedicated button bar. Attached is an impression of how this could look. I hope you'd agree that it would provide a cleaner look. I'd be interested in some clues on what would be needed to add such a button bar. The red, orange, and green window buttons used to have a much better horizontal separation. I am not sure in which update they were put so close together, but they need at least as much horizontal separation as the space from left window border to the first (red) button. Stephan Eggermont

Sept. 16, 2009

Re: [Pharo-project] Morph extension

by Gary Chambers

I get a different "top offenders" list of course. I've managed to refactor the worst offenders. Benchmarks for the "opening system browser" below show an improvement. Going from patched to unpatched shows that the unpatched takes between 15% and 20% longer to complete depending on fonts/theme. (Benchmark code) | saveMorphs time | [saveMorphs := World submorphs. World removeAllMorphs."heh, heh" time := [1 to: 10 do: [:i | MorphicToolBuilder new open: (Browser new setClass: SystemDictionary selector: nil). World doOneCycleNow]. World submorphs do: [:m | m delete. World doOneCycleNow]. ] timeToRun] ensure:[World addAllMorphs: saveMorphs]. SystemWindow noteTopWindowIn: World. time (end of benchmark code) I can make a changeset available for the brave who want to try. I have developed a workspace script that (finally) appears to load it correctly, waas a lot of hung-image before getting there... (loading tested on 10451-BETA) Regards, Gary ----- Original Message ----- From: "Henrik Johansen" <henrik.s.johansen(a)veloxit.no> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, September 08, 2009 7:01 PM Subject: Re: [Pharo-project] Morph extension StÃ©phane Ducasse skrev: > On Sep 8, 2009, at 5:32 PM, Gary Chambers wrote: > > >> After some experimenting I can get over 10% perfromance improvement >> with >> window operations when fillStyle; borderStyle; hResizing; vResizing >> are >> made as instance variables of Morph, rather than going through >> extension. >> > > this is a lot. > You really mean Morph or we could get them in subclasses too. > > Inspect this in an image with some windows open, it will give you the percentage of morphs with otherProperties containing any given property: |propBag noMorphs| propBag := Bag new: 50. noMorphs := 0. Morph allSubInstances do: [:each | each otherProperties ifNotNil: [:props | propBag addAll: props keys. noMorphs := noMorphs +1]] . noMorphs := noMorphs asFloat. propBag sortedCounts collect: [:each | each key: each key / noMorphs; yourself] otherProperties is heavily abused. with respectively 98 and 125 senders of valueOfProperty: / valueOfProperty:ifAbsent:... In my case there were _57_ different distinct otherProperties in use, an average of three, a maximum of 15, and four of them present in over a quarter of morphs defining any (80% for the most common one)... If moving directly to Morph is a bit extreme, at least _some_ of these qualify for promotion to direct access in MorphExtension imho, it seems to have some "free" instvars anyways after the removal of players. In the interest of seeing which would benefit the most from moving, I did a small profile: - Dragging a window and switching some between different ones with 2 browsers, a monticello browser, a workspace and a Method search open. I had the following access numbers: 105586->#clipSubmorphs (about 4.5 per millisecond) 66029->#layoutProperties 62783->#layoutPolicy 55556->#theme 41312->#hasDropShadow 41310->#hasRolloverBorder 36817->#fillStyle 19241->#cornerStyle 13239->#highlightedForDrop 13239->#highlightedForMouseDown 11945->#roundedCorners 11911->#borderStyle 10644->#edgeToAdhereTo 9020->#paneColor 8885->#lastPaneColor [rest below 5000 accesses] Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009

Re: [Pharo-project] Visual nonsense

by Schwab,Wilhelm K

Gary, Whichever you think will work best - changing the background is probably more win2k-like, now that you mention it, but anything that distinguishes the active window would be welcome. Thanks! Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers Sent: Wednesday, September 16, 2009 4:45 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Visual nonsense Do you mean the icon or the button background? Regards, Gary ----- Original Message ----- From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, September 16, 2009 12:02 AM Subject: [Pharo-project] Visual nonsense > Gary, especially for the W2k theme, it would be really nice to have a > distinct look for the selected view's icon in the task bar. > > Andy, is there a good place to change the background fill style? When I > last looked, it seemed to me that it was hard-coded. You mentioned a > configuration tool you wanted to build, but I would be happy to use a > do-it chunk to make the change; I just could not find a relevant style. > > Sorry to bug you guys with such relative minutia. Thanks to all for the > lots of stuff that works well enough that I notice these things. > > Bill > > > > _______________________________________________ > 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

Sept. 16, 2009

[Pharo-project] Author name prompt window is too big

by Oscar Nierstrasz

Today I was giving a Pharo demo, using a slightly larger than standard font. When I tried to commit a change, the prompt for my user name was bigger than the available screen space on my laptop. Luckily I could still type, though I could not see what I was typing. Can we please modify Author>>messagePrompt to use a *short* message? The existing one is ridiculously large. Author>>messagePrompt ^ 'Please type your name. It will be used to sign the changes you make to the image. Try to write an ASCII approximation of your name with only alphabetic characters and avoiding, if possible, spaces, accents, dashes and similar characters. Examples (The prefered form is the first one of each name): Miguel CobÃ¡ -> MiguelCoba Miguel CobÃ¡ -> miguel.coba Miguel CobÃ¡ -> miguel_coba GÃ¶ran Krampe -> GoranKrampe GÃ¶ran Krampe -> GoeranKrampe GÃ¶ran Krampe -> goran.krampe GÃ¶ran Krampe -> goran_krampe Vincent van Gogh -> VincentVanGogh StÃ©phane DUCASSE -> StephaneDucasse StÃ©phane DUCASSE -> stephane.ducasse Yoshiki Oshima -> YoshikiOshima Yoshiki Oshima -> yoshiki.oshima ' The first example would be good enough. - on

Sept. 16, 2009

Re: [Pharo-project] Polymorph - TabIndex and layoutFrames questions

by David Corking

Gary wrote: > There used to be a good description on Bob's Super Swiki, though that seems > to have vanished. This helped me: http://wiki.squeak.org/squeak/2141

Sept. 16, 2009

Re: [Pharo-project] Fwd: Universes? or Metacello meta repository

by Andrey Larionov

My 2 cents. It's very cool what there will be a packaging system. But i think what it should allow distribution not only code, but asets too. Like images, or css (for web application) On Wed, Sep 16, 2009 at 15:59, Michael Robers <mike(a)mjr104.co.uk> wrote: > am interested in learning how we could use metacello. Not for 1.0. > Before we commit to it for 1.1 I think we would need to conduct an > experiment in parallel to get a feel for it. We should also review the > other proposals. Then commit to one proposal for 1.1 1.2 etc and make > the process work. Â Or we could stall 1.1 until we have

Sept. 16, 2009

Re: [Pharo-project] Fwd: Universes? or Metacello meta repository

by Lukas Renggli

> I agree. Universes is cool but: > > - it requires a dedicated server and only few people installed one already > - it only allows one administrator per package description Setting up an Universe server is simple: Just put the XML package definition on some public HTTP server and version it with SVN. I wouldn't bother about the server written in Smalltalk, it is hard to setup and use. You want a consistent Universe anyway, not something where everybody can submit their packages anytime. > - the interface is well... not very nice :-) > - we would need to create a new universe from scratch The purple browser was nice. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 16, 2009

Re: [Pharo-project] Fwd: Universes? or Metacello meta repository

by Michael Robers

I am interested in learning how we could use metacello. Not for 1.0. Before we commit to it for 1.1 I think we would need to conduct an experiment in parallel to get a feel for it. We should also review the other proposals. Then commit to one proposal for 1.1 1.2 etc and make the process work. Or we could stall 1.1 until we have a process in place but I think we will still have fixes coming in we will not want a lag. What do you think? Cheers Mike On 16 Sep 2009, at 10:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi > > I value the idea that when we look for a software (for example SIXX) > we can find a version that is working. In the past we used Universes > and > if was successful. > We cannot not have squeakmap and universe at the same time. > I discussed with damien briefly about that and he told me that we coud > have > a metacello alternative. > Now I wonder if for pharo 1.0 it makes sense. > May be having a nice Universe for pharo would be good and important. > > Dale what do you think? > Do you see metacello working in the story (may be for 1.1)? > Stef > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009