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

Re: [Pharo-project] OB

by Igor Stasenko

i don't see a need to have a mercury input field big. It serves to speed-up the search and from its purpose most times its input will be a few letters long. 2009/3/6 Gary Chambers <gazzaguru2(a)btinternet.com>: > Setting the search text (hResizing) to be rigid and the button bar > (hResizing) Â to be spaceFill should work... > > Regards, Gary > - Show quoted text - > > ----- Original Message ----- > From: "CÃ©drick BÃ©ler" <cdrick65(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Friday, March 06, 2009 3:27 PM > Subject: Re: [Pharo-project] OB > > >>> Don't know how to fix this, so I removed the fixed width. Now it works, >>> but the ugly >>> thing is that mercury panel shrinks in size when more buttons get added. >> >> I don't find it ugly ;)... Actually I finded uglier the long mercury >> panel before. >> >> Maybe having it with a fixed width on the right... (maybe you can use >> an invisible button :), a spacer ?) >> >> Also, it will look a bit nicer if aligned vertically but I don't know >> if possible. >> >> Thanks anyway :) >> >> >> -- >> CÃ©drick >> >> _______________________________________________ >> 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.

March 6, 2009

Re: [Pharo-project] Pharo

by CÃ©drick BÃ©ler

As a simple journeyer, I'm really glad you're part of the team (as several others highly involved) ;) ... Thanks to all, keep the good work in a good atmosphere ! A dynamic language as ST deserves a cool dynamic team ;) Have all a nice week end ! -- CÃ©drick

March 6, 2009

Re: [Pharo-project] [Fwd: Re: [ANN] Preference pragmas]

by Ramon Leon

> Imho, there are already too many meta-models in the squeak > world, just as there are too many event frameworks. OB has one > that defines what properties a node in a tree can take on. > FileList has one that describes what actions can be done to a > file. Preferences has one. Etoys had a huge one, but let's not > even go there. > > I don't know if it belongs in the core (I don't know what the > core is), but it is a basic service I'd expect a lot of > libraries could depend on. > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ Choice is not a bad thing, there is no uber meta model that will suite everyone's needs all of the time. There's nothing wrong with projects creating their own meta model that is suited to exactly what they need. For most things, I find pragmas more than sufficient for static metadata and much lighter weight than Magritte both in code and brain power. There's also the nice synergy of having your metadata actually bound to the things they're representing. This is an advantage pragmas have over Magritte. Magritte has the advantage when the metadata starts to become dynamic but you pay for using it with a much heavier weight code centric approach that separates the metadata from what it's representing. Now you have to maintain a link between the "thing" and the "meta thing" either by either naming patterns or by using pragmas to bind them. These are serious trade-offs to make, it's certainly not a no brainer. Ramon Leon http://onsmalltalk.com

March 6, 2009

[Pharo-project] Pharo

by Gary Chambers

Pharo is looking good, feeling good and getting good. Glad to be involved with the dynamic team. Regards, Gary

March 6, 2009

Re: [Pharo-project] OTChasingInspector preview

by Damien Cassou

On Fri, Mar 6, 2009 at 5:16 PM, Dale Henrichs <dale.henrichs(a)gemstone.com> wrote: > Good ideas about the tooltip and window title, I'll put something in for the next drop ... IIRC, you can use #longDescription or something like that to get a tooltip -- Damien Cassou http://damiencassou.seasidehosting.st

March 6, 2009

Re: [Pharo-project] OTChasingInspector preview

by Dale Henrichs

----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | Having tooltip for the *, 1, # buttons will definitely help. | Alternatively, the title of the window may reflect what is currently | | displayed. | | It looks very good | | Alexandre Alexandre, Good ideas about the tooltip and window title, I'll put something in for the next drop ... Thanks. Dale

March 6, 2009

Re: [Pharo-project] [Fwd: Re: [ANN] Preference pragmas]

by Gary Chambers

True, so many, but none does (or maybe can) do everything to complete satisfaction for all situations... Regards, Gary ----- Original Message ----- From: "Matthew Fulmer" <tapplek(a)gmail.com> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Friday, March 06, 2009 4:00 PM Subject: Re: [Pharo-project] [Fwd: Re: [ANN] Preference pragmas] > On Fri, Mar 06, 2009 at 08:16:30AM -0700, Ramon Leon wrote: >> > >> > Hehe. I've already done that twice now: >> > >> > http://lists.gforge.inria.fr/pipermail/pharo-project/2009-March/006202.html >> > >> > prefTheme >> > <preference category: 'User Interface'> >> > ^ MASingleOptionDescription new >> > options: #( 'Vistary' 'Watery' 'Squeak' 'Soft Squeak' ); >> > reference: MAStringDescription new; >> > autoAccessor: 'theme'; >> > label: 'Theme'; >> > priority: 40; >> > beSorted; >> > yourself >> > >> > -- >> > Matthew Fulmer -- http://mtfulmer.wordpress.com/ >> > >> >> What happened to trying to slim down the image? Do we really want to >> introduce a dependency on a large external library or gasp, include it in >> the core, just for managing preferences? I'd much rather see something >> simpler done with pragmas. Just because Magritte can be used for >> something >> doesn't mean it should. Just because Magritte is a meta model also >> doesn't >> invalidate all future uses of other meta models. If preferences ends up >> doing something like a small Magritte lite that looks kinda similar in >> some >> respects, it doesn't mean it was wrong to not use Magritte. > > Imho, there are already too many meta-models in the squeak > world, just as there are too many event frameworks. OB has one > that defines what properties a node in a tree can take on. > FileList has one that describes what actions can be done to a > file. Preferences has one. Etoys had a huge one, but let's not > even go there. > > I don't know if it belongs in the core (I don't know what the > core is), but it is a basic service I'd expect a lot of > libraries could depend on. > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 6, 2009

Re: [Pharo-project] [Fwd: Re: [ANN] Preference pragmas]

by Matthew Fulmer

On Fri, Mar 06, 2009 at 08:16:30AM -0700, Ramon Leon wrote: > > > > Hehe. I've already done that twice now: > > > > http://lists.gforge.inria.fr/pipermail/pharo-project/2009-March/006202.html > > > > prefTheme > > <preference category: 'User Interface'> > > ^ MASingleOptionDescription new > > options: #( 'Vistary' 'Watery' 'Squeak' 'Soft Squeak' ); > > reference: MAStringDescription new; > > autoAccessor: 'theme'; > > label: 'Theme'; > > priority: 40; > > beSorted; > > yourself > > > > -- > > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > > > What happened to trying to slim down the image? Do we really want to > introduce a dependency on a large external library or gasp, include it in > the core, just for managing preferences? I'd much rather see something > simpler done with pragmas. Just because Magritte can be used for something > doesn't mean it should. Just because Magritte is a meta model also doesn't > invalidate all future uses of other meta models. If preferences ends up > doing something like a small Magritte lite that looks kinda similar in some > respects, it doesn't mean it was wrong to not use Magritte. Imho, there are already too many meta-models in the squeak world, just as there are too many event frameworks. OB has one that defines what properties a node in a tree can take on. FileList has one that describes what actions can be done to a file. Preferences has one. Etoys had a huge one, but let's not even go there. I don't know if it belongs in the core (I don't know what the core is), but it is a basic service I'd expect a lot of libraries could depend on. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

March 6, 2009

Re: [Pharo-project] OB

by Gary Chambers

Setting the search text (hResizing) to be rigid and the button bar (hResizing) to be spaceFill should work... Regards, Gary ----- Original Message ----- From: "CÃ©drick BÃ©ler" <cdrick65(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, March 06, 2009 3:27 PM Subject: Re: [Pharo-project] OB >> Don't know how to fix this, so I removed the fixed width. Now it works, >> but the ugly >> thing is that mercury panel shrinks in size when more buttons get added. > > I don't find it ugly ;)... Actually I finded uglier the long mercury > panel before. > > Maybe having it with a fixed width on the right... (maybe you can use > an invisible button :), a spacer ?) > > Also, it will look a bit nicer if aligned vertically but I don't know > if possible. > > Thanks anyway :) > > > -- > CÃ©drick > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 6, 2009

Re: [Pharo-project] OB

by CÃ©drick BÃ©ler

> Don't know how to fix this, so I removed the fixed width. Now it works, but the ugly > thing is that mercury panel shrinks in size when more buttons get added. I don't find it ugly ;)... Actually I finded uglier the long mercury panel before. Maybe having it with a fixed width on the right... (maybe you can use an invisible button :), a spacer ?) Also, it will look a bit nicer if aligned vertically but I don't know if possible. Thanks anyway :) -- CÃ©drick

March 6, 2009