Hi, > On Jan 9, 2016, at 10:43 AM, Esteban Lorenzano <[email protected]> wrote: > > (re-send because I exceeded limit.) > > Hi, > > let’s think positive.
Thanks :) > 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: Exactly :) We should also remember that it uses GTInspector which should decrease the cost of maintenance for those parts. > <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). Yes, we played with this last night and we can adopt it for now. > 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 Yes. I opened an issue for this: https://pharo.fogbugz.com/f/cases/17362/GTDebugger-should-use-FastTable-to-show-the-stack Cheers, Doru >> 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 "Don't give to get. Just give."
