- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Scat - Public Release and announcement

by Marcus Denker

On Dec 13, 2011, at 12:11 PM, Serge Stinckwich wrote: > > Serge, the thing is that the code in Scratch is terribly bad... maintaining it is close to impossible. The project was coded by several different students with different coding styles and barely any Smalltalk experience. They took advantage of bugs in the old Squeak version used to build Scratch, and mixed view and controllers so hard one can barely distinguish them at all. We've made our best to get what we could to work in Pharo, but we never tried to make the code better. > > You are definitively right Bernat, this is a good example that even in Smalltalk, this is possible to write nightmare code. Do we need another example after etoys? I really would have expected that someone involved in the original etoys would have known better than to *again* let a code base degenerate to the point that it is completely unmaintainable... Marcus -- Marcus Denker -- http://marcusdenker.de

Dec. 13, 2011

Re: [Pharo-project] Progress bar

by StÃ©phane Ducasse

I will try to reduce the flickering first On Dec 13, 2011, at 1:24 PM, Henrik Sperre Johansen wrote: > 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] [ANN] Eclipse Icons for Pharo

by Esteban Lorenzano

cool, then you can send to me? I will play with the idea of decouple ThemeIcons from UITheme (to have a separated strategy like UIThemeIcons, who can be replaced without replacing UITheme). btw... I looked at those icons, and while their are nice, I still don't found correct matching icons for a couple of important tools we use. Most important ones I remember now: 1) System Browser 2) Debugger (or "Hot Coder", as Doru prefer to say :) any ideas we'll be welcome Cheers, Esteban El 13/12/2011, a las 2:50a.m., Fernando Olivero escribiÃ³: > Nice! > As soon as squeaksource is up, i will import them using the icon > importer, so we can give them a try. > Fernando > > On Mon, Dec 12, 2011 at 6:29 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> http://www.famfamfam.com/ >> ? >> >> >> >>> Hi Fernando, >>> >>> oops... I forgot your icon importer, sorry :P >>> >>> I would like âfor a futureâ to integrate it to pharo and replace current ThemeIcons with an icon strategy based on your package... maybe that is the best "future scenario" for icons. >>> >>> best, >>> Esteban >>> >>> El 11/12/2011, a las 8:49a.m., Fernando Olivero escribiÃ³: >>> >>>> Hi Esteban, nice work! >>>> For importing the icons you can use the toolset i've developed: it >>>> automates completely the process of importing a complete set of icons >>>> of a given family. >>>> >>>> ExternalIconFamily @ squeaksource. >>>> I've used it for importing the Oxygen icon set, and others (you can >>>> google the list for previous related emails). >>>> >>>> Fernando >>>> >>>> On Sun, Dec 11, 2011 at 10:38 AM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> Esteban >>>>> I know that feeling :) >>>>> >>>>> :) >>>>> Now I'm not sure that I would like to carry the Eclipse License around in Pharo :) >>>>> What are the other icons sets we could use with a nice license and we do it :). >>>>> famfam? >>>>> >>>>> We should clean also the old icons because some are really old. >>>>> Thanks for pushing that. I would love to have new icons for Pharo. >>>>> Stef >>>>> >>>>> >>>>> >>>>> On Dec 11, 2011, at 3:15 AM, Esteban Lorenzano wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Today I was bored and not wanting to think too much... but I wanted to do something for Pharo... and I never liked the current Pharo icons, so I took one icon library I really like and changed all needed icons (well... all that I saw). >>>>>> Here a couple of screen shots: >>>>>> >>>>>> <Captura de pantalla 2011-12-10 a la(s) 23.05.55.png> >>>>>> <Captura de pantalla 2011-12-10 a la(s) 23.06.20.png> >>>>>> >>>>>> Of course, I don't think they are perfect (also maybe I didn't pick the best icons), but I think they look a lot better than the older. >>>>>> >>>>>> If you want to see how they look, this are the packages: >>>>>> >>>>>> for Pharo 1.3: >>>>>> >>>>>> <Eclipse-Icons-EstebanLorenzano.2.mcz> >>>>>> >>>>>> for Pharo 1.4: >>>>>> >>>>>> <Eclipse-Icons-EstebanLorenzano.4.mcz> >>>>>> >>>>>> >>>>>> Then you execute: >>>>>> >>>>>> ThemeIcons initializeIcons. >>>>>> World resetWorldMenu. >>>>>> >>>>>> ... and enjoy your new icons :) >>>>>> >>>>>> btw... this icons are in an open-source license, the EPL: http://www.eclipse.org/legal/epl-v10.html >>>>>> so, maybe âif all agreeâ, we can add this icons to regular distribution :) >>>>>> >>>>>> best, >>>>>> Esteban >>>>>> >>>>> >>>>> >>>> >>> >>> >> >

Dec. 13, 2011

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