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

Re: [Pharo-project] Call for UI gripes

by Gary Chambers

----- Original Message ----- From: "Bill Schwab" <BSchwab(a)anest.ufl.edu> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, February 10, 2009 2:00 PM Subject: Re: [Pharo-project] Call for UI gripes > Gary, > > Space to sides of the buttons?? Perhaps unrelated, but I have been > thinking of something similar while poking at Damien's recent dev image. > Because Watery2 has more-rounded-than-usual buttons some extra space is required to avoid the text/morph apearing outside the button image. > Bottom line, I switched to Soft Squeak and was pleased to see that the OB > buttons didn't look quite as (pardon me) UGLY<g> (sorry, but that needed > to be said) as they did not long ago. It's getting quite nice. The > problem was not the buttons so much as an awkward combination of shape, > size and mismatching background color behind them. It would help even > more to "do the same thing to the code buttons that has been done to the > classes buttons." I hope that makes some sense. Take a look at the > browser in soft squeak. Note two rows of buttons "in the middle." The > upper row looks nicer than the lower row; a tweak of background color > would help a lot, I think?? > David and I are working on it. I have a few more suggestions for him soon now that I've seen the latest dev image. He has switched to using PluggableButtonMorphPlus which supports enablement but has left the "old style" state selectors in place which affects the button colours. > Soft squeak is a nice theme, and (I assume OB changes) have helped it a > lot; it was hard on the eyes for a little while. In replying to something > not long ago, you mentioned the range of themes and how they differ in > color handling. In particular, Soft Squeak lets the tool colors show > through. I have an idea for using that to advantage. The clay rose tint > to the debugger is great - it does just the right psychological thing > without being too strong. The browser color could be nicer; of course it > can be set, but I think we should find another default. I recall playing > with blues some time ago, but it can't be too strong due to the label text > color. Anybody have any ideas? > The window model colours for themes that support the behaviour can be set in the preference browser. > While I might be setting us up for even more drawing and a speed hit > (ignore this if you fear that), it might be nice to render the > tool-specific title bar icon in the task bar. That way, we could use the > same color for browsers and workspaces, and still have them stand out by > icon. The debugger would keep its color, as might the preference browser > and other "special purpose" tools. > If Polymorph-TaskbarIcons is loaded you should get different icons for many of the standard tools. I'll chat with David about getting some in for OB. This icon also appears in place for the "menu" button on window title bars (excepti9ng StandardSqueak ;-) ). > Just some ideas. Thanks for the great work! > > 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 8:25 AM >>> > > ----- 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 > > > _______________________________________________ > 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

[Pharo-project] [ANN] 10232 mime fixe + pop up cleans...

by StÃ©phane Ducasse

- Remove the last PopUpMenu references. - Remove some of the CustomMenu uses (wherever it is possible to replace it with a simple UIManager dialog). - Mime mike kind of fixes

Feb. 10, 2009

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

by Bill Schwab

Damien, Thanks for trying! Would this stop me from installing Seaside and Magritte, or does it happen later? 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 9:23 AM >>> On Tue, Feb 10, 2009 at 2:29 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > If it is really not a problem, I would like to try it. I can't because of bug 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] Problem with linux VM and Pharo

by Bill Schwab

Damien, I am not seeing that, but I am probably not using the right VM anyway: bills@Ubuntu-9905:~$ squeak -version 3.9-8 #5 Tue Oct 10 11:56:09 PDT 2006 gcc 4.0.3 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux ubuntu 2.6.15-27-386 #1 PREEMPT Sat Sep 16 01:51:59 UTC 2006 i686 GNU/Linux default plugin location: /usr/local/lib/squeak/3.9-8/*.so 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 9:15 AM >>> Every 5 minutes or so, my VM crashes and prints: squeak: /tmp/squeak-svn/platforms/unix/vm/sqUnixMemory.c:172: uxGrowMemoryBy: Assertion `newDelta >= 0' failed. Aborted I'm using Squeak VM from SVN. Does that happen to anyone else? -- 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 2:29 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > If it is really not a problem, I would like to try it. I can't because of bug http://code.google.com/p/pharo/issues/detail?id=520 -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 10, 2009

[Pharo-project] Can't install Pier on Pharo

by Damien Cassou

http://code.google.com/p/pharo/issues/detail?id=520 -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by Igor Stasenko

2009/2/10 Bill Schwab <BSchwab(a)anest.ufl.edu>: > 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. > A shadow drawing can be controlled by property #hasDropShadow of morph. To allow theme to decide it, morph should ask theme about 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 > >>>> 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 > > _______________________________________________ > 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.

Feb. 10, 2009

[Pharo-project] Problem with linux VM and Pharo

by Damien Cassou

Every 5 minutes or so, my VM crashes and prints: squeak: /tmp/squeak-svn/platforms/unix/vm/sqUnixMemory.c:172: uxGrowMemoryBy: Assertion `newDelta >= 0' failed. Aborted I'm using Squeak VM from SVN. Does that happen to anyone else? -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by Bill Schwab

Gary, Space to sides of the buttons?? Perhaps unrelated, but I have been thinking of something similar while poking at Damien's recent dev image. Bottom line, I switched to Soft Squeak and was pleased to see that the OB buttons didn't look quite as (pardon me) UGLY<g> (sorry, but that needed to be said) as they did not long ago. It's getting quite nice. The problem was not the buttons so much as an awkward combination of shape, size and mismatching background color behind them. It would help even more to "do the same thing to the code buttons that has been done to the classes buttons." I hope that makes some sense. Take a look at the browser in soft squeak. Note two rows of buttons "in the middle." The upper row looks nicer than the lower row; a tweak of background color would help a lot, I think?? Soft squeak is a nice theme, and (I assume OB changes) have helped it a lot; it was hard on the eyes for a little while. In replying to something not long ago, you mentioned the range of themes and how they differ in color handling. In particular, Soft Squeak lets the tool colors show through. I have an idea for using that to advantage. The clay rose tint to the debugger is great - it does just the right psychological thing without being too strong. The browser color could be nicer; of course it can be set, but I think we should find another default. I recall playing with blues some time ago, but it can't be too strong due to the label text color. Anybody have any ideas? While I might be setting us up for even more drawing and a speed hit (ignore this if you fear that), it might be nice to render the tool-specific title bar icon in the task bar. That way, we could use the same color for browsers and workspaces, and still have them stand out by icon. The debugger would keep its color, as might the preference browser and other "special purpose" tools. Just some ideas. Thanks for the great work! 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 8:25 AM >>> ----- 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 _______________________________________________ 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

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

Feb. 10, 2009