Not yet tested but looks good. I just noticed it misses the "run to here" action.
Le 9 janv. 2016 à 11:01, Esteban Lorenzano a écrit : > 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 <esteba...@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 <steph...@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"? >>>> >>> >>> >> >
smime.p7s
Description: S/MIME cryptographic signature