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

Re: [Pharo-project] Call for UI gripes

by Gary Chambers

For taskbar/window menu images? If so 16x16 and take your pick of all the common tools/windows. The ones we currently use are shown in the attached png (mostly the MenuIcons small variety). Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, February 10, 2009 2:59 PM Subject: Re: [Pharo-project] Call for UI gripes Hi gary do you need some icons? What size? because I should draw some of them for david too. Stef On Feb 10, 2009, at 2:32 PM, Gary Chambers wrote: > The about-to-be-put-on-SqueakSource version of Polymorph now has theme > rendered drop shadow for SystemWindows. > A small improvement in speed since CornerRounder still applies to > the actual > window morph. > > Regards, Gary > > > ----- Original Message ----- > From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, February 10, 2009 12:11 PM > Subject: Re: [Pharo-project] Call for UI gripes > > >> 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 > > > _______________________________________________ > 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 Bill Schwab

Gary, I need to play more later, but that appears to make a significant difference. 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 >>> gazzaguru2(a)btinternet.com 02/10/09 9:34 AM >>> While we are at it I have noticed that SystemWindow>>passivate deliberately draw the World (old behaviour). Having done a few simple benchmarks it seems that better performance is achieved when it is not drawn then, in contradiction to the implication of "clean damage now, so dont merge this rect with new top window". That's on my machine. Can some of you give it a go with the "self world displayWorld" removed and we'll see if it a worthwhile thing to change? Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, February 10, 2009 12:11 PM Subject: Re: [Pharo-project] Call for UI gripes > 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 _______________________________________________ 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 StÃ©phane Ducasse

Hi gary do you need some icons? What size? because I should draw some of them for david too. Stef On Feb 10, 2009, at 2:32 PM, Gary Chambers wrote: > The about-to-be-put-on-SqueakSource version of Polymorph now has theme > rendered drop shadow for SystemWindows. > A small improvement in speed since CornerRounder still applies to > the actual > window morph. > > Regards, Gary > > > ----- Original Message ----- > From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, February 10, 2009 12:11 PM > Subject: Re: [Pharo-project] Call for UI gripes > > >> 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 > > > _______________________________________________ > 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

Indeed. For the drop shadow I am sneakily using the RoundedBorder (part of Polymorph) for the bottom-right corner when that corner is rounded for a window. No antialisaing, of course, but looks ok-ish... Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, February 10, 2009 2:43 PM Subject: Re: [Pharo-project] Call for UI gripes > 2009/2/10 Gary Chambers <gazzaguru2(a)btinternet.com>: >> Rounded things are tricky to do with no direct support in canvas/balloon. >> > > I did some experimenting to draw a rounded rects using balloon bezier > curves.. > I was disappointed in speed :( > > Moreover, if border is drawn w/o antialiasing, it looks very ugly and > inaccurate. > > Also, balloon using different bordering logic. It does not insets > border inside a shape's area, instead it using a shape segment as a > guide to draw a border around it , i.e. if you drawing a horizontal > line at y=0 with border width = 3, then border will fill y=-1, y=0 , > y=1 . > > You can look a results on attached images. > A code used to draw them: > (RoundedRectShape new rect: (10@10 corner: 100@100)) drawOn: World > assuredCanvas > > > -- > 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] Can't install Pier on Pharo

by StÃ©phane Ducasse

MIMEDocument class>>resetMIMEdatabase seems the faulty one On Feb 10, 2009, at 3:23 PM, Damien Cassou wrote: > http://code.google.com/p/pharo/issues/detail?id=520 > > -- > 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] [ANN][Dev-Images] February 2009 versions

by Damien Cassou

On Tue, Feb 10, 2009 at 3:28 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Thanks for trying! Would this stop me from installing Seaside and > Magritte, or does it happen later? Let me try again with 10232. -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 10, 2009

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

by Damien Cassou

On Tue, Feb 10, 2009 at 3:28 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Thanks for trying! Would this stop me from installing Seaside and > Magritte, or does it happen later? You can try replacing 'Pier' by 'Seaside' in the script and see what happens. -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 10, 2009

[Pharo-project] Workspace API

by Keith Hodges

http://bugs.squeak.org/view.php?id=5669 I requested then implemented a reasonable API for opening Workspaces on strings and files. I now find that pharo has implemented incompatible versions of the same. Workspace openContents: 'blah'. or Workspace new contents: 'blah'; label: 'Title'; open. Keith

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by Igor Stasenko

2009/2/10 Gary Chambers <gazzaguru2(a)btinternet.com>: > Rounded things are tricky to do with no direct support in canvas/balloon. > I did some experimenting to draw a rounded rects using balloon bezier curves.. I was disappointed in speed :( Moreover, if border is drawn w/o antialiasing, it looks very ugly and inaccurate. Also, balloon using different bordering logic. It does not insets border inside a shape's area, instead it using a shape segment as a guide to draw a border around it , i.e. if you drawing a horizontal line at y=0 with border width = 3, then border will fill y=-1, y=0 , y=1 . You can look a results on attached images. A code used to draw them: (RoundedRectShape new rect: (10@10 corner: 100@100)) drawOn: World assuredCanvas -- Best regards, Igor Stasenko AKA sig.

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by Gary Chambers

While we are at it I have noticed that SystemWindow>>passivate deliberately draw the World (old behaviour). Having done a few simple benchmarks it seems that better performance is achieved when it is not drawn then, in contradiction to the implication of "clean damage now, so dont merge this rect with new top window". That's on my machine. Can some of you give it a go with the "self world displayWorld" removed and we'll see if it a worthwhile thing to change? Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, February 10, 2009 12:11 PM Subject: Re: [Pharo-project] Call for UI gripes > 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