Hi, > On Jan 10, 2016, at 11:58 AM, Nicolai Hess <[email protected]> wrote: > > > 2016-01-09 23:10 GMT+01:00 Tudor Girba <[email protected]>: > Hi, > >> On Jan 9, 2016, at 3:29 PM, Christophe Demarey <[email protected]> >> wrote: >> >> Not yet tested but looks good. > > Thanks. > >> I just noticed it misses the "run to here" action. > > It does not miss it. It is in the context menu of the code (this is where it > logically belongs). > > Argh, trying to change a "well known user interface" (SpecDebugger) and > arguing about > why the new interface (GTDebugger) is " more logical" is always risky :)
Tell me about risky :). But, I was not arguing. I just said why we chose to add it where it is. However, in Glamour the rule is that we have global actions as buttons, and contextual ones as contextual menus. This is used consistently in the inspector and playground, and it can be used as consistently to the debugger as well :). > Even so we (smalltalkers) have the best software environment (Pharo) we are > bound to our owns > habits. > And it is a question of "discoverability". If you only see 5 debugger action > icons, you > may not know that there is another one (hidden) inthe context menu. I am convinced it is the habits. Just consider this. The contextual menus of the spec debugger have several dozen actions. Also, the previous inspector had no visual actions. You see, if we would have such a strong set of design principles, we would have seen it. One goal with GT is to provide a small set of conventions that you can learn. They are clearly not the best, but once they are adopted in every tool, it should be better than the current state of affairs. And then we can iterate, but my stand is that we first have to reach a uniform enough situation. Anyway, I do not want to have a religious debate. But, I also think that if we impose the condition that new things should be exactly like the old ones we have a high chance of staying the same forever :). Cheers, Doru > > > <Untitled.png> > > > Doru > > > > >> 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 <[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 > > "Quality cannot be an afterthought." > > -- www.tudorgirba.com www.feenk.com "To utilize feedback, you first have to acquire it."
