Hi Doru, I think most people understand the great value of moldable tools. Maybe not all will use moldability but is a big plus to have. So, keep pushing!
I just think we miss time to make the GT Debugger dealt view as productive as the spec debugger. There are users that do not use shortcuts (at least for debugger) and in this case, the over use of the mouse to reach step buttons is killing the productivity. To me, this issue could be addressed easily but could take time to implement in a generic / moldable way. I agree with Gabriel that buttons act on the stack (in fact also, on the source code pane that represents the AST) but what we mainly look at is the source code. Maybe buttons could be moved to the source code pane? I also have another suggestion: I very often have a debugger window with a lot of variables not visible by default : only 4 visible, need to scroll. Couldn’t we split the variable pane in 2 part to display more variables? To open the inspector, you could either use the second column or open a third one. WDYT? Cheers, Christophe > Le 4 juin 2016 à 08:45, Tudor Girba <tu...@tudorgirba.com> a écrit : > > Hi Sabine (and others that asked this question), > > Thanks for the feedback. Sorry for the delayed reply, but I am traveling > these days and I have limited online time. Also, this email took some time to > write (I started it about a week ago). > > I will answer the buttons issue. The reason they are in a different place > than where they used to be is related to new constraints that come with the > new debugger. While the default interface looks like a regular debugger, the > main feature of the GTDebugger is that it can be customized to match a > specific domain or library. > > Let me provide an example of a scenario of debugging PetitParser: > > PPArithmeticParser parse: '1+2*3^(34-2)’ > > The default debugger looks like this: > > <debug-pp-default.png> > > But, because we have PetitParser code on the stack, we can switch to a custom > debugger: > > <debug-pp-dedicated-source.png> > > This one also features the input stream next to the code. Also, note that the > stack received 3 new button actions. But, this is not all. Next to the > source, there are other tabs, and we can switch to one of those: > > <debug-pp-dedicated-visualization.png> > > This one shows the source as well, but in a graphical form. > > So, if we step back and talk about the buttons, you will see that if we would > have put the buttons on the source tabs, you have had no way to advance in > this state. We could have also duplicated behavior and put the buttons on the > new presentation as well, but the space is much smaller and since we now have > large buttons instead of only icons we needed to deal with that as well. We > encountered similar situations in other debuggers (not all, though). > > But, from a more point of view, the actions act on the stack. So, if we take > an object-oriented approach for designing the UI, it makes sense to place > those actions next to the context they act on. All these reasons made us > choose to put them next to the stack and not next to the source. > > We certainly understand that this is a departure from the classic debugger > and perhaps this is not the best way of doing things, but that was the > rationale we went through. I would be happy to hear other suggestions, but > please understand that we need to take into account the full spectrum of > constraints when choosing solutions. > > In any case, the idea of this debugger is that you can change it in the way > you want and customize it specifically for your needs. We still need to > document how to do that, but if someone wants to start creating a custom > debugger we could use the experience to drive the documentation. > > Does this explain the situation? > > Cheers, > Doru > > >> On May 25, 2016, at 9:43 PM, Sabine Manaa <manaa.sab...@gmail.com >> <mailto:manaa.sab...@gmail.com>> wrote: >> >> Hi, >> >> today I moved to Pharo5. It is great to get feedback and solutions for >> problems so quickly. It is a pleasure to work with Pharo and to have the >> community. I am grateful for having this. >> >> I have one comment. I don't want to complain, I can use it but I was >> wondering about the new position and size of the debugger buttons. >> >> There is a longer distance now from code text pane to the buttons - I see >> this as disadvantage to earlier versions of Pharo from the user experience. >> The buttons are a lot of smaller - same disadvantage - both if you use the >> mouse. >> >> Ok, after seeing that, I thought "Sabine, you should use keyboard shortcuts >> here, too" (I use much of them but interesting - til now not in the >> debugger). >> >> Then I saw the shortcuts for >> Proceed cmd+r >> Restart cmd-shift-a >> Into cmd-e >> over cmd-shift-o >> through cmd-shift-t >> >> especially into, over and through have so different key combinations, two >> with shift, one without shift. When I debug, I often use for example >> into-into-over-over-over-throuhg-through--into-into etc...and with the >> combinations cmd-e and cmd-shit-e, it is more "finger-work". It would be >> better to have all those shortcuts with or all shortcuts without shift. And >> the letters not so far away at the keyboard (e-o-t) >> >> This is only my opinion and my first impression after one day with Pharo5. I >> am sure, after a few days, I forgot that this was uncomfortable because I >> have the shortcuts coming automatically into my fingers. >> >> Regards >> Sabine >> >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390.html >> <http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390.html> >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com >> <http://nabble.com/>. >> > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com > > "Every thing should have the right to be different." > > > >
