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

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by S Krish

> ... > > One can tweak the code to show the first tree right upto a class level and > eliminate the middle morph.. question of eliminating the unnecessary..!.. > > ... > >

March 2, 2012

[Pharo-project] Looking for a package to do some statistics in Pharo

by StÃ©phane Ducasse

Hi guys I would like to know if there is a package doing some statistics in Pharo. I should check the work of didier besset but I want to know if there is more. It would be good to have such kind of package. Stef

March 2, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by S Krish

You can optionally hide any of the two panes to gain real estate the way I have laid out to maximize the code text area. The code text also expands by the last green expand button per method, very important on my 14inch laptop.. One can tweak the code to show the first tree right upto a class level and eliminate the middle morph.. but again I prefer it this way.. To play I will have to release the code along with its now umblical attachment to the PharoMorphicView and wee bit to the Tabbed Pane framework and also with some minimal clean up. Hopefully mid next week, I will have a minimally usable package with Configuration released.. though I would prefer the Applesque wait for two weeks for a more polished and more comprehensive browser.. that I am happy with, get it perfectly right, for my use scenario's, will be a goal on this one.. On Fri, Mar 2, 2012 at 10:30 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 2 March 2012 17:53, Sebastian Sastre <sebastian(a)flowingconcept.com> > wrote: > > it sounds like having a couple interesting features. > > > > In system browsers I always felt missing the feature of a good tree > > component (where the whole hierarchy is always available) while finding > the > > packages pane a terrible use of screen's real state. > > > +100. > > We need package hierarchy on screen. Yes. But it is enough ONE on screen, > but not in every open browser window. > I think that if we measure how often we using each of the panes in > 4-pane layout > i spending 99% of time in rightmost two, and using leftmost mainly to > search for a class (which would make it completely > unnecessary if we could have a shortcut for searching class from anywhere), > and second one (class list) only occasionally. > > > How can I install this to play around? > > > > sebastian > > > > o/ > > > > > > On Mar 2, 2012, at 6:54 AM, S Krish wrote: > > > > Couple of screenshots of a usable code browser, does well for my use > > for now.. need to bring in the basic refactoring, variables text box > > under the class tree, in the middle. > > > > Feels lot more productive in combination with the standard browsers > > where needed. > > > > On 2/29/12, Krishsmalltalk <krishnamachari.sudhakar(a)gmail.com> wrote: > > > > > > Sure I understood that, I am still just month and a half of dabbling in > > > > morphic, that i am still learning.... I do not take any comments amiss. > > > > > > Thx > > > > > > > > On Feb 29, 2012, at 5:44 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > > > Hi, > > > > > > I was not criticizing your solution. I was actually asking for help :). > > > > > > I would like to get a text morph in the tree and have it scale both > > > > horizontally to fill the available space, and vertically to > > > > accommodate the entire text. I show the example with the > > > > GeneralScrollPane because I managed to make it work there (with the > > > > help of Gary), but I cannot do it on MorphTreeMorph. So, if you, or > > > > someone else, have ideas I would be happy to hear them. > > > > > > Cheers, > > > > Doru > > > > > > > > > > On Tue, Feb 28, 2012 at 10:09 AM, S Krish > > > > <krishnamachari.sudhakar(a)gmail.com> wrote: > > > > Sure.. that is fine.. for the use case you state > > > > > > Mine is quick n dirty hack to what I wanted: > > > > > > but my use case is I do wish to have more of these sources partially > > > > visible > > > > through the vertical pane. so I restrain it to max of 210.. and width of > > > > 600 > > > > to be able to to throw up another pane next to it.. for grouping methods > > > > I > > > > am interested in .. to view it more closely.. > > > > > > > > > > On Tue, Feb 28, 2012 at 1:33 PM, Tudor Girba <tudor(a)tudorgirba.com> > > > > wrote: > > > > > > Hi, > > > > > > Thanks for the explanation. > > > > > > I took a look. calculateExtent is triggered when you create the > > > > TextMorph. > > > > This is nice, but I am interested in getting the TextMorph to always > > > > expand > > > > to fill the width of the surrounding element, and to expand vertically > > > > according to the text :). > > > > > > Here is a variation of what I am thinking about with just a simple list > > > > of > > > > morphs within a GeneralScrollPane: > > > > https://gist.github.com/1930477 > > > > > > Cheers, > > > > Doru > > > > > > > > > > On 28 Feb 2012, at 03:22, Krishsmalltalk wrote: > > > > > > It does have the code to calculateTextExtent. You can modify it the way > > > > you want. > > > > > > The height is defaulted to a max 210 and fixed 600. But on expand it > > > > goes to max ht of 600 > > > > > > > > Modify the logic in that method as you want it to > > > > > > > > On Feb 28, 2012, at 2:42 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > > > Hi, > > > > > > I gave it a try. I am not necessarily looking for the looks as for the > > > > solution to make the text editor within the tree span horizontally and > > > > vertically with the size of the method. Unfortunately, this does not > > > > work in > > > > this example, either. > > > > > > Does anyone have ideas of how to make it work? :) > > > > > > Cheers, > > > > Doru > > > > > > > > On 27 Feb 2012, at 21:43, StÃ©phane Ducasse wrote: > > > > > > MorphicViewNewPackageBrowser new packageNames: #('UIManager') ; open > > > > > > > > But it does not look that nice :) > > > > > > > > On Feb 27, 2012, at 6:42 PM, StÃ©phane Ducasse wrote: > > > > > > this looks really nice. > > > > I would really like to see if we cannot include a version so that > > > > people can browse change set and other code like that. > > > > I'm really happy to see that the work done by alain and ben around > > > > treeMorph pays off that well. > > > > > > Stef > > > > > > > > Can take the latest of the package.. > > > > > > PackageTree-Browser-Experiment > > > > > > * Find class added and a crude/ workable expand for text morph.. > > > > > > As stated in the comments: will require a hack in Pharo 1.4 for > > > > now. > > > > > > Will work towards integrating TabbedPane with TWM/ this too as an > > > > addon with more complete features month ahead. > > > > <Pharo_CodeBrowser02.JPG> > > > > > > > > > > > > > > -- > > > > www.tudorgirba.com > > > > > > "One cannot do more than one can do." > > > > > > > > > > > > > > > > -- > > > > www.tudorgirba.com > > > > > > "Sometimes the best solution is not the best solution." > > > > > > > > > > > > > > > > -- > > > > www.tudorgirba.com > > > > > > "Every thing has its own flow" > > > > > > > > <Pharo_Tabbed_TreeCodeBrowser01.JPG><Pharo_Tabbed_TreeCodeBrowser02.JPG> > > > > > > > > > > > > -- > Best regards, > Igor Stasenko. > >

March 2, 2012

Re: [Pharo-project] Monticello Version Info

by Frank Shearar

On 2 March 2012 17:32, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Frank, > > That's right ... the major difference between the two is that git manages multiple files ... Well, kind've. A blob usually does contain the contents of a file. (http://book.git-scm.com/1_the_git_object_model.html) That is, when you checkout some branch you end up with a directory structure containing files, which is what you're talking about. It's probably better not to think of them as files: the blobs might look like files in your working copy, but they're just, well, blobs. Chunks of binary stuff that, for versioning software, happens to be UTF-8 encoded plain text (or whatever). (This is exactly why, from standing inside an image, mapping a method to a file makes sense: a method's a single unit of stuff.) Which is probably why you express yourself this way: Monticello turns a whole bunch of methods + comments + class definitions into a big snapshot.st - a single file in the zip - and a corresponding list of changes to an image - "add this, remove that". Both are still versioning a collection of things together, though: I see no problem with saying "Monticello package Foo-fbs.2 means that you have this class with this definition and that method with that definition". That's pretty much the same thing as saying "git commit id deadbeef means that you have this file with these contents and that file with those contents". frank > Dale > > ----- Original Message ----- > | From: "Frank Shearar" <frank.shearar(a)gmail.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Friday, March 2, 2012 9:27:39 AM > | Subject: Re: [Pharo-project] Monticello Version Info > | > | On 2 March 2012 17:02, Dale Henrichs <dhenrich(a)vmware.com> wrote: > | > Sven, > | > > | > A Monticello mcz file is a version data base for a single package > | > .... Git is a version data base for a directory structure ... > | > > | > Monticello has branching by convention (change the name of a file > | > to create the branch), although the mcz ancestry handles branches > | > just fine. In Git branches are first class objects ... it is > | > difficult to do things in git if you are not on one branch or > | > another ... > | > | Bearing in mind that a branch is just a pointer to a commit: look in > | your blah/.git/refs/heads/ and each file is a branch containing the > | SHA1 id of the head of that branch. (And each commit knows its > | ancestor/s, just like an mcz file, except that the hash means the > | relationship's based on the commit's _contents_, not its _name_.) > | > | frank > | > | > You can merge with Monticello and you can merge with Git ... > | > > | > The big difference is that Git allows you to version a bunch of > | > files together and with Monticello you are versioning a single > | > file. > | > > | > Part of what Metacello was invented to do was to create a "data > | > base" of versioned collections of mcz files ... Git was designed > | > to manage collections of files... > | > > | > Is this what you were asking? > | > > | > Dale > | > > | > ----- Original Message ----- > | > | From: "Sven Van Caekenberghe" <sven(a)beta9.be> > | > | To: Pharo-project(a)lists.gforge.inria.fr > | > | Sent: Friday, March 2, 2012 12:31:42 AM > | > | Subject: Re: [Pharo-project] Monticello Version Info > | > | > | > | > | > | On 02 Mar 2012, at 01:52, Chris Cunningham wrote: > | > | > | > | > The issue is that Monticello is setup for distributed > | > | > processing, > | > | > and > | > | > allowing for multiple repositories, some of which may not be > | > | > available > | > | > to all of the users for a project. Â For instance, a project > | > | > might > | > | > be > | > | > developed internally (or on the developers hard-drive) until > | > | > they > | > | > feel > | > | > comfortable distributing the code later. Â So, publicly, you get > | > | > version 12, 17, 34, and 37. Â There is no access to the > | > | > intermediate > | > | > ones (unless you happen to be the one that created them and > | > | > didn't > | > | > release them). Â The 'whole ancestry' let's you do diffs off of > | > | > a > | > | > version derived from 37 against one derived from 34 - the > | > | > ancestry > | > | > can > | > | > determine that version 34 if 'common', and work from there. > | > | > Â [Note > | > | > that just numbers aren't enough - the original developer, say, > | > | > cbc > | > | > could have version cbc.34, while you could have, say, > | > | > CamilloBruni.34, > | > | > but yours is based off of 17 (since you picked up that verison > | > | > and > | > | > started working there). Â So, merging cbc.37 with > | > | > CamilloBruni.34 > | > | > would > | > | > need to pull down cbc.17 for a good merge to work.] > | > | > > | > | > At least, that's my understanding from long ago discussions. > | > | > | > | This makes sense, but how is this handled with git ? > | > | > | > | Sven > | > > | > | >

March 2, 2012

Re: [Pharo-project] Monticello Version Info

by Dale Henrichs

Frank, That's right ... the major difference between the two is that git manages multiple files ... Dale ----- Original Message ----- | From: "Frank Shearar" <frank.shearar(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Friday, March 2, 2012 9:27:39 AM | Subject: Re: [Pharo-project] Monticello Version Info | | On 2 March 2012 17:02, Dale Henrichs <dhenrich(a)vmware.com> wrote: | > Sven, | > | > A Monticello mcz file is a version data base for a single package | > .... Git is a version data base for a directory structure ... | > | > Monticello has branching by convention (change the name of a file | > to create the branch), although the mcz ancestry handles branches | > just fine. In Git branches are first class objects ... it is | > difficult to do things in git if you are not on one branch or | > another ... | | Bearing in mind that a branch is just a pointer to a commit: look in | your blah/.git/refs/heads/ and each file is a branch containing the | SHA1 id of the head of that branch. (And each commit knows its | ancestor/s, just like an mcz file, except that the hash means the | relationship's based on the commit's _contents_, not its _name_.) | | frank | | > You can merge with Monticello and you can merge with Git ... | > | > The big difference is that Git allows you to version a bunch of | > files together and with Monticello you are versioning a single | > file. | > | > Part of what Metacello was invented to do was to create a "data | > base" of versioned collections of mcz files ... Git was designed | > to manage collections of files... | > | > Is this what you were asking? | > | > Dale | > | > ----- Original Message ----- | > | From: "Sven Van Caekenberghe" <sven(a)beta9.be> | > | To: Pharo-project(a)lists.gforge.inria.fr | > | Sent: Friday, March 2, 2012 12:31:42 AM | > | Subject: Re: [Pharo-project] Monticello Version Info | > | | > | | > | On 02 Mar 2012, at 01:52, Chris Cunningham wrote: | > | | > | > The issue is that Monticello is setup for distributed | > | > processing, | > | > and | > | > allowing for multiple repositories, some of which may not be | > | > available | > | > to all of the users for a project. Â For instance, a project | > | > might | > | > be | > | > developed internally (or on the developers hard-drive) until | > | > they | > | > feel | > | > comfortable distributing the code later. Â So, publicly, you get | > | > version 12, 17, 34, and 37. Â There is no access to the | > | > intermediate | > | > ones (unless you happen to be the one that created them and | > | > didn't | > | > release them). Â The 'whole ancestry' let's you do diffs off of | > | > a | > | > version derived from 37 against one derived from 34 - the | > | > ancestry | > | > can | > | > determine that version 34 if 'common', and work from there. | > | > Â [Note | > | > that just numbers aren't enough - the original developer, say, | > | > cbc | > | > could have version cbc.34, while you could have, say, | > | > CamilloBruni.34, | > | > but yours is based off of 17 (since you picked up that verison | > | > and | > | > started working there). Â So, merging cbc.37 with | > | > CamilloBruni.34 | > | > would | > | > need to pull down cbc.17 for a good merge to work.] | > | > | > | > At least, that's my understanding from long ago discussions. | > | | > | This makes sense, but how is this handled with git ? | > | | > | Sven | > | |

March 2, 2012

Re: [Pharo-project] Monticello Version Info

by Frank Shearar

On 2 March 2012 17:02, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Sven, > > A Monticello mcz file is a version data base for a single package .... Git is a version data base for a directory structure ... > > Monticello has branching by convention (change the name of a file to create the branch), although the mcz ancestry handles branches just fine. In Git branches are first class objects ... it is difficult to do things in git if you are not on one branch or another ... Bearing in mind that a branch is just a pointer to a commit: look in your blah/.git/refs/heads/ and each file is a branch containing the SHA1 id of the head of that branch. (And each commit knows its ancestor/s, just like an mcz file, except that the hash means the relationship's based on the commit's _contents_, not its _name_.) frank > You can merge with Monticello and you can merge with Git ... > > The big difference is that Git allows you to version a bunch of files together and with Monticello you are versioning a single file. > > Part of what Metacello was invented to do was to create a "data base" of versioned collections of mcz files ... Git was designed to manage collections of files... > > Is this what you were asking? > > Dale > > ----- Original Message ----- > | From: "Sven Van Caekenberghe" <sven(a)beta9.be> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Friday, March 2, 2012 12:31:42 AM > | Subject: Re: [Pharo-project] Monticello Version Info > | > | > | On 02 Mar 2012, at 01:52, Chris Cunningham wrote: > | > | > The issue is that Monticello is setup for distributed processing, > | > and > | > allowing for multiple repositories, some of which may not be > | > available > | > to all of the users for a project. Â For instance, a project might > | > be > | > developed internally (or on the developers hard-drive) until they > | > feel > | > comfortable distributing the code later. Â So, publicly, you get > | > version 12, 17, 34, and 37. Â There is no access to the intermediate > | > ones (unless you happen to be the one that created them and didn't > | > release them). Â The 'whole ancestry' let's you do diffs off of a > | > version derived from 37 against one derived from 34 - the ancestry > | > can > | > determine that version 34 if 'common', and work from there. Â [Note > | > that just numbers aren't enough - the original developer, say, cbc > | > could have version cbc.34, while you could have, say, > | > CamilloBruni.34, > | > but yours is based off of 17 (since you picked up that verison and > | > started working there). Â So, merging cbc.37 with CamilloBruni.34 > | > would > | > need to pull down cbc.17 for a good merge to work.] > | > > | > At least, that's my understanding from long ago discussions. > | > | This makes sense, but how is this handled with git ? > | > | Sven >

March 2, 2012

Re: [Pharo-project] Monticello Version Info

by Dale Henrichs

Chris, The last time I delved into the area there was one line of code in Monticello (I was looking at pharo) that compared the file UUID and it might have been involved in hashing. At one point the UUID calculation was broken in Pharo and noone noticed until they tried to load the package into GemStone (which is using an older version of Monitcello) and things went haywire:) So yes the name is the primary lookup mechanism... You might have gotten messed up by changing the name of the mcz file to NOT match the internal package name ... there are definitely expectations in the Monticello ecosystem that the package name and file name match at some level... Dale ----- Original Message ----- | From: "Chris Cunningham" <cunningham.cb(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Friday, March 2, 2012 8:30:27 AM | Subject: Re: [Pharo-project] Monticello Version Info | | On Fri, Mar 2, 2012 at 5:30 AM, Camillo Bruni | <camillobruni(a)gmail.com> wrote: | > | > But I am not completely sure how the internals work with MC, but | > from my research | > so far I am almost convinced that versions are found merely by | > their name. Since | > the VersionInfo does not track the repository it relates to. | > | It does appear to find versions by name, but there is an internal id | number that it uses to validate the file is the right one. I've been | 'bitten' by this a few times - it is a really good idea to NOT rename | MCZ files. | |

March 2, 2012

Re: [Pharo-project] Pharo 1.4 beta?

by Bernardo Ezequiel Contreras

+1. On Fri, Mar 2, 2012 at 11:48 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > +1 > > > On Fri, Mar 2, 2012 at 10:40 AM, Sebastian Sastre < > sebastian(a)flowingconcept.com> wrote: > >> +1 >> >> it would feel right (about timing) >> >> sebastian <http://about.me/sebastianconcept> >> >> o/ >> >> On Mar 2, 2012, at 5:48 AM, StÃ©phane Ducasse wrote: >> >> Hi guys >> >> I would like to see Pharo 1.4 going beta = >> focus on bugs, less changes. >> >> Does it make sense? >> >> What are the key problems we should focus on? >> >> Stef >> >> >> >> >> >> >> >> >

March 2, 2012

Re: [Pharo-project] Monticello Version Info

by Dale Henrichs

Sven, A Monticello mcz file is a version data base for a single package .... Git is a version data base for a directory structure ... Monticello has branching by convention (change the name of a file to create the branch), although the mcz ancestry handles branches just fine. In Git branches are first class objects ... it is difficult to do things in git if you are not on one branch or another ... You can merge with Monticello and you can merge with Git ... The big difference is that Git allows you to version a bunch of files together and with Monticello you are versioning a single file. Part of what Metacello was invented to do was to create a "data base" of versioned collections of mcz files ... Git was designed to manage collections of files... Is this what you were asking? Dale ----- Original Message ----- | From: "Sven Van Caekenberghe" <sven(a)beta9.be> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Friday, March 2, 2012 12:31:42 AM | Subject: Re: [Pharo-project] Monticello Version Info | | | On 02 Mar 2012, at 01:52, Chris Cunningham wrote: | | > The issue is that Monticello is setup for distributed processing, | > and | > allowing for multiple repositories, some of which may not be | > available | > to all of the users for a project. For instance, a project might | > be | > developed internally (or on the developers hard-drive) until they | > feel | > comfortable distributing the code later. So, publicly, you get | > version 12, 17, 34, and 37. There is no access to the intermediate | > ones (unless you happen to be the one that created them and didn't | > release them). The 'whole ancestry' let's you do diffs off of a | > version derived from 37 against one derived from 34 - the ancestry | > can | > determine that version 34 if 'common', and work from there. [Note | > that just numbers aren't enough - the original developer, say, cbc | > could have version cbc.34, while you could have, say, | > CamilloBruni.34, | > but yours is based off of 17 (since you picked up that verison and | > started working there). So, merging cbc.37 with CamilloBruni.34 | > would | > need to pull down cbc.17 for a good merge to work.] | > | > At least, that's my understanding from long ago discussions. | | This makes sense, but how is this handled with git ? | | Sven

March 2, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Igor Stasenko

On 2 March 2012 17:53, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > it sounds like having a couple interesting features. > > In system browsers I always felt missing the feature of a good tree > component (where the whole hierarchy is always available) while finding the > packages pane a terrible use of screen's real state. > +100. We need package hierarchy on screen. Yes. But it is enough ONE on screen, but not in every open browser window. I think that if we measure how often we using each of the panes in 4-pane layout i spending 99% of time in rightmost two, and using leftmost mainly to search for a class (which would make it completely unnecessary if we could have a shortcut for searching class from anywhere), and second one (class list) only occasionally. > How can I install this to play around? > > sebastian > > o/ > > > On Mar 2, 2012, at 6:54 AM, S Krish wrote: > > Couple of screenshots of a usable code browser, does well for my use > for now.. need to bring in the basic refactoring, variables text box > under the class tree, in the middle. > > Feels lot more productive in combination with the standard browsers > where needed. > > On 2/29/12, Krishsmalltalk <krishnamachari.sudhakar(a)gmail.com> wrote: > > > Sure I understood that, I am still just month and a half of dabbling in > > morphic, that i am still learning.... Â I do not take any comments amiss. > > > Thx > > > > On Feb 29, 2012, at 5:44 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > > I was not criticizing your solution. I was actually asking for help :). > > > I would like to get a text morph in the tree and have it scale both > > horizontally to fill the available space, and vertically to > > accommodate the entire text. I show the example with the > > GeneralScrollPane because I managed to make it work there (with the > > help of Gary), but I cannot do it on MorphTreeMorph. So, if you, or > > someone else, have ideas I would be happy to hear them. > > > Cheers, > > Doru > > > > > On Tue, Feb 28, 2012 at 10:09 AM, S Krish > > <krishnamachari.sudhakar(a)gmail.com> wrote: > > Sure.. that is fine.. for the use case you state > > > Mine is quick n dirty hack to what I wanted: > > > but my use case is I do wish to have more of these sources partially > > visible > > through the vertical pane. so I restrain it to max of 210.. and width of > > 600 > > to be able to to throw up another pane next to it.. for grouping methods > > I > > am interested in .. to view it more closely.. > > > > > On Tue, Feb 28, 2012 at 1:33 PM, Tudor Girba <tudor(a)tudorgirba.com> > > wrote: > > > Hi, > > > Thanks for the explanation. > > > I took a look. calculateExtent is triggered when you create the > > TextMorph. > > This is nice, but I am interested in getting the TextMorph to always > > expand > > to fill the width of the surrounding element, and to expand vertically > > according to the text :). > > > Here is a variation of what I am thinking about with just a simple list > > of > > morphs within a GeneralScrollPane: > > https://gist.github.com/1930477 > > > Cheers, > > Doru > > > > > On 28 Feb 2012, at 03:22, Krishsmalltalk wrote: > > > It does have the code to calculateTextExtent. You can modify it the way > > you want. > > > The height is defaulted to a max 210 and fixed 600. But on expand it > > goes to max ht of 600 > > > > Modify the logic in that method as you want it to > > > > On Feb 28, 2012, at 2:42 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > > I gave it a try. I am not necessarily looking for the looks as for the > > solution to make the text editor within the tree span horizontally and > > vertically with the size of the method. Unfortunately, this does not > > work in > > this example, either. > > > Does anyone have ideas of how to make it work? :) > > > Cheers, > > Doru > > > > On 27 Feb 2012, at 21:43, StÃ©phane Ducasse wrote: > > > MorphicViewNewPackageBrowser new packageNames: #('UIManager') ; open > > > > But it does not look that nice :) > > > > On Feb 27, 2012, at 6:42 PM, StÃ©phane Ducasse wrote: > > > this looks really nice. > > I would really like to see if we cannot include a version so that > > people can browse change set and other code like that. > > I'm really happy to see that the work done by alain and ben around > > treeMorph pays off that well. > > > Stef > > > > Can take the latest of the package.. > > > PackageTree-Browser-Experiment > > > * Find class added and a crude/ workable expand for text morph.. > > > As stated in the comments: will require a hack in Pharo 1.4 for > > now. > > > Will work towards integrating TabbedPane with TWM/ this too as an > > addon with more complete features month ahead. > > <Pharo_CodeBrowser02.JPG> > > > > > > > -- > > www.tudorgirba.com > > > "One cannot do more than one can do." > > > > > > > > -- > > www.tudorgirba.com > > > "Sometimes the best solution is not the best solution." > > > > > > > > -- > > www.tudorgirba.com > > > "Every thing has its own flow" > > > > <Pharo_Tabbed_TreeCodeBrowser01.JPG><Pharo_Tabbed_TreeCodeBrowser02.JPG> > > > > -- Best regards, Igor Stasenko.

March 2, 2012