- Pharo-dev - lists.pharo.org

Re: [Pharo-project] need hunter to kill the double paste bug.

by Lukas Renggli

Another thing, this is not something that is only related to the clipboard. I've seen a similar thing happen when I use a keyboard shortcut that opens a dialog. In some cases the initial selection of a text-field is replaced by the keyboard shortcuts character, e.g. pressing Ctrl+x to delete a method inserts sometimes the x into the confirmation dialog. Lukas 2009/12/19 George Herolyants <george.herolyants(a)gmail.com>: > 2009/12/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> On Thu, Dec 17, 2009 at 4:20 PM, Michael Rueger <m.rueger(a)acm.org> wrote: >>> >>> Do people actually experience the double paste problem on non-Mac >>> platforms? >> >> No. Only mac. I have been using Pharo in Linux and Windows, and happpens >> only on Mac I think. > > I've never expirienced this problem on Windows, too. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 19, 2009

Re: [Pharo-project] need hunter to kill the double paste bug.

by George Herolyants

2009/12/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: > On Thu, Dec 17, 2009 at 4:20 PM, Michael Rueger <m.rueger(a)acm.org> wrote: >> >> Do people actually experience the double paste problem on non-Mac >> platforms? > > No. Only mac. I have been using Pharo in Linux and Windows, and happpens > only on Mac I think. I've never expirienced this problem on Windows, too.

Dec. 19, 2009

Re: [Pharo-project] Pharo for Professional Development

by Pavel Krivanek

On Fri, Dec 18, 2009 at 1:39 PM, George Herolyants <george.herolyants(a)gmail.com> wrote: > 2009/12/18 Michael Rueger <m.rueger(a)acm.org>: >> Henrik Johansen wrote: >> >> Interestingly enough a lot of the (complex) multiple native window >> applications have (gone back to) all in one window UIs (Eclipse, all of >> the Adobe products, ...). > > Yeah! That's true. And their look&feel may differ from the underlying > os. And everyone uses them without complaining. So what's wrong with > pharo? Maybe one of the weak points is that it simulates windowing > system inside another one, when other applications (Eclipse, > Netbeans...) have strongly defined layout (though customizable)? I > think it's a real issue. Pharo Development Environment is *Integrated* > but the UI still lacks this integration in some places, IMHO. > > But I think multiple windows in the meaning of what for example > firefox has will be helpful as well. I mean two or more usual pharo > windows "connected" to the same image. Is that possible? > > And native basic dialogs may be helpful too, to not reinvent the wheel > (aka FileBrowser :). > > I vote for the WhiskerBrowser with all the cool OB stuff integrated! ;) > > Cheers, > George > Hi, you may be interested in SeasideXUL project (http://code.google.com/p/seasidexul/) The rendering of UI with native look&feel is a responsibility of the standard Mozilla XULRunner and there may be several clients connected to one image. However the OmniBrowser binding and code editor is not in the production ready state now. Cheers, -- Pavel

Dec. 19, 2009

Re: [Pharo-project] Pharo IDE usability (was Re: Pharo for Professional Development)

by Mariano Martinez Peck

On Sat, Dec 19, 2009 at 10:13 AM, Geert Claes <geert.wl.claes(a)gmail.com>wrote: > > > > Lukas Renggli wrote: > > > > The browser environments are described in (upcoming) "Pharo by > > Example" chapter "Reflection" in the section "Browsing environments": > > > > > https://www.iam.unibe.ch/scg/svn_repos/SqueakByExample/PharoBook/Reflection… > > > > Is there an HTML version or how do I read this .tex thingy? > I don't know, but here you can find the pdf of the book and you can look to the reflection chapter if you want. http://pharobyexample.org/ > -- > View this message in context: > http://n2.nabble.com/Pharo-IDE-usability-was-Re-Pharo-for-Professional-Deve… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 19, 2009

Re: [Pharo-project] Pharo IDE usability (was Re: Pharo for Professional Development)

by Geert Claes

Lukas Renggli wrote: > > The browser environments are described in (upcoming) "Pharo by > Example" chapter "Reflection" in the section "Browsing environments": > > https://www.iam.unibe.ch/scg/svn_repos/SqueakByExample/PharoBook/Reflection… > Is there an HTML version or how do I read this .tex thingy? -- View this message in context: http://n2.nabble.com/Pharo-IDE-usability-was-Re-Pharo-for-Professional-Deve… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 19, 2009

Re: [Pharo-project] Pharo IDE usability (was Re: Pharo for Professional Development)

by Geert Claes

Mariano Martinez Peck wrote: > > YES!!!! Exactlly...that's what I always said...I doesn't matter how nice > and very good implemented is the Pharo core if the pharo dev is not cool, > they won't use it. Of course, most of the times happens that to achieve a > good pharo dev image, we need first a good core. > > But we are in the way. I hope Metacello can help us and also the test > server and all that related stuff. > Once the core (Packages/Categories/Projects/Components and dependencies) makes a bit more sense (Metacello?), innovation building on top of that will be just around the corner I reckon. -- View this message in context: http://n2.nabble.com/Pharo-IDE-usability-was-Re-Pharo-for-Professional-Deve… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 19, 2009

Re: [Pharo-project] Default code browser

by Geert Claes

StÃ©phane Ducasse wrote: > > On of the idea is to use glamour to experiment new browsers and probably > to > write it from scratch when we know what is really good. > What I have seen so far I have to say I really like Glamour! I like a lot of Pharo stuff and can't wait to see the next package management system in 1.1. Go Pharo :) -- View this message in context: http://n2.nabble.com/Default-code-browser-tp4183317p4190785.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 19, 2009

Re: [Pharo-project] [squeak-dev] The Trunk: Kernel-dtl.331.mcz

by Eliot Miranda

Hi David, Interesting! To my mind that definition is incorrect. I would expect the sender of a block to be the sender of the enclosing method, in which case the definition would arguably be BlockClosure methods for accessing sender ^self home sender A block activation's caller would be it's sender slot, so within a block you might refer to thisContext caller. But what is arguably a bug in my implementation is that within a block activation thisContext sender refers to the caller (the sender of value: to the activation's block) not to the sender of the enclosing method. I think I may have screwed up badly here and that the correct implementations should be *MethodContext methods for accessing* *caller* ^closureOrNil ifNil: [self error: 'this is a method activation and so has no caller'] ifNotNil: [sender] *sender* ^closureOrNil ifNil: [sender] ifNotNil: [closureOrNil outerContext sender] *BlockClosure methods for accessing* *sender* * ^outerContext sender* and either *BlockClosure methods for accessing* *caller* * "Since a BlockClosure is by definition not an activation it does not have a caller.* * It has a sender because it is always created within the context of a method."* ^nil or *BlockClosure methods for accessing* *caller* ^self error: 'this is an inactive block and so has no caller' I believe the pre-closure definitions are *ContextPart methods for accessing* *sender* ^sender *BlockContext methods for accessing* *caller* ^sender which to my mind is missing *BlockContext methods for accessing* *sender* ^home sender What do people think the right definitions should be? On Fri, Dec 18, 2009 at 8:36 PM, <commits(a)source.squeak.org> wrote: > David T. Lewis uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-dtl.331.mcz > > ==================== Summary ==================== > > Name: Kernel-dtl.331 > Author: dtl > Time: 18 December 2009, 11:32:44 am > UUID: 20ffffda-86bc-47a7-8eae-cd11b55aa65e > Ancestors: Kernel-bs.330 > > Add BlockClosure>>sender required for MessageTally class>>tallySends: > > Harvested from Pharo (nice 4/14/2009 19:09). > > =============== Diff against Kernel-bs.330 =============== > > Item was added: > + ----- Method: BlockClosure>>sender (in category 'debugger access') ----- > + sender > + "Answer the context that sent the message that created the > receiver." > + > + ^outerContext sender! > > >

Dec. 19, 2009

Re: [Pharo-project] Default code browser

by StÃ©phane Ducasse

Yes gather together publish it on squeaksource and fix it. Stef On Dec 18, 2009, at 10:20 PM, laurent laffont wrote: > 2009/12/18 George Herolyants <george.herolyants(a)gmail.com> > 2009/12/18 GeertClaes <geert.wl.claes(a)gmail.com>: > > George Herolyants-3 wrote: > >> > >> Though I think WhiskerBrowser still covers the above use case better. > >> Unfortunately it doesn't run on Pharo. > >> > > > > Maybe WhiskerBrowser can be created using Glamour? > > I don't now. IIRC someone on the list mentioned that Glamour can't be > used to build real browsers for now, but I may be wrong. > I wonder, if it can be done using OB? It would be cool if it was possible. > Recently I loaded it into Pharo but it relies on some missing classes > and expects some old behaviour from underlying libraries. It worked > somehow but it has some visual artefacts (for example boxes for tree > menu items are smaller than the text they contain; see in the > attachment). And of course in lacks all the cool stuff OB has. > > Cheers, > George > > > I've just tried Whisker on Pharo... buggy but there's some great ideas inside !! > > Laurent > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 19, 2009

Re: [Pharo-project] Default code browser

by StÃ©phane Ducasse

On of the idea is to use glamour to experiment new browsers and probably to write it from scratch when we know what is really good. Ideally I like the multiple method showing of whisker but not the rest david implemented that in OB. I like the fact that O2 supports the view of class extension view per packages Now I avoid to talk about browsers because we do not have somebody in the community working heavily on that beside david and david may leave once he will finish his PhD. Now OB metamodel does not support tree and make it difficult to have something like the class comment visible close to the class definition. On Dec 18, 2009, at 3:47 PM, GeertClaes wrote: > > > George Herolyants-3 wrote: >> >> Though I think WhiskerBrowser still covers the above use case better. >> Unfortunately it doesn't run on Pharo. >> > > Maybe WhiskerBrowser can be created using Glamour? > -- > View this message in context: http://n2.nabble.com/Default-code-browser-tp4183317p4186933.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 19, 2009