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

Re: [Pharo-project] Progress bar

by Henrik Sperre Johansen

On 13.12.2011 13:00, StÃ©phane Ducasse wrote: > On Dec 13, 2011, at 11:44 AM, Henrik Sperre Johansen wrote: > >> On 13.12.2011 11:01, StÃ©phane Ducasse wrote: >>> Hi >>> >>> I was looking how we could improve the situation of the progress bar. >>> We could "simply" remove some annoying updates (I did some first analysis because I got tired of this). >>> I will try to continue so that we have less updates all the times. >>> >>> Now what I see is that there is also an architectural problem. >>> I will try to explain it: each method in different classes (change set, MCloader, FileStream), can be used in >>> different scenarios and depending on the path you want or not to raise feedback. >>> A bad solution would be to duplicate the method and pass a boolean to indicate whether the feedback should be >>> raised or not. >>> >>> Now I have the impression that the architecture should be: >>> - the different part raised events (but this is not clear how) >>> - the top level (the part launching) can absorb and aggregate event to give feedback. >>> I do not know if it makes sense. Do you know how this is done in other systems. >>> >>> Stef >> Makes sense to me. >> My suggestion: >> Replace with Announcing progress has been made. (e.g. StartedActivity, ProgressedActivity, EndedActivity ) >> The places you want visual feedback (ie when invoked from a GUI), install an listener to the announcements (A ProgressMorph?) which displays the progress bar(s). > There is already an exception/warning starting and progress. > I will digest that and see. First reducing the flickering. Yes, like you said, Exceptions... It's one of the things worth changing, imho :) To keep it backwards-compatible, one could alias those names to those of Announcements, and keep a backwards-compatible protocol for messages which are found non-suitable (or, use the same). My personal main dislike though is the use of displayProgress* protocol rather than the equivalent of announceProgress* or some such, which could then acted upon instead of being displayed directly. Invoked headlessly/from non-GUI code? Just disregard. Invoked headlessly from command-line? Use a listener writing to stdout. Invoked from GUI? Use a listener displaying a ProgressMorph. You can separate headless/GUI with custom UIManagers atm, but the other cases are tricky unless you want your code to meddle about installing custom UIManagers. Cheers, Henry

Dec. 13, 2011

Re: [Pharo-project] native boost is the best thing since COGVM

by Igor Stasenko

On 12 December 2011 18:42, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Igor > > what is the link between pango cairo and the work you did on the text model in athens? > Because I have the impression that you work on text modeling is important. > i dont know much about pango to say anything, except that it is library for text layout. my impression, that if we will want to use pango for text layout, then we need to use different model for text. Or maybe Text could stay, but morphic related stuff will require serious changes. This is because when i did text layout for Athens, i had to make own paragraph/morph pair, because of hardcoded stuff in existing classes. > Stef > > >> A taste of what will be available: rendering the same GLabel (the >> gaucho equivalent to StringMorph), scaling the CairoCanvas. >> >> Pesudo Code: >> >> "create a label" >> label := GLabel on : 'hello Pango-Cairo'. >> >> "draw it on the canvas" >> label drawOn: canvas. >> >> "scale the canvas" >> canvas translateBy: aDelta ; scaleBy: aScale. >> >> "draw it on the canvas" >> label drawOn: canvas. >> >> "repeat" > -- Best regards, Igor Stasenko.

Dec. 13, 2011

Re: [Pharo-project] Sprint friday 16 of december

by StÃ©phane Ducasse

University Stef On Dec 13, 2011, at 1:15 PM, Mariano Martinez Peck wrote: > > > > > Please let us know the exact location. > > I imagine that we will do it in the same place as last time. > > > And that was?... INRIA or university ? > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 13, 2011

Re: [Pharo-project] Sprint friday 16 of december

by Benjamin

I think it was at university in the big room (116) Ben On Dec 13, 2011, at 1:15 PM, Mariano Martinez Peck wrote: > > > > > Please let us know the exact location. > > I imagine that we will do it in the same place as last time. > > > And that was?... INRIA or university ? > > -- > Mariano > http://marianopeck.wordpress.com >

Dec. 13, 2011

Re: [Pharo-project] Sprint friday 16 of december

by Mariano Martinez Peck

> > > > Please let us know the exact location. > > I imagine that we will do it in the same place as last time. > > And that was?... INRIA or university ? -- Mariano http://marianopeck.wordpress.com

Dec. 13, 2011

Re: [Pharo-project] Sprint friday 16 of december

by StÃ©phane Ducasse

On Dec 13, 2011, at 1:05 PM, Sven Van Caekenberghe wrote: > StÃ©phane, > > On 07 Dec 2011, at 13:03, StÃ©phane Ducasse wrote: > >> we want to code and fix stuff for pharo. We will organize a christmas sprint at Lille. >> You are welcomed, just let us know if you want to participate. > > C'Ã©tait trÃ¨s agrÃ©able la derniÃ¨re fois ;-) > > So I am planning to come. I am hoping to finally finish the proper integration of Zn into the core. For the rest, I am willing to help on whatever is important. > > The only problem is that it is quite stormy weather this week and it is a long drive (200 km single). But as long as there are no 'stay home' warnings I will probably make it. > >> We will start at 9h we will indicate if we do it in our building or the INRIA one. > > Please let us know the exact location. I imagine that we will do it in the same place as last time. Stef

Dec. 13, 2011

Re: [Pharo-project] Sprint friday 16 of december

by Sven Van Caekenberghe

StÃ©phane, On 07 Dec 2011, at 13:03, StÃ©phane Ducasse wrote: > we want to code and fix stuff for pharo. We will organize a christmas sprint at Lille. > You are welcomed, just let us know if you want to participate. C'Ã©tait trÃ¨s agrÃ©able la derniÃ¨re fois ;-) So I am planning to come. I am hoping to finally finish the proper integration of Zn into the core. For the rest, I am willing to help on whatever is important. The only problem is that it is quite stormy weather this week and it is a long drive (200 km single). But as long as there are no 'stay home' warnings I will probably make it. > We will start at 9h we will indicate if we do it in our building or the INRIA one. Please let us know the exact location. Sven

Dec. 13, 2011

Re: [Pharo-project] Startup Preferences

by StÃ©phane Ducasse

we should integrate it :) Stef On Dec 13, 2011, at 11:37 AM, Benjamin wrote: > New version: > > Now there is a hierarchy for the setting file > > - first it lloks in the image diretory for st files > - if none is found, it looks into > ~/.config/pharo/${VERSION} > - if none is found it looks into > ~/.config/pharo/general > > We could also add a look into > ~/.pharo/ > > > > Gofer new > squeaksource: 'StartupPreferences'; > package: 'StartupPreferences'; > load. > > Ben > > On Dec 1, 2011, at 6:50 PM, StÃ©phane Ducasse wrote: > >> me too. >> >> Stef >> >> On Dec 1, 2011, at 6:38 PM, Camillo Bruni wrote: >> >>> Yeah I would really love to see this. >>> >>> maybe with a fixed lookup chain >>> >>> 1. Settings from the Image directory/startup.st >>> 2. Settings from ~/.pharo/$VERSION/startup.st >>> 3. Settings from ~/.pharo/startup.st >>> >>> cami >>> >> >> >

Dec. 13, 2011

Re: [Pharo-project] Progress bar

by StÃ©phane Ducasse

On Dec 13, 2011, at 11:44 AM, Henrik Sperre Johansen wrote: > On 13.12.2011 11:01, StÃ©phane Ducasse wrote: >> Hi >> >> I was looking how we could improve the situation of the progress bar. >> We could "simply" remove some annoying updates (I did some first analysis because I got tired of this). >> I will try to continue so that we have less updates all the times. >> >> Now what I see is that there is also an architectural problem. >> I will try to explain it: each method in different classes (change set, MCloader, FileStream), can be used in >> different scenarios and depending on the path you want or not to raise feedback. >> A bad solution would be to duplicate the method and pass a boolean to indicate whether the feedback should be >> raised or not. >> >> Now I have the impression that the architecture should be: >> - the different part raised events (but this is not clear how) >> - the top level (the part launching) can absorb and aggregate event to give feedback. >> I do not know if it makes sense. Do you know how this is done in other systems. >> >> Stef > Makes sense to me. > My suggestion: > Replace with Announcing progress has been made. (e.g. StartedActivity, ProgressedActivity, EndedActivity ) > The places you want visual feedback (ie when invoked from a GUI), install an listener to the announcements (A ProgressMorph?) which displays the progress bar(s). There is already an exception/warning starting and progress. I will digest that and see. First reducing the flickering. > > Cheers, > Henry >

Dec. 13, 2011

Re: [Pharo-project] [Vm-dev] OSS sound plugin.

by Bernat Romagosa

It doesn't seem like it was done... I can't manage to get sound to work in Linux and the OSS plugin is not there. Anyone succeeded? -- View this message in context: http://forum.world.st/OSS-sound-plugin-tp3357110p4190128.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 13, 2011