- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Nicolai Hess

Am 09.01.2016 11:03 vorm. schrieb "Esteban Lorenzano" <estebanlm(a)gmail.com>: > > you have to confess that with text and icons looks a lot better than the old one :P > Yes alot better >> On 09 Jan 2016, at 11:01, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> again re-send because of exceed limits with the image (thatâs new?) >> >> with a small tweak, texts (AND icons :P): >> >> >> <Screen Shot 2016-01-09 at 10.59.20.png> >> >> would that be aceptable for you? >> >> cheers! >> Esteban >> >>> On 09 Jan 2016, at 09:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> (re-send because I exceeded limit.) >>> >>> Hi, >>> >>> letâs think positive. >>> the GTDebugger is a step forwardâ¦ it allow a lot of better interactions and of course, it needs some iterations to make it appealing to everybody. >>> For instance, I took me 2â to tweak the debugger presentation and to get this: >>> >>> <Screen Shot 2016-01-09 at 09.29.59.png> >>> >>> (I changed all availableâ¦ is a trivial task) >>> >>> and like IMO feels a lot betterâ¦ and I think is a good compromise between the old and the new. >>> Reasons to suggest this approach: >>> >>> - it keeps old approach who(I think) was good (I can see the stack, and the flow feels natural from top to down) >>> - it preserves âthe importantâ (the code) as central. >>> - it gives space for adding columns (like the bytecode). >>> >>> Nowâ¦ I can understand you want icons with text, and that can be hacked tooâ¦ >>> >>> Soâ¦ can we have an agreement? >>> >>> Esteban >>> >>> ps: btwâ¦ using GT with Fast Table we can also avoid those annoying paginated lists too >>> >>>> On 09 Jan 2016, at 08:53, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> Thanks for your testimony. >>>> >>>> I'm not against GTDebugger per se. I believe that we should have better tools >>>> but we should take time for building better tools (even if this is two years that moosers use or not this new debugger). >>>> I would appreciate a process where users can give real feedback and we can simplify/shape our tools nicely. >>>> >>>> Now for the mooc I will not present GTDebugger. So students will not use Pharo 50 >>>> >>>> Stef >>>> >>>>> Le 08/01/2016 21:22, stepharo a Ã©crit : >>>>>> >>>>>> I'm sorry but this debugger should not be the default one. >>>>>> MONDAY we are filming our mooc and we have to explain the debugger and >>>>>> personally I do not see the gain: >>>>>> - It looks a lot more complex to me and I do not want to have to >>>>>> redo all the screenshots >>>>>> of our lecture. >>>>>> - Just that I have to learn the meaning of small icons. >>>>>> - Why do we need a special pane for the evaluator >>>>>> - Why there is a type column. >>>>>> - Sorry but I'm not convinced about the moldable aspect behind the >>>>>> story (no need to argue I know it) >>>>>> >>>>>> I would like to avoid to be forced to use not the latest version of >>>>>> Pharo for the mooc. >>>>>> >>>>>> Such changes are arriving far too late in the release. We do not change >>>>>> the debugger itself the day of code freeze. >>>>>> >>>>>> We decided that the GTDebugger can be included but to me it never meant >>>>>> that it should be the default one. >>>>>> I think that experts can choose the debugger they want. The newbies don't. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>> IMO the old debugger is way more intuitive. >>>>> When I used the debugger of Eclipse for java I was lost. When I used >>>>> Spec debugger I thought "Oh, this is not so hard in fact". And I lose >>>>> the feeling with GTDebugger. And the debugger is one of the main source >>>>> of interest for newbies. >>>>> >>>>> Maybe we could have a button on the spec Debugger "Switch to GTDebugger"? >>>>> >>>> >>>> >>> >> >

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Tudor Girba

You get it in the Moose image until it gets integrated :). Doru > On Jan 9, 2016, at 12:11 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > looks lovely > > Is there a way to add the new debugger to my existing image ? How I get the new debugger, I downloaded the latest image and is not in it, > > On Sat, Jan 9, 2016 at 12:02 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > again re-send because of exceed limits with the image (thatâs new?) > > with a small tweak, texts (AND icons :P): > > > <Screen Shot 2016-01-09 at 10.59.20.png> > > would that be aceptable for you? > > cheers! > Esteban >> On 09 Jan 2016, at 09:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> (re-send because I exceeded limit.) >> >> Hi, >> >> letâs think positive. >> the GTDebugger is a step forwardâ¦ it allow a lot of better interactions and of course, it needs some iterations to make it appealing to everybody. >> For instance, I took me 2â to tweak the debugger presentation and to get this: >> >> <Screen Shot 2016-01-09 at 09.29.59.png> >> >> (I changed all availableâ¦ is a trivial task) >> >> and like IMO feels a lot betterâ¦ and I think is a good compromise between the old and the new. >> Reasons to suggest this approach: >> >> - it keeps old approach who(I think) was good (I can see the stack, and the flow feels natural from top to down) >> - it preserves âthe importantâ (the code) as central. >> - it gives space for adding columns (like the bytecode). >> >> Nowâ¦ I can understand you want icons with text, and that can be hacked tooâ¦ >> >> Soâ¦ can we have an agreement? >> >> Esteban >> >> ps: btwâ¦ using GT with Fast Table we can also avoid those annoying paginated lists too >> >>> On 09 Jan 2016, at 08:53, stepharo <stepharo(a)free.fr> wrote: >>> >>> Thanks for your testimony. >>> >>> I'm not against GTDebugger per se. I believe that we should have better tools >>> but we should take time for building better tools (even if this is two years that moosers use or not this new debugger). >>> I would appreciate a process where users can give real feedback and we can simplify/shape our tools nicely. >>> >>> Now for the mooc I will not present GTDebugger. So students will not use Pharo 50 >>> >>> Stef >>> >>>> Le 08/01/2016 21:22, stepharo a Ã©crit : >>>>> I'm sorry but this debugger should not be the default one. >>>>> MONDAY we are filming our mooc and we have to explain the debugger and >>>>> personally I do not see the gain: >>>>> - It looks a lot more complex to me and I do not want to have to >>>>> redo all the screenshots >>>>> of our lecture. >>>>> - Just that I have to learn the meaning of small icons. >>>>> - Why do we need a special pane for the evaluator >>>>> - Why there is a type column. >>>>> - Sorry but I'm not convinced about the moldable aspect behind the >>>>> story (no need to argue I know it) >>>>> >>>>> I would like to avoid to be forced to use not the latest version of >>>>> Pharo for the mooc. >>>>> >>>>> Such changes are arriving far too late in the release. We do not change >>>>> the debugger itself the day of code freeze. >>>>> >>>>> We decided that the GTDebugger can be included but to me it never meant >>>>> that it should be the default one. >>>>> I think that experts can choose the debugger they want. The newbies don't. >>>>> >>>>> Stef >>>>> >>>>> >>>> IMO the old debugger is way more intuitive. >>>> When I used the debugger of Eclipse for java I was lost. When I used >>>> Spec debugger I thought "Oh, this is not so hard in fact". And I lose >>>> the feeling with GTDebugger. And the debugger is one of the main source >>>> of interest for newbies. >>>> >>>> Maybe we could have a button on the spec Debugger "Switch to GTDebugger"? >>>> >>> >>> >> -- www.tudorgirba.com www.feenk.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

Jan. 9, 2016

Re: [Pharo-dev] About LayoutFrame>>fractions:offsets:

by Tudor Girba

Hi, This issue is still pending: https://pharo.fogbugz.com/f/cases/7077/LayoutFrame-refactoring Let us fix the Glamour issues and then we can deprecate it. Cheers, Doru > On Jan 9, 2016, at 11:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Stef, > > could you deprecate the use of fractions:offsets: ? It's a nice way of shooting oneself in the foot. > > Create a LayoutFrame taking all space: > > LayoutFrame fractions: (0@0 corner: 1@1) > > right? > > Create a layout frame taking all space with an inset of three, so an offset of +3 left and above, and -3 right and bottom: > > LayoutFrame fractions: (0@0 corner: 1@1) offsets: (3@3 extent: -3@ -3) > > Fail! > > See what I mean? You have to forbid the use of a rectangle for offsets! > > (Note: I think the easiest API is the one used by Spec and Morphic: Rectangle asLayoutFrame topOffset: / bottomOffset ...) > > Thierry > > Le 09/01/2016 09:56, stepharo a Ã©crit : >> Here is the new class comments I'm trying to write. >> I hope that it will help people to understand the circumstances under >> which they should use fractions:offset: creation API. >> >> >> >> I define a transformation frame relative to some rectangle. I'm basic >> data structure used for graphics. >> I represent two groups of distances: >> - The fractional distance (between 0 and 1) to place the morph in its >> owner's bounds >> - Fixed pixel offset to apply after fractional positioning (e.g., "10 >> pixel right of the center of the owner") >> >> !! API usage >> It is important to understand that it is better to use the fine grained >> API using elementary distances (bottomFraction:, bottomOffset:, >> leftFraction: ....) than the ones (historical) using points and >> rectangles (fractions:offsets:) >> >> The reason is that the old API (fractions:offsets:) is only interesting >> if you already have a rectangle and points at hand. If you need to >> create new ones, then they are created for nothing because they will be >> destructured to extract their information to be feed into the layoutFrame. >> So please do not blindly copy and paste code! >> >> Example: >> Favor >> >> (LayoutFrame identity >> leftFraction: 0; >> yourself); >> >> (LayoutFrame identity >> leftFraction: 0.5; >> rightFraction: 0.95; >> >> (LayoutFrame identity >> topOffset: topHeight; >> bottomFraction: 0; >> bottomOffset: self buttonsBarHeight; >> leftOffset: -1; >> rightOffset: 1) >> over >> >> (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) >> >> because you are creating for nothing a new rectangle and some points. >> >> >> >> !! Implementation >> >> Instance variables: >> The fractional distance (between 0 and 1) to place the morph in its >> owner's bounds is represented by the following instance variables: >> leftFraction >> topFraction >> rightFraction >> bottomFraction <Float> >> >> >> Fixed pixel offset to apply after fractional positioning (e.g., "10 >> pixel right of the center of the owner") is represented by the >> following instance variables: >> leftOffset >> topOffset >> rightOffset >> bottomOffset <Integer> >> >> > > -- www.tudorgirba.com www.feenk.com "The coherence of a trip is given by the clearness of the goal."

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Tudor Girba

Hi, Thanks! Could you publish the code and then we can iterate over it? Cheers, Doru > On Jan 9, 2016, at 12:02 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > you have to confess that with text and icons looks a lot better than the old one :P > >> On 09 Jan 2016, at 11:01, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> again re-send because of exceed limits with the image (thatâs new?) >> >> with a small tweak, texts (AND icons :P): >> >> >> <Screen Shot 2016-01-09 at 10.59.20.png> >> >> would that be aceptable for you? >> >> cheers! >> Esteban >> >>> On 09 Jan 2016, at 09:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> (re-send because I exceeded limit.) >>> >>> Hi, >>> >>> letâs think positive. >>> the GTDebugger is a step forwardâ¦ it allow a lot of better interactions and of course, it needs some iterations to make it appealing to everybody. >>> For instance, I took me 2â to tweak the debugger presentation and to get this: >>> >>> <Screen Shot 2016-01-09 at 09.29.59.png> >>> >>> (I changed all availableâ¦ is a trivial task) >>> >>> and like IMO feels a lot betterâ¦ and I think is a good compromise between the old and the new. >>> Reasons to suggest this approach: >>> >>> - it keeps old approach who(I think) was good (I can see the stack, and the flow feels natural from top to down) >>> - it preserves âthe importantâ (the code) as central. >>> - it gives space for adding columns (like the bytecode). >>> >>> Nowâ¦ I can understand you want icons with text, and that can be hacked tooâ¦ >>> >>> Soâ¦ can we have an agreement? >>> >>> Esteban >>> >>> ps: btwâ¦ using GT with Fast Table we can also avoid those annoying paginated lists too >>> >>>> On 09 Jan 2016, at 08:53, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> Thanks for your testimony. >>>> >>>> I'm not against GTDebugger per se. I believe that we should have better tools >>>> but we should take time for building better tools (even if this is two years that moosers use or not this new debugger). >>>> I would appreciate a process where users can give real feedback and we can simplify/shape our tools nicely. >>>> >>>> Now for the mooc I will not present GTDebugger. So students will not use Pharo 50 >>>> >>>> Stef >>>> >>>>> Le 08/01/2016 21:22, stepharo a Ã©crit : >>>>>> I'm sorry but this debugger should not be the default one. >>>>>> MONDAY we are filming our mooc and we have to explain the debugger and >>>>>> personally I do not see the gain: >>>>>> - It looks a lot more complex to me and I do not want to have to >>>>>> redo all the screenshots >>>>>> of our lecture. >>>>>> - Just that I have to learn the meaning of small icons. >>>>>> - Why do we need a special pane for the evaluator >>>>>> - Why there is a type column. >>>>>> - Sorry but I'm not convinced about the moldable aspect behind the >>>>>> story (no need to argue I know it) >>>>>> >>>>>> I would like to avoid to be forced to use not the latest version of >>>>>> Pharo for the mooc. >>>>>> >>>>>> Such changes are arriving far too late in the release. We do not change >>>>>> the debugger itself the day of code freeze. >>>>>> >>>>>> We decided that the GTDebugger can be included but to me it never meant >>>>>> that it should be the default one. >>>>>> I think that experts can choose the debugger they want. The newbies don't. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>> IMO the old debugger is way more intuitive. >>>>> When I used the debugger of Eclipse for java I was lost. When I used >>>>> Spec debugger I thought "Oh, this is not so hard in fact". And I lose >>>>> the feeling with GTDebugger. And the debugger is one of the main source >>>>> of interest for newbies. >>>>> >>>>> Maybe we could have a button on the spec Debugger "Switch to GTDebugger"? >>>>> >>>> >>>> >>> >> > -- www.tudorgirba.com www.feenk.com "Speaking louder won't make the point worthier."

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Dimitris Chloupis

looks lovely Is there a way to add the new debugger to my existing image ? How I get the new debugger, I downloaded the latest image and is not in it, On Sat, Jan 9, 2016 at 12:02 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > again re-send because of exceed limits with the image (thatâs new?) > > with a small tweak, texts (AND icons :P): > > > [image: Screen Shot 2016-01-09 at 10.59.20.png] > > would that be aceptable for you? > > cheers! > Esteban > > On 09 Jan 2016, at 09:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > (re-send because I exceeded limit.) > > Hi, > > letâs think positive. > the GTDebugger is a step forwardâ¦ it allow a lot of better interactions > and of course, it needs some iterations to make it appealing to everybody. > For instance, I took me 2â to tweak the debugger presentation and to get > this: > > <Screen Shot 2016-01-09 at 09.29.59.png> > > (I changed all availableâ¦ is a trivial task) > > and like IMO feels a lot betterâ¦ and I think is a good compromise between > the old and the new. > Reasons to suggest this approach: > > - it keeps old approach who(I think) was good (I can see the stack, and > the flow feels natural from top to down) > - it preserves âthe importantâ (the code) as central. > - it gives space for adding columns (like the bytecode). > > Nowâ¦ I can understand you want icons with text, and that can be hacked > tooâ¦ > > Soâ¦ can we have an agreement? > > Esteban > > > ps: btwâ¦ using GT with Fast Table we can also avoid those annoying > paginated lists too > > On 09 Jan 2016, at 08:53, stepharo <stepharo(a)free.fr> wrote: > > Thanks for your testimony. > > I'm not against GTDebugger per se. I believe that we should have better > tools > but we should take time for building better tools (even if this is two > years that moosers use or not this new debugger). > I would appreciate a process where users can give real feedback and we can > simplify/shape our tools nicely. > > Now for the mooc I will not present GTDebugger. So students will not use > Pharo 50 > > Stef > > Le 08/01/2016 21:22, stepharo a Ã©crit : > > I'm sorry but this debugger should not be the default one. > MONDAY we are filming our mooc and we have to explain the debugger and > personally I do not see the gain: > - It looks a lot more complex to me and I do not want to have to > redo all the screenshots > of our lecture. > - Just that I have to learn the meaning of small icons. > - Why do we need a special pane for the evaluator > - Why there is a type column. > - Sorry but I'm not convinced about the moldable aspect behind the > story (no need to argue I know it) > > I would like to avoid to be forced to use not the latest version of > Pharo for the mooc. > > Such changes are arriving far too late in the release. We do not change > the debugger itself the day of code freeze. > > We decided that the GTDebugger can be included but to me it never meant > that it should be the default one. > I think that experts can choose the debugger they want. The newbies don't. > > Stef > > > IMO the old debugger is way more intuitive. > When I used the debugger of Eclipse for java I was lost. When I used > Spec debugger I thought "Oh, this is not so hard in fact". And I lose > the feeling with GTDebugger. And the debugger is one of the main source > of interest for newbies. > > Maybe we could have a button on the spec Debugger "Switch to GTDebugger"? > > > > >

Jan. 9, 2016

Re: [Pharo-dev] need help improving layoutFrame =

by Tudor Girba

Thanks! Doru > On Jan 9, 2016, at 11:37 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 09-01-16 10:06, stepharo wrote: >> (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) = LayoutFrame identity >> should be true and it is not. >> I do not have the time to fix it now. >> >> Stef >> >> > Name: SLICE-Issue-17363-LayoutFrame-fractions-0--0-corner-1--1--LayoutFrame-identity-should-be-true-and-it-is-not-StephanEggermont.1 > Author: StephanEggermont > Time: 9 January 2016, 10:36:18.036246 am > UUID: 0a7119da-7ed6-4bf2-8581-7c02351dd2de > Ancestors: > Dependencies: Morphic-Base-StephanEggermont.525, Morphic-Tests-StephanEggermont.7 > > = & hash to avoid comparing with == > > -- www.tudorgirba.com www.feenk.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

Jan. 9, 2016

Re: [Pharo-dev] Fixed Glamour wrong users of LayoutFrame fractions: (0@0 corner: 1@1) fixes

by Tudor Girba

Hi, > On Jan 9, 2016, at 11:17 AM, stepharo <stepharo(a)free.fr> wrote: > > Hi > > I commited Glamour fixes for > > LayoutFrame fractions: (0@0 corner: 1@1)) > -> > LayoutFrame identity Thanks! > It is faster, produces less garbage and easier to read. > > Now it would be good that Glamourers do the same cleans that I did with Igor on complete Pharo. > Check all the uses of fractions: and fractions:offsets: and only use those if you do not create > by yourself a rectangle. Yes. This is on the to do list. I missed this one beforehand. > In addition using rectangles for passing four digits is doomed to create wrong and incorrect rectangles > so if you still need to use rectangle better use Margin. > > A margin is a holder of 1,2 or 4 digits and it is not a rectangle. > > Tell me if you need more precision. Makes sense. Cheers, Doru > Stef > -- www.tudorgirba.com www.feenk.com "To utilize feedback, you first have to acquire it."

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Esteban Lorenzano

you have to confess that with text and icons looks a lot better than the old one :P > On 09 Jan 2016, at 11:01, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > again re-send because of exceed limits with the image (thatâs new?) > > with a small tweak, texts (AND icons :P): > > > <Screen Shot 2016-01-09 at 10.59.20.png> > > would that be aceptable for you? > > cheers! > Esteban > >> On 09 Jan 2016, at 09:43, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> (re-send because I exceeded limit.) >> >> Hi, >> >> letâs think positive. >> the GTDebugger is a step forwardâ¦ it allow a lot of better interactions and of course, it needs some iterations to make it appealing to everybody. >> For instance, I took me 2â to tweak the debugger presentation and to get this: >> >> <Screen Shot 2016-01-09 at 09.29.59.png> >> >> (I changed all availableâ¦ is a trivial task) >> >> and like IMO feels a lot betterâ¦ and I think is a good compromise between the old and the new. >> Reasons to suggest this approach: >> >> - it keeps old approach who(I think) was good (I can see the stack, and the flow feels natural from top to down) >> - it preserves âthe importantâ (the code) as central. >> - it gives space for adding columns (like the bytecode). >> >> Nowâ¦ I can understand you want icons with text, and that can be hacked tooâ¦ >> >> Soâ¦ can we have an agreement? >> >> Esteban >> >> ps: btwâ¦ using GT with Fast Table we can also avoid those annoying paginated lists too >> >>> On 09 Jan 2016, at 08:53, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>> >>> Thanks for your testimony. >>> >>> I'm not against GTDebugger per se. I believe that we should have better tools >>> but we should take time for building better tools (even if this is two years that moosers use or not this new debugger). >>> I would appreciate a process where users can give real feedback and we can simplify/shape our tools nicely. >>> >>> Now for the mooc I will not present GTDebugger. So students will not use Pharo 50 >>> >>> Stef >>> >>>> Le 08/01/2016 21:22, stepharo a Ã©crit : >>>>> I'm sorry but this debugger should not be the default one. >>>>> MONDAY we are filming our mooc and we have to explain the debugger and >>>>> personally I do not see the gain: >>>>> - It looks a lot more complex to me and I do not want to have to >>>>> redo all the screenshots >>>>> of our lecture. >>>>> - Just that I have to learn the meaning of small icons. >>>>> - Why do we need a special pane for the evaluator >>>>> - Why there is a type column. >>>>> - Sorry but I'm not convinced about the moldable aspect behind the >>>>> story (no need to argue I know it) >>>>> >>>>> I would like to avoid to be forced to use not the latest version of >>>>> Pharo for the mooc. >>>>> >>>>> Such changes are arriving far too late in the release. We do not change >>>>> the debugger itself the day of code freeze. >>>>> >>>>> We decided that the GTDebugger can be included but to me it never meant >>>>> that it should be the default one. >>>>> I think that experts can choose the debugger they want. The newbies don't. >>>>> >>>>> Stef >>>>> >>>>> >>>> IMO the old debugger is way more intuitive. >>>> When I used the debugger of Eclipse for java I was lost. When I used >>>> Spec debugger I thought "Oh, this is not so hard in fact". And I lose >>>> the feeling with GTDebugger. And the debugger is one of the main source >>>> of interest for newbies. >>>> >>>> Maybe we could have a button on the spec Debugger "Switch to GTDebugger"? >>>> >>> >>> >> >

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Esteban Lorenzano

again re-send because of exceed limits with the image (thatâs new?) with a small tweak, texts (AND icons :P): would that be aceptable for you? cheers! Esteban > On 09 Jan 2016, at 09:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > (re-send because I exceeded limit.) > > Hi, > > letâs think positive. > the GTDebugger is a step forwardâ¦ it allow a lot of better interactions and of course, it needs some iterations to make it appealing to everybody. > For instance, I took me 2â to tweak the debugger presentation and to get this: > > <Screen Shot 2016-01-09 at 09.29.59.png> > > (I changed all availableâ¦ is a trivial task) > > and like IMO feels a lot betterâ¦ and I think is a good compromise between the old and the new. > Reasons to suggest this approach: > > - it keeps old approach who(I think) was good (I can see the stack, and the flow feels natural from top to down) > - it preserves âthe importantâ (the code) as central. > - it gives space for adding columns (like the bytecode). > > Nowâ¦ I can understand you want icons with text, and that can be hacked tooâ¦ > > Soâ¦ can we have an agreement? > > Esteban > > ps: btwâ¦ using GT with Fast Table we can also avoid those annoying paginated lists too > >> On 09 Jan 2016, at 08:53, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >> >> Thanks for your testimony. >> >> I'm not against GTDebugger per se. I believe that we should have better tools >> but we should take time for building better tools (even if this is two years that moosers use or not this new debugger). >> I would appreciate a process where users can give real feedback and we can simplify/shape our tools nicely. >> >> Now for the mooc I will not present GTDebugger. So students will not use Pharo 50 >> >> Stef >> >>> Le 08/01/2016 21:22, stepharo a Ã©crit : >>>> I'm sorry but this debugger should not be the default one. >>>> MONDAY we are filming our mooc and we have to explain the debugger and >>>> personally I do not see the gain: >>>> - It looks a lot more complex to me and I do not want to have to >>>> redo all the screenshots >>>> of our lecture. >>>> - Just that I have to learn the meaning of small icons. >>>> - Why do we need a special pane for the evaluator >>>> - Why there is a type column. >>>> - Sorry but I'm not convinced about the moldable aspect behind the >>>> story (no need to argue I know it) >>>> >>>> I would like to avoid to be forced to use not the latest version of >>>> Pharo for the mooc. >>>> >>>> Such changes are arriving far too late in the release. We do not change >>>> the debugger itself the day of code freeze. >>>> >>>> We decided that the GTDebugger can be included but to me it never meant >>>> that it should be the default one. >>>> I think that experts can choose the debugger they want. The newbies don't. >>>> >>>> Stef >>>> >>>> >>> IMO the old debugger is way more intuitive. >>> When I used the debugger of Eclipse for java I was lost. When I used >>> Spec debugger I thought "Oh, this is not so hard in fact". And I lose >>> the feeling with GTDebugger. And the debugger is one of the main source >>> of interest for newbies. >>> >>> Maybe we could have a button on the spec Debugger "Switch to GTDebugger"? >>> >> >> >

Jan. 9, 2016

Re: [Pharo-dev] About LayoutFrame>>fractions:offsets:

by Thierry Goubier

Stef, could you deprecate the use of fractions:offsets: ? It's a nice way of shooting oneself in the foot. Create a LayoutFrame taking all space: LayoutFrame fractions: (0@0 corner: 1@1) right? Create a layout frame taking all space with an inset of three, so an offset of +3 left and above, and -3 right and bottom: LayoutFrame fractions: (0@0 corner: 1@1) offsets: (3@3 extent: -3@ -3) Fail! See what I mean? You have to forbid the use of a rectangle for offsets! (Note: I think the easiest API is the one used by Spec and Morphic: Rectangle asLayoutFrame topOffset: / bottomOffset ...) Thierry Le 09/01/2016 09:56, stepharo a Ã©crit : > Here is the new class comments I'm trying to write. > I hope that it will help people to understand the circumstances under > which they should use fractions:offset: creation API. > > > > I define a transformation frame relative to some rectangle. I'm basic > data structure used for graphics. > I represent two groups of distances: > - The fractional distance (between 0 and 1) to place the morph in its > owner's bounds > - Fixed pixel offset to apply after fractional positioning (e.g., "10 > pixel right of the center of the owner") > > !! API usage > It is important to understand that it is better to use the fine grained > API using elementary distances (bottomFraction:, bottomOffset:, > leftFraction: ....) than the ones (historical) using points and > rectangles (fractions:offsets:) > > The reason is that the old API (fractions:offsets:) is only interesting > if you already have a rectangle and points at hand. If you need to > create new ones, then they are created for nothing because they will be > destructured to extract their information to be feed into the layoutFrame. > So please do not blindly copy and paste code! > > Example: > Favor > > (LayoutFrame identity > leftFraction: 0; > yourself); > > (LayoutFrame identity > leftFraction: 0.5; > rightFraction: 0.95; > > (LayoutFrame identity > topOffset: topHeight; > bottomFraction: 0; > bottomOffset: self buttonsBarHeight; > leftOffset: -1; > rightOffset: 1) > over > > (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) > > because you are creating for nothing a new rectangle and some points. > > > > !! Implementation > > Instance variables: > The fractional distance (between 0 and 1) to place the morph in its > owner's bounds is represented by the following instance variables: > leftFraction > topFraction > rightFraction > bottomFraction <Float> > > > Fixed pixel offset to apply after fractional positioning (e.g., "10 > pixel right of the center of the owner") is represented by the > following instance variables: > leftOffset > topOffset > rightOffset > bottomOffset <Integer> > >

Jan. 9, 2016