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

Re: [Pharo-project] Gofer issue

by Lukas Renggli

> Ok so I have the impression that we could get rid of branching or use another delimiter. You cannot get rid of branching, this is a central part of version control and extensively used in many large projects. In Seaside we use the following pattern, also see the documentation at http://code.google.com/p/seaside/wiki/PackageNaming: Package = PackageName "-" Author { "." Branch } "." Version However I noticed that other projects (and earlier versions of Seaside) use a different scheme: Package = PackageName { "." Branch } "-" Author "." Version In this case I guess we must support: Package = PackageName { "." Branch } "-" Author { "." Branch } "." Version However, that doesn't change that $. and $- cannot be part of the PackageName or Author. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 24, 2011

Re: [Pharo-project] Tabs and back button in browser?

by Tudor Girba

Hi Janko, Good observation. I too believe that to bring Pharo further we have to rethink the IDE experience altogether. This requires more than just patch the existing IDEs with a couple of widgets. I am definitely interested in working on this. The work on Glamour goes towards providing an infrastructure for such new kinds of tools. For example, tabs are now nicely supported in several forms. Navigation is indeed not yet supported, but it is on the roadmap. The major problem currently is posed by the Morphic widgets. Gary and Alain are doing a great job, but it would be cool if we would get a more concerted effort in this area. If anyone is interested in spending energy on this, please contact me. Cheers, Doru On 24 Jan 2011, at 14:47, Janko MivÅ¡ek wrote: > Hi Pharoers, > > Are you thinking about introducing tabs and back/forward button, like in > web browsers? > > Just because of web we are now all accustomized and used of tabbed > browsing and navigation with a back and forward buttons. This habit now > demands all other tools to follow. Tabs are now everywhere, also in > Smalltalk. Look at Visualworks, also Dolphin. > > Introducing tabs soon in Pharo will therefore greatly improve user > experience, so if someone would spend some time on it, his contribution > will be very valuable! > > Best regards > Janko > > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si > -- www.tudorgirba.com "We cannot reach the flow of things unless we let go."

Jan. 24, 2011

Re: [Pharo-project] What about a little rename in MouseEvent?

by StÃ©phane Ducasse

I would like to have the iSqueak Event hierarchy. It is published in PharoTaskForces if I remember correctly. Stef > I hate yellowButtonPressed and redButtonPressed and blueButtonPressed messages. > > Why not lefClick, rightClick and "middleClick"? > > Cheers, > Guille

Jan. 24, 2011

Re: [Pharo-project] Gofer issue

by StÃ©phane Ducasse

Ok so I have the impression that we could get rid of branching or use another delimiter. Would it be ok? Lukas? Dale? Stef On Jan 24, 2011, at 7:06 PM, Dale Henrichs wrote: > On 01/22/2011 12:37 AM, StÃ©phane Ducasse wrote: >> I think that a stupid numbering like the one we have now is not so bad, you do not want to force >> the tools to read all the metadata inside the files. >> I think that we have many more places where we should improve: UI, network layer, Filesystem..... > > I tend to agree, but... > >> >> So with a simple fix in the tools to follow a pattern we can get a good impact. >> So what is the right pattern so that Gofer and Metacello are happy? > > Upon closer examination of the Metacello code, I see that for sorting and comparison operations, Metacello pretty much follows the Gofer sorting scheme (separate methods for wider range of comparison operators)... The departure from Gofer comes in how Metacello matches a package name to a working copy... > > So in the end if you make Gofer happy you make Metacello happy. > > Pharo/Gofer parses the package file name looking for the following pattern" > > packageName, '-', author, '.', branch, '.', counter > > and Squeak/GemStone parses the package file name with this pattern: > > packageName, '-', 'author', '.', counter > > > In Squeak/GemStone, the author is allowed to contain '.' and in Pharo a '.' in the author name causes the characters following the '.' to be interpreted as a branch names and in the sorting scheme for Gofer branches have precedence over the counter....which is why Igor's seeing the "wrong sort order in Gofer". > > In the Squeak/GemStone pattern, branches were indicated by a '.' in the packageName: > > packageName, '.', branch, '-', author, '.', branch, '.', counter > > To see examples just look at the old Seaside package names...Nothing about this ever made it into the code, but when I asked Avi way back when .. that is what he told me and I've been using it for years > > In terms of trying to get Metacello to run on multiple platforms, Pharo naming scheme is a headache, because Squeak/Gemstone allows '.' in author names and Gofer parses them as branch names leading to subtle problems as we've seen > > Personally, I have never seen a package in the wild that uses the Pharo 'branch' naming scheme...I have just seen problems caused by the 'branch' naming scheme. > > The RepositoryInspector itself uses the meta information when it sorts so it doesn't use the package name at all and in Igor's case, CMakeVMMaker-EstebanLorenzano.15 is an ancestor of CMakeVMMaker-Igor.Stasenko.16 and shows CMakeVMMaker-Igor.Stasenko.16 as the latest version, which means that the tools are inconsistent... > > My opinion is that the 'branch' naming scheme just causes problems and isn't in common use so I wouldn't mind seeing it dropped. Without the Pharo-style branch naming scheme a simple-minded sort based on the counter usually matches the actual ancestry... > > With that said I have seen projects with package naming conventions that don't include author names and don't have counters, so the naming schemes for packages is just a mess...without digging in and using the actual ancestry meta information, we are guaranteed to have inconsistencies no matter what we do... > > Dale

Jan. 24, 2011

Re: [Pharo-project] default styler is shout

by StÃ©phane Ducasse

ok we will have to iterate once more time... :) Tx for the report lukas. Stef On Jan 24, 2011, at 5:37 PM, Lukas Renggli wrote: > I mean with the old ParagraphEditor. I am not saying that the old > ParagraphEditor was better (it had lots of other problems), but the > separation between Editor and SmalltalkEditor makes the OB code much > more complicated. > > Also having to send #beStyled is kind of tricky. The previous pull > mechanism with #shoutWantsToBeStyled: was much more useful as the > model of the editor could decide itself how and if it wanted to be > styled. Now the model (or some other new entity inbetween) needs to > know the view and update the editor all the time. > > Lukas > > On 24 January 2011 08:23, Alain Plantec <alain.plantec(a)free.fr> wrote: >> Hi Lukas, >> When you say "previously" do you mean with >> ParagraphEditor or with previous version of >> Editor/TextEditor/SmalltalkEditor ? >> Cheers >> Alain >> >> >> Le 24/01/2011 16:46, Lukas Renggli a Ã©crit : >>> >>> Just as an additional comment (don't know if this is related or not): >>> >>> For OB I had to subclass Editor and duplicate all SmalltalkEditor >>> functionality, because the same Morph instance is used different >>> contexts. Previously it was very easy to enable and disable syntax >>> highlighting and other Smalltalk specific functionality. >>> >>> Lukas >>> >>> On 24 January 2011 00:10, Tudor Girba<tudor.girba(a)gmail.com> wrote: >>>> >>>> Hi, >>>> >>>> I opened a ticket. We should move the discussion there: >>>> http://code.google.com/p/pharo/issues/detail?id=3583 >>>> >>>> Cheers, >>>> Doru >>>> >>>> On 24 Jan 2011, at 08:31, Marcus Denker wrote: >>>> >>>>> On Jan 24, 2011, at 2:19 AM, Guillermo Polito wrote: >>>>> >>>>>> But that imperfect solution won't be a good solution either, since we >>>>>> are not going to have shout styler anywhere :). >>>>>> >>>>> So how is that solved in1.1? We need, for 1.2, just a *usable* >>>>> compromise. Then we can iterate in 1.3 >>>>> >>>>> Marcus >>>>> >>>>> >>>>> -- >>>>> Marcus Denker -- http://www.marcusdenker.de >>>>> INRIA Lille -- Nord Europe. Team RMoD. >>>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "In a world where everything is moving ever faster, >>>> one might have better chances to win by moving slower." >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

Jan. 24, 2011

Re: [Pharo-project] Tabs and back button in browser?

by StÃ©phane Ducasse

I would love but time/money usual problem. Not lack of vision or will. Stef On Jan 24, 2011, at 2:47 PM, Janko MivÅ¡ek wrote: > Hi Pharoers, > > Are you thinking about introducing tabs and back/forward button, like in > web browsers? > > Just because of web we are now all accustomized and used of tabbed > browsing and navigation with a back and forward buttons. This habit now > demands all other tools to follow. Tabs are now everywhere, also in > Smalltalk. Look at Visualworks, also Dolphin. > > Introducing tabs soon in Pharo will therefore greatly improve user > experience, so if someone would spend some time on it, his contribution > will be very valuable! > > Best regards > Janko > > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

Jan. 24, 2011

Re: [Pharo-project] Hapao for Test coverage!

by StÃ©phane Ducasse

This is cool to have news! Excellent idea. I will try to help you to post regularly. On Jan 24, 2011, at 11:01 AM, Marcus Denker wrote: > On Thu, Jan 20, 2011 at 6:41 PM, Vanessa PeÃ±a <vane.c.pena(a)gmail.com> wrote: >> Hello all, >> >> We are happy to introduce you Hapao, an innovative test coverage tool which >> gives you an intuitive graphical representation to visually assess the >> quality of the coverage. >> >> For more information and download you can visit us at: >> http://hapao.dcc.uchile.cl/ >> Of course, all feedback is always welcome :) >> > Very nice! > > One small thing: the dialog selecting the packages at the beginning should > label the button "continue"", not "terminate" (which sounds like cancel to me). > > I added a blog post: http://pharo-project.org/news > > > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de >

Jan. 24, 2011

Re: [Pharo-project] whisker browser

by StÃ©phane Ducasse

I should have the code but only for a 3.8 or older version. With the code gary sent around it would be cool to build it. Stef On Jan 24, 2011, at 10:12 AM, Tudor Girba wrote: > Hi, > > Does anybody have an image with a working Whisker Browser? I would be interested in learning from it. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > >

Jan. 24, 2011

[Pharo-project] Issue 3590 in pharo: AntiAliased fix

by pharo＠googlecode.com

Status: Fixed Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3590 by stephane...(a)gmail.com: AntiAliased fix http://code.google.com/p/pharo/issues/detail?id=3590 Out of curiosity, I executed your code in Squeak and the antialiasing > works there. Debugging a little, I found a difference in > BalloonCanvas>>#line:to:width:color:. If you update Pharo's > implementation with Squeak's one it works in Pharo as well. > There might be other differences so you might look into that. Thanks Ricardo Moran Attachments: BalloonCanvas-linetowidthcolor.st 451 bytes

Jan. 24, 2011

Re: [Pharo-project] doc on ob requests and commands

by Lukas Renggli

Performing a user interaction always goes through signaling the notification. For example to request a text input: expression := OBTextRequest new prompt: 'Enter a matching expression'; signal Or to open the completion dialog: category := OBCompletionRequest new assisted: true; collection: categories; prompt: 'Add Category'; signal Or to open a new browser: view := OBBrowseRequest new browser: OBSystemBrowser new; signal Note that Morphic raises some interaction notifications in a very hackish too (with information stuffed into arrays and dictionaries) when opening some (of course not all) of the user interactions. OB implemented its own user interaction mechanism long before Morphic was improved and also to remain independent of the platform/view. Lukas On 24 January 2011 13:07, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi Lukas, > > On 24 Jan 2011, at 15:57, Lukas Renggli wrote: > >>> My main current question is what are the reasons for OBInteractionRequest to subclass Notification? >> >> To be able to perform user interactions anywhere without having a >> global OBPlatform instance, and without having to pass OBPlatform in >> or store OBPlatform anywhere. There can be multiple UI platforms >> active at the same time and they can even change over the lifetime of >> a single browser window. > > I am not sure I understand. Why did it have to be a subclass of Notification? Would it not be enough to have it as a subclass of Object? > > Cheers, > Doru > > > >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > -- > www.tudorgirba.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > > -- Lukas Renggli www.lukas-renggli.ch

Jan. 24, 2011