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

Re: [Pharo-project] OB

by David RÃ¶thlisberger

>> What other packages have you loaded? > > The whole dev-image, generated from scratch. hm, maybe then it's actually caused by the interplay with another package that I haven't loaded. I will look at that. For the moment I'd say just use the versions in the Universe to build the dev images. They work but have this little glitch I mentioned that the mercury panel shrinks when more buttons get loaded dependent on the selected entity. David

March 6, 2009

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

by Ramon Leon

> > 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. Ramon Leon http://onsmalltalk.com

March 6, 2009

Re: [Pharo-project] OB

by Damien Cassou

On Fri, Mar 6, 2009 at 3:33 PM, David RÃ¶thlisberger <squeak(a)webcitas.ch> wrote: > >>> I just wanted to fix the width of the mercury panel, but this doesn't seem to work in >>> Pharo. >> >> It also doesn't work on Squeak 3.9. > > For me it worked well, like a charm. > What was the behavior you got in Squeak? The text input recovered the buttons. > What other packages have you loaded? The whole dev-image, generated from scratch. -- Damien Cassou http://damiencassou.seasidehosting.st

March 6, 2009

Re: [Pharo-project] OB

by David RÃ¶thlisberger

>> I just wanted to fix the width of the mercury panel, but this doesn't seem to work in >> Pharo. > > It also doesn't work on Squeak 3.9. For me it worked well, like a charm. What was the behavior you got in Squeak? What other packages have you loaded? >> The width specified for one component in table layout doesn't prevent the next >> cell to take the same space... >> 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. > > Could you please update the universe? I already did that. OmniBrowser-Morphic 0.84? David

March 6, 2009

Re: [Pharo-project] OB

by Damien Cassou

On Fri, Mar 6, 2009 at 2:58 PM, David RÃ¶thlisberger <squeak(a)webcitas.ch> wrote: > I just wanted to fix the width of the mercury panel, but this doesn't seem to work in > Pharo. It also doesn't work on Squeak 3.9. > The width specified for one component in table layout doesn't prevent the next > cell to take the same space... > 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. Could you please update the universe? -- Damien Cassou http://damiencassou.seasidehosting.st

March 6, 2009

Re: [Pharo-project] OB

by David RÃ¶thlisberger

I just wanted to fix the width of the mercury panel, but this doesn't seem to work in Pharo. The width specified for one component in table layout doesn't prevent the next cell to take the same space... 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. David > yes confirmed > (nb I like having buttons there). > > Cheers, > > 2009/3/6 Alexandre Bergel <Alexandre.Bergel(a)inria.fr>: >> Hi David, >> >> it seems that your last improvement of OB (especially the one defining >> the width of the mercury input field) does not work properly. The >> input field is above the buttons. >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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

[Pharo-project] Application based preference (external)

by CÃ©drick BÃ©ler

I was just wandering if we could use the framework in development to deal with preference/settings on an application base. I mean, for my app, I have say 10 parameters (implemented class side) and I want to collect them so as build a preference editor in seaside (or whatever, aida, morphic...). How would you do ? use the new preference stuff (maybe another class - ExtAppPreference) or something else... Thanks -- CÃ©drick

March 6, 2009

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

by Gary Chambers

----- Original Message ----- From: "Norbert Hartl" <norbert(a)hartl.name> To: <Pharo-project(a)lists.gforge.inria.fr>; <alain.plantec(a)free.fr> Sent: Friday, March 06, 2009 11:22 AM Subject: Re: [Pharo-project] [Fwd: Re: [ANN] Preference pragmas] > On Fri, 2009-03-06 at 12:02 +0100, Alain Plantec wrote: >> Matthew Fulmer a Ã©crit : >> > On Fri, Mar 06, 2009 at 10:36:13AM +0100, Alain Plantec wrote: >> > >> >> themePreference >> >> <preference> >> >> ^ ThemePreference >> >> ifNil: [ThemePreference := MultiplePreferenceValue >> >> name: 'UITheme' >> >> description: 'The theme to use for UI look and >> >> feel' >> >> parent: #uiPreferenceNode >> >> type: #UITheme >> >> default: UIThemeWatery2 >> >> values: { >> >> FixedPreferenceValue >> >> name: 'Standard Squeak' >> >> description: 'Standard Squeak style' >> >> type: #UITheme >> >> >> >> value: UIThemeStandardSqueak. >> >> FixedPreferenceValue >> >> name: 'Watery 2' >> >> description: 'Similar to a nice OS' >> >> type: #UITheme >> >> value: UIThemeWatery2}] >> >> >> > >> > >> Hi Matthew, >> > You're really just inventing a half-baked Magritte now. >> Surely, but, for now, Magritte is not in the base system. >> Maybe you can send some advices or ideas about how we can improve >> the preference system. >> >> And the <preference:ziag:zig:> way is still a solution we can adopt back >> if the pharo community prefers it. >> >> > Do >> > yourself a favor and use the real thing. Magritte is far more >> > descriptive and far less verbose than anything you have yet >> > presented. Magritte also already knows how to automatically create both >> > seaside and morphic forms out of a field description. It also >> > knows more ways to look up a field than just selector and block. >> > >> Anyway, it seems very interesting and I would like to learn a bit about >> Magritte even it is not possible to use it for preferences. >> As an example, could you explain how you specify the themePreference >> with Magritte ? >> Maybe it can help us to improve our implementation. >> Thanks >> alain >> > I'm not sure but I'm starting to understand what Matthew wanted. > I think the description would like this > > descriptionThemePreference > ^ MASingleOptionDescription new > selectorAccessor: #themePreference; > label: 'The theme to use for UI look and feel'; > reference: MAClassDescription new; > options: {UIThemeStandardSqueak. UIThemeWatery2}; > default: UIThemeWatery2; > priority: 1000; > yourself > > Hmmm, I'm not sure if I should revoke my former mail :) > > Norbert > Or even: descriptionThemePreference ^MASingleOptionDescription new selectorAccessor: #themePreference; label: 'UI Theme'; comment: 'The theme to use for UI look and feel'; reference: MAClassDescription new; optionsAndLabels: {UIThemeStandardSqueak->'Standard Squeak' . UIThemeWatery2->'Watery 2'}; default: UIThemeWatery2; priority: 1000; beRequired; yourself Although the "labels" for options doesn't work in Magritte yet... plus no description for each selectable theme. Also, to look nicer would benefit from adding more to Magritte for radio button lists which would then require setting the widget/morph/seaside-thing class explicitly for each rendering target. Using this scheme the change-of-preference notification handling would need to be implemented for each defined preference also... more and more complicated and increased replication of code. Regards Gary

March 6, 2009

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

by Alain Plantec

Matthew Fulmer a Ã©crit : > On Fri, Mar 06, 2009 at 12:02:54PM +0100, Alain Plantec wrote: > >> Anyway, it seems very interesting and I would like to learn a bit about >> Magritte even it is not possible to use it for preferences. >> As an example, could you explain how you specify the themePreference >> with Magritte ? >> Maybe it can help us to improve our implementation. >> > > Hehe. I've already done that twice now: > yes, sorry :) cheers alain

March 6, 2009

Re: [Pharo-project] Cog Closure Compiler

by Keith Hodges

Lukas Renggli wrote: > Hi, > > I finally found out where to get the image level code for the Cog Closure Image. > > http://www.mirandabanda.org/files/Cog/Closures0811/Bootstrap/ > > I used the latest Squeak 4.0 VM from John and I tried to load the > change-sets into the latest Pharo, as well as into the latest Squeak > 3.9.1. In both cases it breaks pretty early on. > > It is easy to add empty dummy classes that the script tries to patch > (e.g. DecompilerTest) but then there are dozens of undeclared > variables reported on transcript and the file-in eventually dies. The > fact that debugger, compiler, browser and compiled methods are then in > a strange state doesn't make it easier ... > > Has anybody had more success with this? Anybody willing to help making > this thing work in Pharo? > > I desire fast closures so badly ... ;-) > > Lukas > I cant help thinking that atomic loading would be useful here. I assume that Elliot has not used traits, so it "should work", however: There is an image here with lpf and atomic loading enabled: http://bob.warwick.st/3.11/Squeak3.10.2-lpf-atomic/090305-0113/ When I tried to add stuff to this image I get a load of obsolete classes that are not tidied up, as can be seen in this image here: http://bob.warwick.st/output/BuildBase/Squeak3.10.2-build-atomic/090305-013… So honestly it might be worth someone's time to have a look at it, and find out what matthew broke :-) Keith

March 6, 2009