- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] cleanup rubric

by Tudor Girba

TxText should only be considered for Bloc. This is where the future is, and we should invest our effort to build that future. Doru On Wed, Aug 5, 2015 at 9:16 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2015-08-04 21:29 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> >> > >>> > Hello all, >>> > Yes we have both PluggableTextMorph and Rubric so it is a mess. >>> > Yes Rubric was a fork, so a lot of code is duplicated. >>> > I would say just wait that all PluggableTextMorph uses are removed >>> > then we will be able to clean-up things. >>> > Now, remember that I was not so excited by Rubric as the default >>> editor. >>> > Rubric is the past, It should be removed asap with all the crap that >>> it duplicates. >>> > I would not invest to much time in cleaning and commenting it. >>> > Instead, clean, document and implement tests for TxText. >>> >>> Really? We move from pluggabletextmorph to rubric, just to move again to >>> txtext? >>> >>> >> Yes (it if is far from perfect but) now we decided to introduce rubric >> because >> TxText is not ready >> people need to be able to have line number and other niceties that >> Rubric has. >> Alain told me that it will be probably easier to move from Rub to >> TxText than >> from pluggable to TxText. >> >> And as one of the guy with franck doing most of the Pluggable -> Rubric >> migration we would have preferred to avoid and jump to TxText directly. >> > > > OK, so the plan is: > 1. replace old with rubric > 2. remove old > 3. cleanup rubric (maybe) > 4. move to txtext > > is the 4th step only doable for bloc, or do we want to use txtext in > morphic too? > > nicolai > > > > > >> >> Stef >> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 5, 2015

Re: [Pharo-dev] cleanup rubric

by Nicolai Hess

2015-08-04 21:29 GMT+02:00 stepharo <stepharo(a)free.fr>: > > > >> > Hello all, >> > Yes we have both PluggableTextMorph and Rubric so it is a mess. >> > Yes Rubric was a fork, so a lot of code is duplicated. >> > I would say just wait that all PluggableTextMorph uses are removed >> > then we will be able to clean-up things. >> > Now, remember that I was not so excited by Rubric as the default >> editor. >> > Rubric is the past, It should be removed asap with all the crap that it >> duplicates. >> > I would not invest to much time in cleaning and commenting it. >> > Instead, clean, document and implement tests for TxText. >> >> Really? We move from pluggabletextmorph to rubric, just to move again to >> txtext? >> >> > Yes (it if is far from perfect but) now we decided to introduce rubric > because > TxText is not ready > people need to be able to have line number and other niceties that > Rubric has. > Alain told me that it will be probably easier to move from Rub to > TxText than > from pluggable to TxText. > > And as one of the guy with franck doing most of the Pluggable -> Rubric > migration we would have preferred to avoid and jump to TxText directly. > OK, so the plan is: 1. replace old with rubric 2. remove old 3. cleanup rubric (maybe) 4. move to txtext is the 4th step only doable for bloc, or do we want to use txtext in morphic too? nicolai > > Stef > > >

Aug. 5, 2015

Re: [Pharo-dev] Nautilus new buttons not buttons?

by Franck Warlouzet

Hi, Thanks guys, but do not worry, I do not take opinions as critics. I learn in every domain so all questions and advices are helpful. I did not do real UI before Nautilus, so I think it is normal to make mistakes, but as I said, I learn from them and I will try to do my best to never do them again. This is what is so good with Pharo, direct feebacks allow us to get better day by day (at least I hope I am really getting better). When I am done with those buttons, you will not have buttons as labels anymore, I promise. ;-) Cheers, Franck > From: estebanlm(a)gmail.com > Date: Tue, 4 Aug 2015 22:18:16 +0200 > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] Nautilus new buttons not buttons? > > Franck is doing a great work. > Nowâ¦ that does not means we cannot have opinions :) > > cheers! > Esteban > > ps: that mail-waterfall just can means one thing: Stef is back! > > > On 04 Aug 2015, at 21:34, stepharo <stepharo(a)free.fr> wrote: > > > > You know in french we have this expressions" > > > > "y a ka" = you just need to do > > > > And this expressions conveys that it is way easier to say something than to do something. > > > > If you would really be nicer guys, you would congratulate franck for his efforts to improve nautilus. > > Because Nautilius is not easy and because we are trying our best. > > > > Stef > > > > > >

Aug. 4, 2015

Re: [Pharo-dev] Nautilus new buttons not buttons?

by Esteban Lorenzano

Franck is doing a great work. Nowâ¦ that does not means we cannot have opinions :) cheers! Esteban ps: that mail-waterfall just can means one thing: Stef is back! > On 04 Aug 2015, at 21:34, stepharo <stepharo(a)free.fr> wrote: > > You know in french we have this expressions" > > "y a ka" = you just need to do > > And this expressions conveys that it is way easier to say something than to do something. > > If you would really be nicer guys, you would congratulate franck for his efforts to improve nautilus. > Because Nautilius is not easy and because we are trying our best. > > Stef > >

Aug. 4, 2015

Re: [Pharo-dev] Nautilus new buttons not buttons?

by Peter UhnÃ¡k

On Tue, Aug 4, 2015 at 9:34 PM, stepharo <stepharo(a)free.fr> wrote: > You know in french we have this expressions" > > "y a ka" = you just need to do > > And this expressions conveys that it is way easier to say something than > to do something. > > If you would really be nicer guys, you would congratulate franck for his > efforts to improve nautilus. > Because Nautilius is not easy and because we are trying our best. > I don't see how that is relevant, because nobody is saying that what he has done is functionally bad. I like the provided functionality very much. What I've done is that I've raised a question about user experience, because I felt that there is room for improvement. And as I am not an UX expert I wanted to hear opinions of others. And this thread has clearly shown that there is different preference between form and function, which is fine, but just because you prefer one over the other doesn't make the discussion useless. After all this just follows the formula Make it work. Make it right. Make it fast. > And this expressions conveys that it is way easier to say something than to do something. This would be true if I said "It's bad and you should've done it better" and walk away, but I didn't do that. I was trying to tackle a problem and get to the bottom of it. Peter

Aug. 4, 2015

Re: [Pharo-dev] wrong syntax highlighting in debugger

by stepharo

Le 3/8/15 21:25, Nicolai Hess a Ã©crit : > > recent pharo 50 has wrong syntax highlighting. This is caused > by my fix for issue 15773. > > I am working on that thanks :) > > nicolai

Aug. 4, 2015

Re: [Pharo-dev] Using Kommiter I got a problem with diff morph and rubric

by stepharo

thanks a lot franck. Le 2/8/15 00:32, Franck Warlouzet a Ã©crit : > Right I forgot to call scrollPane on the morph before scroller in this > method. I did not see it because I do not use Komitter. > > Fixed here: > > https://pharo.fogbugz.com/f/cases/16088/Fix-DiffMorph-when-called-from-Komi… > > Franck > > > > Date: Sat, 1 Aug 2015 22:05:15 +0200 > > From: stepharo(a)free.fr > > To: pharo-dev(a)lists.pharo.org > > Subject: [Pharo-dev] Using Kommiter I got a problem with diff morph > and rubric > > > > Hi frank > > > > when I tried to save a project, Kommiter is invoked and I got > > > > calibrateScrollbar > > "Set the scrollbar parameters to match the texts." > > > > | maxY range delta innerH | > > self fullBounds. > > maxY := self srcMorph extent y max: self dstMorph extent y. > > innerH := self dstMorph innerBounds height. > > delta := 91. "self dstMorph textMorph defaultLineHeight" > > range := maxY - innerH max: 0. > > range = 0 > > ifTrue: [ > > ^ self scrollbarMorph > > scrollDelta: 0.02 pageDelta: 0.2; > > interval: 1.0; > > setValue: 0.0 ]. > > self scrollbarMorph > > scrollDelta: (delta / range) asFloat pageDelta: ((innerH - > > delta) / range) asFloat; > > interval: (innerH / maxY) asFloat; > > setValue: > > ((self srcMorph scroller offset y max: self dstMorph > > scroller offset y) / range min: 1.0) asFloat > > > > ^^^^^^^ > > > > where srcMoirph is a RubScrolledTextMorph > > > > Stef > >

Aug. 4, 2015

Re: [Pharo-dev] Nautilus new buttons not buttons?

by stepharo

You know in french we have this expressions" "y a ka" = you just need to do And this expressions conveys that it is way easier to say something than to do something. If you would really be nicer guys, you would congratulate franck for his efforts to improve nautilus. Because Nautilius is not easy and because we are trying our best. Stef

Aug. 4, 2015

Re: [Pharo-dev] cleanup rubric

by stepharo

> > > > Hello all, > > Yes we have both PluggableTextMorph and Rubric so it is a mess. > > Yes Rubric was a fork, so a lot of code is duplicated. > > I would say just wait that all PluggableTextMorph uses are removed > > then we will be able to clean-up things. > > Now, remember that I was not so excited by Rubric as the default > editor. > > Rubric is the past, It should be removed asap with all the crap that > it duplicates. > > I would not invest to much time in cleaning and commenting it. > > Instead, clean, document and implement tests for TxText. > > Really? We move from pluggabletextmorph to rubric, just to move again > to txtext? > Yes (it if is far from perfect but) now we decided to introduce rubric because TxText is not ready people need to be able to have line number and other niceties that Rubric has. Alain told me that it will be probably easier to move from Rub to TxText than from pluggable to TxText. And as one of the guy with franck doing most of the Pluggable -> Rubric migration we would have preferred to avoid and jump to TxText directly. Stef

Aug. 4, 2015

Re: [Pharo-dev] open street map example

by stepharo

really nice. Stef Le 3/8/15 17:28, Alexandre Bergel a Ã©crit : > Hi! > > Some of you have an interest in visualizing graphs on top of open > street maps. > Together with Hilaire we made a small example: > > -=-=-=-=-=-=-=-=-=-=-=-= > | v map data b d whiteBackground london elementsAndEdges | > v := RTView new. > v @ RTDraggableView. > map := RTOSM new. > v add: map element. > > "Place to set the data and center the camera" > london := 51.507222@ -0.1275. > "Some arbitrary data" > data := ((1 to: 500) collect: [ :i | 50 atRandom - 25 ]) cumsum. > > "We build the graph" > b := RTGrapher new. > b extent: 100@30. > d := RTData new. > d noDot. > d connectColor: Color red. > d points: data. > > b add: d. > b axisY > labelFontHeight: 6; > color: Color red; > title: 'Sale'. > > b axisX color: Color red; noTick; title: 'country'. > b build. > elementsAndEdges := b view elements, b view edges. > > "We create a white background" > whiteBackground := (RTRoundedBox new color: Color white trans; > borderRadius: 10) element. > v add: whiteBackground. > v addAll: elementsAndEdges. > RTNest new on: whiteBackground nest: elementsAndEdges. > whiteBackground translateTo: (map latLonToRoassal: london). > > v canvas camera translateTo: (map latLonToRoassal: london). > v canvas camera noInitializationWhenOpen. > v canvas camera scale: 1.5. > v > -=-=-=-=-=-=-=-=-=-=-=-= > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > >

Aug. 4, 2015