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

Re: [Pharo-project] Loading GemTools in Pharo 1.1.1-dev

by Johan Brichau

Hi Veronica ;-) First update Metacello: ConfigurationOfMetacello project updateProject On 30 Mar 2011, at 15:42, Veronica Isabel Uquillas Gomez wrote: > Hi, > > I want to try GemStone. So I started loading GemTools in a Pharo image 1.1.1-dev without success. > An error appears when loading Metacello Browser version #development. > After that I tried to load first MetacelloBrowser and then I got the same error for OmniBrowser version #stable. > > What am I doing wrong? or do I need to use a different image? > > Regards, > Veronica

March 30, 2011

[Pharo-project] Loading GemTools in Pharo 1.1.1-dev

by Veronica Isabel Uquillas Gomez

Hi, I want to try GemStone. So I started loading GemTools in a Pharo image 1.1.1-dev without success. An error appears when loading Metacello Browser version #development. After that I tried to load first MetacelloBrowser and then I got the same error for OmniBrowser version #stable. What am I doing wrong? or do I need to use a different image? Regards, Veronica

March 30, 2011

Re: [Pharo-project] Issue 3584 in pharo: ToDo: remove DisplayText class

by pharo＠googlecode.com

Updates: Status: FixProposed Labels: Milestone-1.3 Comment #2 on issue 3584 by marcus.d...(a)gmail.com: ToDo: remove DisplayText class http://code.google.com/p/pharo/issues/detail?id=3584 (No comment was entered for this change.)

March 30, 2011

Re: [Pharo-project] Issue 3584 in pharo: ToDo: remove DisplayText class

by pharo＠googlecode.com

Comment #1 on issue 3584 by fernando...(a)gmail.com: ToDo: remove DisplayText class http://code.google.com/p/pharo/issues/detail?id=3584 I've based this changes on CUIS 3.1, the idea is to remove the primary user of DisplayText in like this: String>>displayOn: aDisplayMedium at: aPoint textColor: aColor aDisplayMedium getCanvas drawString: self from: 1 to: self size at: aPoint font: nil color: aColor and also removed UIManager>>composeForm:. Attachments: DisplayTextRemoval.1.cs 13.8 KB

March 30, 2011

Re: [Pharo-project] who is using softSqueak and standard Squeak

by Helene Bilbo

Patrick Barroca wrote: > > My first look yesterday night taught me that different windows colour > management is a basic behaviour of UITheme via #patchworkUIThemeColorFor:. > If I simply subclass UITheme and do nothing more I get more or less a > standard squeak theme with coloured windows minus some fills and borders > styles. > > From here I think I could try to make a simple theme with the look of > Glamourous one with support for squeak windows colour management. > Is this the right direction ? > I was toying around with this yesterday. I also found methods for setting the background of various UI elements in UITheme - but not yet for PluggableTextMorph.. Do you know if there is a way to change the background colors of PluggableTextMorph and OBPluggableTextMorph in UITheme? Or is there a way to change the background of all UI elements in one place? -- View this message in context: http://forum.world.st/who-is-using-softSqueak-and-standard-Squeak-tp3407241… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 30, 2011

[Pharo-project] XSD Encoding/Decoding

by Udo Schneider

All, I'm a bit stuck on decoding/encoding data based on existing XSDs. I assumed this should be possible with SoapOpera ... but I don't really know where to start. Does anybody have a small example of encoding/decoding Smalltalk Objects based on exiting XSDs? Thanks, Udo

March 30, 2011

[Pharo-project] Issue 3914 in pharo: Add a method in RPackage

by pharo＠googlecode.com

Status: FixProposed Owner: Benjamin...(a)gmail.com Labels: Nautilus New issue 3914 by Benjamin...(a)gmail.com: Add a method in RPackage http://code.google.com/p/pharo/issues/detail?id=3914 Which is an extension of Monticello, so I prefer not to publish the package by my own :s Attachments: RPackage.BenjaminVanRyseghem.1.cs 3.2 KB

March 30, 2011

Re: [Pharo-project] Progress bar design pattern

by Henrik Johansen

On Mar 30, 2011, at 2:17 23AM, Martin Dias wrote: > Hello > > I have a couple of algorithms and I want to show the progress while they run. I played with the progress bar and it's okay for my needs. > > The progress bar should be pluggable and decoupled of the algorithms. > > I am writing to you to ask about good designs for my problem. I hope I haven't expressed the problem in a too abstract way. > > The design I have in mind is a kind of observer pattern: the serialization algorithm publishes information about the run; a specific listener implements the progress bar for that serialization algorithm, interpreting the information published. > > Thanks, > Martin If my previous post wasn't crystal clear: I've used this pattern in the past, it works like a charm :) I'd recommend just using a simple progress bar widget though, and putting the pluggability at a different level. This is more of a pattern than a framework, it's hard to make a one-size-fits-all solution. Not to mention using a simple API for updating the widget itself makes it easier later on to substitute if you find a different visualization would be better. Cheers, Henry

March 30, 2011

Re: [Pharo-project] Progress bar design pattern

by Henrik Johansen

On Mar 30, 2011, at 7:13 23AM, Daniel Lyons wrote: > > On Mar 29, 2011, at 6:17 PM, Martin Dias wrote: > >> I have a couple of algorithms and I want to show the progress while they run. I played with the progress bar and it's okay for my needs. >> >> The progress bar should be pluggable and decoupled of the algorithms. >> >> I am writing to you to ask about good designs for my problem. I hope I haven't expressed the problem in a too abstract way. >> >> The design I have in mind is a kind of observer pattern: the serialization algorithm publishes information about the run; a specific listener implements the progress bar for that serialization algorithm, interpreting the information published. > > > I'm a newcomer here, so I'm sharing my experience with non-Smalltalk systems and my best guess what would constitute good designs. I hope other real Smalltalkers will poke some holes in this and point out the right way to do things! ;) > > The simplest design, IMO, would be this API: > > MyProgressBar>>percentComplete: aNumber > MyProgressBar>>beIndeterminant > MyProgressBar>>beDeterminant > > You would manually invoke percentComplete: with a new percent complete each time you want to advance the progress bar. I've seen this kind of thing in practice somewhere. Maybe it was Cocoa? > > The next level of abstraction would be to go a bit more jQuery UI and remove percentComplete: and use this instead: > > MyProgressBar>>maximum: anInteger > MyProgressBar>>current: anInteger > > Now you'll calculate the progress bar based on some quantity of "tasks" you want to do. You could even go further and just have: > > MyProgressBar>>incrementProgress > > instead of letting your clients tell you which one they're on. That would prevent progress bar relapse. Either of these would be easy to implement on top of the above API using percent. > > The simplest observer-type pattern would be to rely on the built-in observer/event system and use the stuff from Object's updating protocol or events-registering or events-triggering. I don't know which one of these is modern or preferred. Anybody? :) At any rate, they make it possible to expose a simple object/message protocol as in Polymorph, where your progress bar widget would be listening for change notifications from your domain object. Then you can ask the same questions about your model as above, in terms of whether you want to work in terms of simply percent complete or N/M or what. > > Another question is whether or not you want to provide a string message status to go under the progress bar. > > Does this help at all, or did I miss the point? > > â > Daniel Lyons > I've used Announcements for this in the past, and liked it quite alot. - Worker announces WorkCompleted or some such. Announcement holds details of the work it's done, in my case different properties of an analysis like leak rate, . - GUI/Client is set up before analysis starts, and initialized with the total work to be done. Annnouncement handling contains code to estimate how much progress the Work indicated by it was of the overall total. I also used a different client which provided ETA based on a more sophisticated analysis of the Work announcements. Needless to say, there's no hard dependency on a UI in such a scheme, as there simply won't be any clients instantiated if you run headless. (well, unless you make one writing to stdout or something) Not sure what would be reasonable to put in a Work-annnouncement intended as superclass for custom solutions... In other words, the downside is that this approach doesn't lead to something you can use out-of-the-box, you always have to do some customization, either/both to what data you provide, or/and to how you give feedback. (In this case, a standard widget using the simplest design you described is preferrable, btw, the pluggability is done at a different level than the widget) Cheers, Henry

March 30, 2011

Re: [Pharo-project] who is using softSqueak and standard Squeak

by Sven Van Caekenberghe

On 30 Mar 2011, at 10:53, Patrick Barroca wrote: > My first look yesterday night taught me that different windows colour management is a basic behaviour of UITheme via #patchworkUIThemeColorFor:. > If I simply subclass UITheme and do nothing more I get more or less a standard squeak theme with coloured windows minus some fills and borders styles. > > From here I think I could try to make a simple theme with the look of Glamourous one with support for squeak windows colour management. > Is this the right direction ? If that would work, that would be great: simple & effective.

March 30, 2011