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

Re: [Pharo-project] [ANN][Dev-Images] February 2009 versions

by Bill Schwab

Damien, If it is really not a problem, I would like to try it. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> damien.cassou(a)gmail.com 02/10/09 8:16 AM >>> On Tue, Feb 10, 2009 at 1:58 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Is there a Pharo-web link? Apologies if I'm missing the obvious. I'm not generating pharo-web images because nobody asked as far as I remember. Do you want one? (that won't cost much don't worry :-)) -- Damien Cassou http://damiencassou.seasidehosting.st _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 10, 2009

Re: [Pharo-project] another slice for popups cleaning and somequestions

by Gary Chambers

The UIManager remains, at present, netural to the specific implementation, be it Polymorph, Morphic or otherwise. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr>; <alain.plantec(a)free.fr> Sent: Monday, February 09, 2009 8:59 AM Subject: Re: [Pharo-project] another slice for popups cleaning and somequestions > > On Feb 8, 2009, at 11:57 PM, Alain Plantec wrote: > >> Hi all, >> I've uploaded another slice for popup and co cleaning >> (SLICE-MorePopUpAndCustomMenuCleaning-alain_plantec.1) >> - it Removes last PopUpMenu references. >> - it Removes some of CustomMenu uses (wherever it is possible to >> replace >> it with a simpler UIManager dialog). > > Excellent >> >> >> I've three questions: >> - EmphasizedMenu is never used, can we remove it ? > > I imagine > >> - MorphicUIManager is subclassed by PSUIManager which is now the >> default UIManager. Several MorphicUImanager methods are >> redefined in PSUIManager. So I guess one can simply remove >> MorphicUIManager versions. Is it ok to do so ? (as an example, >> #chooseDirectory:from:, in MorphicUIManager, the code is using >> FileList >> but now we have the PSUIManager version) > > this is the question of how far Polymorph should be integrated. > For me I would really remove the old code when it is not good. > > Ideally I would like to see what can be moved from polymorph to base > Morphic > in the case we would like to have several Polymorph like frameworks. > Then I would clean part of Morphic that are not used or left over of > experiements. > > But this would be good to discuss that > >> - last unrelated question, I've also seen that ListParagraph is never >> used, can we remove it ? > > Do not know > >> >> >> now I am about to see how to kill MVCMenuMorph > > Good >> >> >> cheers >> alain >> >> _______________________________________________ >> 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

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by Gary Chambers

----- Original Message ----- From: "Damien Pollet" <damien.pollet(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, February 08, 2009 1:52 PM Subject: Re: [Pharo-project] Call for UI gripes > On Sat, Feb 7, 2009 at 17:58, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: >> I suppose I could suggest replacing some of the button bars with more >> compact iconic toolbars. Things like debugging over, into, etc. lend >> themselves well to that. The world menu will not make much sense if we >> ever get one window per shell. > > it was probably already said, but could the other buttons in the > browser use the squarish buttons from the task bar rather than the > current rounded ones that waste a bit of space ? > At present the space to the sides must be reserved as the rounded state of the buttons is not known at the time of creation/initial-layout. I'll have a go at making it more adaptable. >> The biggest concern I have right now is speed. I'm not saying Pharo is >> too slow; I'm simply admitting that I do not know whether it is fast >> enough for some of the things I want to do. > > Agreed. Actually I'm wondering if a very sleek minimalistic theme > would be niceâ¦ flat colors, simple lines, very limited complicated > stuff like gradients or shadersâ¦ provided the typography, widget > spacing, and color choices are done with taste, I think it can look > quite nice, and would even be more usable than a more flashy theme. > > -- > 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

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by Gary Chambers

Rounded things are tricky to do with no direct support in canvas/balloon. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, February 08, 2009 1:55 PM Subject: Re: [Pharo-project] Call for UI gripes > I'm also want to play with rounding and compare the efficiency of > drawing an initially rounded shape (by using curves) instead of > hacking , which CornerRounder does. > > I took a single rounded button and measured how fast it get drawn and > what parts of drawing process takes what time: > > 100 times > - fulldraw 80ms > - (1) draw 18ms (simple fill a rectangle) > - (2) fulldraw w/o rounding 51ms (almost same as a fulldraw but w/o > use of CorderRounder) > > so, CornerRounder takes 30ms for itself (from total 80ms). > I think if we initially draw a rounded shape, we could have better > numbers , i hoping that drawing a filled rectangular shape and filled > rounded rectangular shape could have much less difference (much less > than 30ms). > It's a bit expensive to spend 3/8 of total rendering time for such > little fancy thing :) > > 2009/2/8 Igor Stasenko <siguctua(a)gmail.com>: >> 2009/2/8 Gary Chambers <gazzaguru2(a)btinternet.com>: >>> I'll make the drop shadows themable for system windows. >>> The default way Morphic does drop shadows is quite inefficient. >>> >> >> Right, i think it would be wise to provide own implementation of >> drawDropShadowOn: for SystemWindow, to draw simple rectangle (or group >> of rectangles to avoid excessive fills) since we know that >> systemwindow is rectangular beforehead. >> >> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Igor Stasenko" <siguctua(a)gmail.com> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Saturday, February 07, 2009 7:23 PM >>> Subject: Re: [Pharo-project] Call for UI gripes >>> >>> >>>> 2009/2/7 Ramon Leon <ramon.leon(a)allresnet.com>: >>>>>> The biggest concern I have right now is speed. I'm not >>>>>> saying Pharo is too slow; I'm simply admitting that I do not >>>>>> know whether it is fast enough for some of the things I want to do. >>>>> >>>>> +10 to this. >>>>> >>>>> The UI is looking really great lately, but overall the experience is >>>>> it's >>>>> just too slow. Cracking open a raw squeak base image reminds me how >>>>> snappy >>>>> the UI used to be. Not really complaining, it's totally bearable, but >>>>> it'd >>>>> sure be nice if the pretty UI was quick and snappy, and you are >>>>> asking. >>>>> >>>> Sure thing >>>> MessageTally spyOn:[self fullDrawOn: World assuredCanvas] "where self >>>> is an OB system window morph" >>>> >>>> 16.7% {10ms} BalloonEngine>>copyLoopFaster >>>> 11.7% {7ms} SimpleBorder>>frameRectangle:on: >>>> 6.7% {4ms} Array(SequenceableCollection)>>select: >>>> 5.0% {3ms} ByteString(String)>>= >>>> 5.0% {3ms} SmallInteger(Number)>>to:by:do: >>>> 5.0% {3ms} GrafPort(BitBlt)>>primDisplayString:from:to:map:xTable:kern: >>>> 5.0% {3ms} BorderStyle>>frameRectangle:on: >>>> 3.3% {2ms} ByteSymbol>>species >>>> 3.3% {2ms} ByteString class(String class)>>new: >>>> >>>> total 61ms. >>>> >>>> some hot points crying to be optimized: >>>> cache the OBMonticelloPackageNode>>classCategories , which get >>>> rebuilt each time you draw the window. >>>> this can make following numbers much smaller: >>>> 5.0% {3ms} ByteString(String)>>= >>>> 6.7% {4ms} Array(SequenceableCollection)>>select: >>>> 3.3% {2ms} ByteString class(String class)>>new: >>>> >>>> Making SystemWindow>>drawDropShadowOn: to do nothing makes a >>>> difference: >>>> >>>> [10 timesRepeat: [self fullDrawOn: World assuredCanvas ]] timeToRun >>>> with shadows: 530 >>>> without: 473 >>>> ~ 10% speedup >>>> >>>> Changing the theme makes some difference (no shadows/with shadows): >>>> - Watery 2: 50/60 ms >>>> - Standard Squeak: 38/43 ms >>>> - Soft Squeak: 46/55 ms >>>> - Vistary: 56/62ms >>>> (keep in mind these numbers are polluted with messageTally) >>>> >>>> As to me, the theme variancy is quite acceptable - a most complex >>>> theme (with transulency) is drawn just 50% slower than most simple >>>> one. >>>> >>>> As for, >>>> 3.3% {2ms} ByteString class(String class)>>new: >>>> >>>> Total count of ByteString>>new: calls during >>>> GlobalCounter reset. >>>> self fullDrawOn: World assuredCanvas. >>>> GlobalCounter counters copy inspect >>>> >>>> is 7146, >>>> which again makes me look suspicious at OB here.. Hey! Are we drawing, >>>> or processing a text?!?! >>>> >>>> >>>>> Ramon Leon >>>>> http://onsmalltalk.com >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 10, 2009

Re: [Pharo-project] [ANN][Dev-Images] February 2009 versions

by Damien Cassou

On Tue, Feb 10, 2009 at 1:58 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Is there a Pharo-web link? Apologies if I'm missing the obvious. I'm not generating pharo-web images because nobody asked as far as I remember. Do you want one? (that won't cost much don't worry :-)) -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by Bill Schwab

Sig, Is it something that could be themed? Then it could be present in the "expensive" themes and left out for a limited theme that would hopefully still look nice, have robust focus behavior, but seeks to be as fast as possible. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> siguctua(a)gmail.com 02/10/09 7:11 AM >>> 2009/2/10 David RÃ¶thlisberger <squeak(a)webcitas.ch>: > Hi Igor, > >> OB is quite complex thing, and its hard to understand what it does for >> outsider :) >> >> I just identified a few points, which can improve rendering speed by a >> certain amount: > [...] >> - default. >> 60 ms >> >> - with override in SystemWindow>>drawDropShadowOn: aCanvas to do nothing: >> 51 ms >> >> - with override in OBMonticelloPackageNode>>classCategories to return >> cached collection >> 45 ms >> > > I incorporated into OB a patch that is following your idea concerning caching of > class cats in package nodes. I did it differently than you but the results are even > better now. > Great! In my patch i didn't care about correctness or whatever, it was simply to outline what possible can be done to improve rendering speed. > Can you take care of integrating the SystemWindow patch into Pharo? > you mean override of SystemWindow>>drawDropShadowOn: ? Its not really correct override. Shadow should be drawn, if it there. And by default , to draw shadow, it using Morph>>drawOn: method with special shadow canvas. For system window it means that a rectangular area with dimensions of morph is filled with shadow color, shifted by shadowOffset. To improve its speed, we could clip a shadow rectangle to not visit pixels which is covered my system window contents, only pixels which are outside of it and 'dropping' shadow. I can implement such method, but concerning integration - i'm not in charge here :) What is interesting about shadows, that by default a shadow offset is 1 pixel wide: shadowOffset: 1@1 this means that unless you using magnifying glass on you display, you can't really tell if there shadow drawn or not. Since visual difference is minimal, do anyone can tell, why wasting so much CPU cycles on it? :) > Thanks, > David > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 10, 2009

Re: [Pharo-project] Plugin organization

by StÃ©phane Ducasse

> > I feel the same about it. Also I don't particularly like the solution > with the space, and/or camel case labels (like "Collections- > KernelDropTests"). Michael, what would you suggest as a scheme? How > about the following solution I suggested in a previous mail? > > Kernel-Numbers > Kernel-Traits > Kernel-Compiler > ... > Libraries-Collections > Libraries-Regex > Libraries-Network > ... > Tests-Kernel > Tests-Libraries > ... > > In the class categories we could still have a fine-grained structure > for tests, like > > Tests-Kernel-Numbers > Tests-Kernel-Traits > Tests-Libraries-Collections > ... > > Like this we have sort of a "tests close to the code" since the last > part, e.g., "Libraries-Collections" would match the category structure > of the implementation. Basically it's just that we prefix the > categories with "Test-" and that we have a coarse Top level structure. > Stef, wouldn't that also (partly) satisfy your wish of organizing > tests close to the code? I do not like it but it looks like the best compromise with the tools we have right now For me it goes against OOP and encapsulation but....there is a pattern matching ugly trick. Stef

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by StÃ©phane Ducasse

> >>> >>> > > I can implement such method, but concerning integration - i'm not in > charge here :) Our motto is if code is there and people agree this is integrated :) So go :) > > > What is interesting about shadows, that by default a shadow offset is > 1 pixel wide: > shadowOffset: 1@1 > > this means that unless you using magnifying glass on you display, you > can't really tell if there shadow drawn or not. > Since visual difference is minimal, do anyone can tell, why wasting so > much CPU cycles on it? :) sounds small indeed. Stef > > > >> Thanks, >> David >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 10, 2009

Re: [Pharo-project] Plugin organization

by Michael Rueger

Adrian Lienhard wrote: > KernelDropTests"). Michael, what would you suggest as a scheme? How > about the following solution I suggested in a previous mail? IIRC that was exactly what I suggested as well :-) So I'm all for it :-) Michael > > Kernel-Numbers > Kernel-Traits > Kernel-Compiler > ... > Libraries-Collections > Libraries-Regex > Libraries-Network > ... > Tests-Kernel > Tests-Libraries > ... > > In the class categories we could still have a fine-grained structure > for tests, like > > Tests-Kernel-Numbers > Tests-Kernel-Traits > Tests-Libraries-Collections > ... > > Like this we have sort of a "tests close to the code" since the last > part, e.g., "Libraries-Collections" would match the category structure > of the implementation. Basically it's just that we prefix the > categories with "Test-" and that we have a coarse Top level structure. > Stef, wouldn't that also (partly) satisfy your wish of organizing > tests close to the code? > > Adrian > >> >> Michael >> >> _______________________________________________ >> 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 >

Feb. 10, 2009

Re: [Pharo-project] [ANN][Dev-Images] February 2009 versions

by Bill Schwab

Damien, Is there a Pharo-web link? Apologies if I'm missing the obvious. Thanks! Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> damien.cassou(a)gmail.com 02/10/09 5:57 AM >>> Hi, I've just uploaded new dev and web images based on Squeak3.9.1-7075, Squeak3.10.2-7179 and Pharo0.1-10231. More information and download: http://damiencassou.seasidehosting.st/Smalltalk/squeak-dev Pharo-based images can be downloaded at: http://code.google.com/p/pharo/wiki/Downloads?tm=2 Download statistics at http://damiencassou.dabbledb.com/publish/dev-imagesdownloads Changes in this version: --------------------------- - Pharo images are based on version 10231 - Polymorph fixes (by Gary Chambers) - OmniBrowser changes (by David RÃ¶thlisberger) - Refactored auto-selection of list items to be easier extensible - Extended and improved traits integration (various new features) - Integrated OB patches done by various people - Improved compatibility to Polymorph (button colors, scrollbars) - Several defects corrected - Magritte and Pier have been updated to version 1.1 (by Lukas Renggli and Tudor Girba) Contained packages: ------------------------ This image contains the following packages (some packages are only in the squeak-web image or 3.10-based images): Aida version 5.6 Algernon version 1.2 AST version 160 AutomaticMethodCategorizer version 0.25 AutomaticMethodCategorizerOB version 0.2 DynamicBindings version 2.7 eCompletion version 0.102 eCompletion-Traits version 0.1 eCompletionOmniBrowser version 0.5 Installer version 4.3.284 KomHttpServer version 7.0.30 KomServices version 1.12 Magritte-Model version 1.1.331 Magritte-Seaside version 1.1.283 Magritte-Tests version 1.1.148 OB-Enhancements version 0.292 OmniBrowser version 0.436 OmniBrowser-Algernon version 0.5 OmniBrowser-Full version 0.27 OmniBrowser-Morphic version 0.74 OmniBrowser-Refactory version 117 OmniBrowser-Regex version 0.9.1 OmniBrowser-Standard version 0.389 Pier version current Pier-Blog version 1.1.103 Pier-Documents version 1.1.7 Pier-EditorEnh version 1.1.17 Pier-Model version 1.1.263 Pier-Seaside version 1.1.331 Pier-Security version 1.1.119 Pier-Tests version 1.1.116 Polymorph EventEnhancements version 1.1 Polymorph Geometry version 1.1 Polymorph TaskbarIcons version 1.0 Polymorph ToolBuilder version 1.2 Polymorph Tools Diff version 1.3 Polymorph Widgets version 1.3 Refactoring Core version 17 RoelTyper version 0.60 RSRSS2 version 2.8.3.11 Scriptaculous version 2.8.3.242 ScriptManager version 0.6 Seaside version 2.8.3.572 Seaside-Adapters-Core version pmm.2.mcz Seaside-Adapters-Swazoo version 9 Seaside-Squeak-Adapters version pmm.3.mcz SeasideAdaptersCompatibility version pmm.1.mcz Shout version 3.15-tween.72 ShoutWorkspace version 1-tween.4 SmaCC runtime version 13 Sport version 2.31 Squeak dev packages version 0.27 Squeak dev packages beta version 0.32 Squeak web packages version 0.2 SUnit-improved version 4.0.118 SUnitGUI-improved version 4.0.50 Swazoo version 2.1 Universes version 51 Universes OmniBrowser version 0.38 VBRegex version 1.9 YAXO version 14 -- Damien Cassou http://damiencassou.seasidehosting.st _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 10, 2009