June 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Three current versions: 1.0, 1.1, 1.2

by Niko Schwarz

I hear that we're working on 1.2 now. But pharo-project.org still hands out 1.0 versions to everyone who asks. So we'll get plenty of bug reports for 1.0. I think we should switch over to 1.1 on the home page soon. Niko -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

June 8, 2010

Re: [Pharo-project] GAUCHO 1.0 released!

by laurent laffont

On Tue, Jun 8, 2010 at 10:07 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Jun 8, 2010, at 9:28 AM, Fernando olivero wrote: > > > Hi Simon, > > > > On Jun 7, 2010, at 5:48 PM, Simon Denier wrote: > > > >> > >> OK two other things > >> > >> 1) (minor) I find myself repeatdly trying to extend a Shape size to > display more instance variables and methods by looking for the resize handle > in the bottom right corner > >> > > > > Fernando if you listen what simon is telling you is that he does not want > to see the code in larger font. > he said that on his 30 inches screen he would like to see more method names > at once. > Now looking at what your hand is doing is interesting: simon hand wanted to > have a large number of methods > so he tried to grab the corner. > > In terms of UI assessment, one guru said that we can debug 50% of the > problems by asking people to speak aloud when they try > an interface. So this is a cheap but really effective way of making > progress. > > > We wanted to provide a concise and compact view of the shapes, due to the > restrictions that the current Morphic is pixel based and not scalable, to > take the most of the real estate of a pampas. Possibly once i migrate to a > scalable and vectorized UI framework ( Morphic3 ?), resizing would be > considered. > > You have a far easier solution if you want to let people work better. > > > 2) when I want to edit a method, the shape takes the full screen and I > can't see any other data. Why can't I edit the method in-place > >> > > > > > > This was a decision i took, based on the fact that this lets you focus on > writing that method only, similar to what Ommwriter proposes. > http://www.ommwriter.com/ > > Bad bad bad idea. > You never want to have a look at other code while programming. > never -> always ? Laurent > For me this will be the reason 1 for not using gaucho. > Smalltalk is already bad because you have to open another browser but > gaucho is a jail since you cannot even > look at something else. > > > The idea is to provide a Control panel where the developer can customize > the system in the next version. > > > >> > >> Also, I find it quickly annoying when I have to place manually each > shape created. It would be better if shapes tend to stick to their parent > shape when created, and I can move them freely after (I think that one point > where codebubbles is good). > > > > > > This is also something for the next release, i also think that code > bubbles has a good automatic layout strategy, and would like to provide > something similar, or even better. > > > > > >> I actually have more ideas about that, but it's tedious to explain by > plain mail. > >> > > > > I would love to hear them! I think this next ESUG would be an excellent > place to meet and discuss. > > if you want to run a real user experience feedback I can be a guinea pig > you can ask me to do some tasks and tape me. > > Stef > > > > > > Thanks for the feedback ! > > > > > > Fernando > > > > > > > > _______________________________________________ > > 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 >

June 8, 2010

Re: [Pharo-project] squeaksource.com is down?

by Fabrizio Perin

Hi, now squeaksource should work. 2010/6/8 laurent laffont <laurent.laffont(a)gmail.com> > On Mon, Jun 7, 2010 at 10:54 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Old version of squeak. >> Problem with cocnurrency or something like that. >> > > > Arggg squeaksource still down. Isn't it possible to upgrade it ? How can it > be mirrored ? > > Laurent > > > >> >> > no unfortunately this is the server. May be having a cron job restarting >> every day the server could be good. >> > >> > Stef >> > >> > or a mirror :) Do someone knows why squeaksource go down so often ? >> > >> > Laurent >> > >> > >> > >> > > I couldn't access it for the last couple of hours, is it some planned >> > > maintenance? >> > > >> > > Thank you, >> > > Andrei >> > > >> > > _______________________________________________ >> > > 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 >> > >> > _______________________________________________ >> > 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 8, 2010

Re: [Pharo-project] GAUCHO 1.0 released!

by StÃ©phane Ducasse

On Jun 8, 2010, at 9:28 AM, Fernando olivero wrote: > Hi Simon, > > On Jun 7, 2010, at 5:48 PM, Simon Denier wrote: > >> >> OK two other things >> >> 1) (minor) I find myself repeatdly trying to extend a Shape size to display more instance variables and methods by looking for the resize handle in the bottom right corner >> > Fernando if you listen what simon is telling you is that he does not want to see the code in larger font. he said that on his 30 inches screen he would like to see more method names at once. Now looking at what your hand is doing is interesting: simon hand wanted to have a large number of methods so he tried to grab the corner. In terms of UI assessment, one guru said that we can debug 50% of the problems by asking people to speak aloud when they try an interface. So this is a cheap but really effective way of making progress. > We wanted to provide a concise and compact view of the shapes, due to the restrictions that the current Morphic is pixel based and not scalable, to take the most of the real estate of a pampas. Possibly once i migrate to a scalable and vectorized UI framework ( Morphic3 ?), resizing would be considered. You have a far easier solution if you want to let people work better. > 2) when I want to edit a method, the shape takes the full screen and I can't see any other data. Why can't I edit the method in-place >> > > > This was a decision i took, based on the fact that this lets you focus on writing that method only, similar to what Ommwriter proposes. http://www.ommwriter.com/ Bad bad bad idea. You never want to have a look at other code while programming. For me this will be the reason 1 for not using gaucho. Smalltalk is already bad because you have to open another browser but gaucho is a jail since you cannot even look at something else. > The idea is to provide a Control panel where the developer can customize the system in the next version. > >> >> Also, I find it quickly annoying when I have to place manually each shape created. It would be better if shapes tend to stick to their parent shape when created, and I can move them freely after (I think that one point where codebubbles is good). > > > This is also something for the next release, i also think that code bubbles has a good automatic layout strategy, and would like to provide something similar, or even better. > > >> I actually have more ideas about that, but it's tedious to explain by plain mail. >> > > I would love to hear them! I think this next ESUG would be an excellent place to meet and discuss. if you want to run a real user experience feedback I can be a guinea pig you can ask me to do some tasks and tape me. Stef > > > Thanks for the feedback ! > > > Fernando > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 8, 2010

Re: [Pharo-project] Gaucho icons framework into Pharo1.1 ?

by StÃ©phane Ducasse

Yes this would be a nice idea to have several icons importers and icons family. If we could have the default set under the same infrastructure it would be good. For 1.2 :) On Jun 8, 2010, at 9:21 AM, Fernando olivero wrote: > Hi Simon, the icons are the Oxygen family of icons from the GNOME project. > > I've made a icons framework importer , which loads an icon set into Pharo and creates a class for each icon set. > The idea is to have polymorphic classes of icons sets: > For example > > IconsFamilyBuilder>>build > | specs secs | > specs := self iconsSpecs . > specs do:[:each| each resourcesFolderName: self resourcesFolderName ]. > ^ GMIconFamily createFamilyNamed: self iconFamilyName specs: specs . > > Which has subclasses such as OxygenIconsBuilder, that creates GMIconFamilyOxygen. > The code is similar to that found in MenuIcons, but i've added the notion of icons sets. > > I would like to integrate it to Pharo1.1, so we should unify the MenuIcons and maybe the UIThemes methods found in the icons category, so we provide only one entry point for icons in the system, together with a simple importer and provider of icons. > > Let me know what you think. > > > > Fernando > > > >> >> >> Who did the nice icons? >> >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> 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

June 8, 2010

Re: [Pharo-project] ISSUE 2514: Refactoring the Editors

by Fernando olivero

On Jun 7, 2010, at 3:29 PM, Henrik Johansen wrote: > > On Jun 7, 2010, at 3:03 33PM, Fernando olivero wrote: > >> Hi Adrian, i've added this test in the SLICE. >> It wasn't there before. >> >> The problem is that in PharoCore-1.1-11383-Beta the new editors aren't initialized, and the test fails, >> >> TextEditor initialize. >> SmalltalkEditor initialize. >> SimpleEditor initialize. >> >> I could either add this statements as a test preconditions, or we could execute them and have already initialized in the image itself. So we have a valid state of the editors in the image. >> >> What is your opinion? >> >> Fernando > Should do some refactoring too, right now actions are stored in a shared variable for SimpleEditor, and a class inst var for TextEditor. (capitalized differently) > YES! > And most of them are initialized, it's just SmalltalkEditor which is not. > Since it doesn't implement initialize directly, it is never executed when loaded from Monticello (or filed in, for that matter). > With the initialize factored into different methods like that, the initialize method itself is seldomly updated, it's hard to ensure you've initialized correctly when using Monticello. > Up to now i've only ported the Editors, and made minor modifcations due to Pharo being diferent than CUIS and Squeak. What you propose and also what Lukas proposed in the past is the next step. > In this case, a postload script for System-Text doing Editor allSubclassesDo: [:each | each initialize] might have been the simplest solution, but those don't exist anymore in Pharo. > > Cheers, > Henry > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 8, 2010

Re: [Pharo-project] Gaucho icons framework into Pharo1.1 ?

by Mariano Martinez Peck

On Tue, Jun 8, 2010 at 9:21 AM, Fernando olivero <oliverof(a)lu.unisi.ch>wrote: > Hi Simon, the icons are the Oxygen family of icons from the GNOME project. > > I've made a icons framework importer , which loads an icon set into Pharo > and creates a class for each icon set. > The idea is to have polymorphic classes of icons sets: > For example > > IconsFamilyBuilder>>build > | specs secs | > specs := self iconsSpecs . > specs do:[:each| each resourcesFolderName: self resourcesFolderName > ]. > ^ GMIconFamily createFamilyNamed: self iconFamilyName specs: specs . > > Which has subclasses such as OxygenIconsBuilder, that creates > GMIconFamilyOxygen. > The code is similar to that found in MenuIcons, but i've added the notion > of icons sets. > > I would like to integrate it to Pharo1.1, so we should unify the MenuIcons > and maybe the UIThemes methods found in the icons category, so we provide > only one entry point for icons in the system, together with a simple > importer and provider of icons. > > Please don't. We need to freeze Pharo1.1. We are near to the release and only bug fixes should be integrated. But of course, this is more than welcome in Pharo 1.2 ;) > Let me know what you think. > > > > Fernando > > > > > > > > > Who did the nice icons? > > > > > > -- > > Simon > > > > > > > > > > _______________________________________________ > > 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 >

June 8, 2010

Re: [Pharo-project] Gaucho icons framework into Pharo1.1 ?

by Alain Plantec

Le 08/06/2010 09:21, Fernando olivero a Ã©crit : > Hi Simon, the icons are the Oxygen family of icons from the GNOME project. > > I've made a icons framework importer , which loads an icon set into Pharo and creates a class for each icon set. > The idea is to have polymorphic classes of icons sets: > For example > > IconsFamilyBuilder>>build > | specs secs | > specs := self iconsSpecs . > specs do:[:each| each resourcesFolderName: self resourcesFolderName ]. > ^ GMIconFamily createFamilyNamed: self iconFamilyName specs: specs . > > Which has subclasses such as OxygenIconsBuilder, that creates GMIconFamilyOxygen. > The code is similar to that found in MenuIcons, but i've added the notion of icons sets. > > I would like to integrate it to Pharo1.1, so we should unify the MenuIcons and maybe the UIThemes methods found in the icons category, so we provide only one entry point for icons in the system, together with a simple importer and provider of icons. > > Let me know what you think. > Hi Fernando, It seems cool. Maybe open an issue with a package for your icon framework so that people can test and write feedbacks. Cheers Alain > > > Fernando > > > > >> >> Who did the nice icons? >> >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> 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 > >

June 8, 2010

Re: [Pharo-project] GAUCHO 1.0 released!

by Fernando olivero

Hi Simon, On Jun 7, 2010, at 5:48 PM, Simon Denier wrote: > > OK two other things > > 1) (minor) I find myself repeatdly trying to extend a Shape size to display more instance variables and methods by looking for the resize handle in the bottom right corner > We wanted to provide a concise and compact view of the shapes, due to the restrictions that the current Morphic is pixel based and not scalable, to take the most of the real estate of a pampas. Possibly once i migrate to a scalable and vectorized UI framework ( Morphic3 ?), resizing would be considered. > 2) when I want to edit a method, the shape takes the full screen and I can't see any other data. Why can't I edit the method in-place > This was a decision i took, based on the fact that this lets you focus on writing that method only, similar to what Ommwriter proposes. http://www.ommwriter.com/ The idea is to provide a Control panel where the developer can customize the system in the next version. > > Also, I find it quickly annoying when I have to place manually each shape created. It would be better if shapes tend to stick to their parent shape when created, and I can move them freely after (I think that one point where codebubbles is good). This is also something for the next release, i also think that code bubbles has a good automatic layout strategy, and would like to provide something similar, or even better. > I actually have more ideas about that, but it's tedious to explain by plain mail. > I would love to hear them! I think this next ESUG would be an excellent place to meet and discuss. Thanks for the feedback ! Fernando

June 8, 2010

[Pharo-project] Gaucho icons framework into Pharo1.1 ?

by Fernando olivero

Hi Simon, the icons are the Oxygen family of icons from the GNOME project. I've made a icons framework importer , which loads an icon set into Pharo and creates a class for each icon set. The idea is to have polymorphic classes of icons sets: For example IconsFamilyBuilder>>build | specs secs | specs := self iconsSpecs . specs do:[:each| each resourcesFolderName: self resourcesFolderName ]. ^ GMIconFamily createFamilyNamed: self iconFamilyName specs: specs . Which has subclasses such as OxygenIconsBuilder, that creates GMIconFamilyOxygen. The code is similar to that found in MenuIcons, but i've added the notion of icons sets. I would like to integrate it to Pharo1.1, so we should unify the MenuIcons and maybe the UIThemes methods found in the icons category, so we provide only one entry point for icons in the system, together with a simple importer and provider of icons. Let me know what you think. Fernando > > > Who did the nice icons? > > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 8, 2010