February 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Tiny Static File Server cleanup

by Camillo Bruni

On 2013-02-06, at 18:53, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Camillo Bruni-3 wrote >> do you have access to the gforge? > > Not that I know of... who would I ask? I don't remember, but I think you could register here somhwere: https://gforge.inria.fr/

Feb. 6, 2013

Re: [Pharo-project] Tiny Static File Server cleanup

by Sean P. DeNigris

Camillo Bruni-3 wrote > do you have access to the gforge? Not that I know of... who would I ask? -- View this message in context: http://forum.world.st/Tiny-Static-File-Server-cleanup-tp4668028p4668062.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 6, 2013

[Pharo-project] Give http://ss3.gemstone.com/ss/MetaRepoForPharo20 some love !

by Sven Van Caekenberghe

With 2.0 almost ready, it would be great if everybody gave http://ss3.gemstone.com/ss/MetaRepoForPharo20 some love. Currently, the Configuration Browser looks like this: I am missing many, many, well know, useful packages right there. So if you have some generally useful package you maintain and that you know loads and works well with Pharo 2.0 (and that you are willing to maintain), please copy its Metacello Configuration in http://ss3.gemstone.com/ss/MetaRepoForPharo20 ! That is really all there is to it. You will make life for others so much easier, and improve exposure for the software you wrote. Let's make one-click installs real. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Feb. 6, 2013

Re: [Pharo-project] Tiny Static File Server cleanup

by Camillo Bruni

do you have access to the gforge? I'll remove it for now... On 2013-02-06, at 17:33, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > http://pharo.gforge.inria.fr/ci/image/20/50512.zip has an incorrect update > number and sorts to the top of the list. Will someone please remove it... or > give me access and never see another post like this again :) > > > > -- > View this message in context: http://forum.world.st/Tiny-Static-File-Server-cleanup-tp4668028.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Feb. 6, 2013

Re: [Pharo-project] AbstractNautilusPlugin positions

by Sean P. DeNigris

Benjamin Van Ryseghem-2 wrote > Because I planned to implement #right #left but never did :) Issue 7431: [Cleanup]: AbstractNautilusPlugin class>>#defaultPosition comment suggests non-existent http://code.google.com/p/pharo/issues/detail?id=7431 Fix in inbox: SLICE-Issue-7431-Cleanup-AbstractNautilusPlugin-classgtgtdefaultPosition-comment-suggests-non-existent-options-SeanDeNigris.1 Simply refer to #possiblePositions -- View this message in context: http://forum.world.st/AbstractNautilusPlugin-positions-tp4668026p4668037.ht… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 6, 2013

Re: [Pharo-project] AbstractNautilusPlugin positions

by Benjamin

Because I planned to implement #right #left but never did :) Ben On Feb 6, 2013, at 5:28 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > class-side #possiblePositions lists #top. #middle. #bottom. #none. > but class-side #defaultPosition comment: > " should answer the position of the UI " > "Pick an answer among: > - #top > - #right > - #left > - #middle > - #bottom > - #none" > > Why are these lists not the same? > > Cheers, > Sean > > > > -- > View this message in context: http://forum.world.st/AbstractNautilusPlugin-positions-tp4668026.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Feb. 6, 2013

[Pharo-project] Tiny Static File Server cleanup

by Sean P. DeNigris

http://pharo.gforge.inria.fr/ci/image/20/50512.zip has an incorrect update number and sorts to the top of the list. Will someone please remove it... or give me access and never see another post like this again :) -- View this message in context: http://forum.world.st/Tiny-Static-File-Server-cleanup-tp4668028.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 6, 2013

[Pharo-project] AbstractNautilusPlugin positions

by Sean P. DeNigris

class-side #possiblePositions lists #top. #middle. #bottom. #none. but class-side #defaultPosition comment: " should answer the position of the UI " "Pick an answer among: - #top - #right - #left - #middle - #bottom - #none" Why are these lists not the same? Cheers, Sean -- View this message in context: http://forum.world.st/AbstractNautilusPlugin-positions-tp4668026.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 6, 2013

Re: [Pharo-project] TextModel review and discussion

by Sean P. DeNigris

Benjamin Van Ryseghem-2 wrote > We really need to kill this ugly monster, and make it turn into a nice > butterfly for 3.0 :) YES!!! -- View this message in context: http://forum.world.st/TextModel-review-and-discussion-tp4668021p4668025.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 6, 2013

Re: [Pharo-project] TextModel review and discussion

by Benjamin

Cool :) We really need to kill this ugly monster, and make it turn into a nice butterfly for 3.0 :) Just a tiny question: Shouldn't the code belong to RMoD team instead of Igor on SmalltalkHub ? Ben On Feb 6, 2013, at 3:56 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hi, today, me, Tristan and Camillo took some overview on existing > code and discussed further steps. > > TxAttributes > 'contents' should be private (no getter/setter) > > because if you can directly manipulate the underlying collection, then > what is the point of having separate class? > > Text Attributes in general: > > - we discussed and decided that it would be better that model will > keep abstract attributes for text , like > - bold > - italic > - font family name > > the view then can compute the real font to use, but model don't have > to deal with real font(s). > > This will imply having more complex attribute(s): you will be forced > to visit them all to determine all of the font properties > of a final font to use. > > The attributes in span should behave like a set (you cannot apply same > attribute once), > and hence implement #= and #hash properly. > > Also, i think, since neither bold, nor italic attributes don't need to > be represented by multiple instances of same class, > we could use convenience methods (by introducing them) in TxAttribute > class to get a singletons for those ones, e.g.: > > selection applyAttribute: TxAttribute bold > > Layout: > - right now, when you do layout it will split spans of txmodel. Which > should not happen. > > We discussed about it and agreed that layouts(views) should not modify > anything in text model. > Instead the information about where line has to be split (like when > you need to wrap a text) should be kept > separately by a view. > > We thought that it would be nicer to implement a new span type > (layoutspan), which will hold > an text-interval (pos1, pos2) and probably any additional information > (like caching the width/height) > to not recalculate this stuff if nothing changed in model. > > > We did some cosmetic changes to configuration.. to merge Tristan's > code into it and load most recent packages: > > Gofer it > smalltalkhubUser: 'sig' project: 'TxText'; > package: 'ConfigurationOfTxText'; > load. > > (ConfigurationOfTxText project version: '0.3') load: 'Tests' > > -- > Best regards, > Igor Stasenko. >

Feb. 6, 2013