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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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."
