On Sun, Jun 5, 2016 at 1:17 AM, Tudor Girba <tu...@tudorgirba.com> wrote: > Hi, > >> On Jun 4, 2016, at 7:09 PM, Ben Coman <b...@openinworld.com> wrote: >> >> >> >> On Sat, Jun 4, 2016 at 11:28 PM, Gabriel Cotelli <g.cote...@gmail.com> wrote: >> Hi, >> I undestand and really liked the idea of a moldable debugger and it's true >> that the button actions act over the stack, however the decision on what >> action to use is taken not looking to the stack pane (normally I've decided >> what to do looking on the source pane). In this context, the buttons are far >> away where the attention usually is (the code pane). IMHO for the user >> experience point of view I think is better to have the actions below the >> stack list and above the stack pane to let the user do not diverge his >> attention. I'm proposing not dettaching the action buttons for the stack >> pane, just changing the location (and also moving and inverting the >> direction of the tab label to not waste space). >> >> Interesting idea. Only the [Stack] tab is a bit lonely over there on the >> right. Perhaps the tab could still be on the left, with the buttons left >> justified against it? >> >> btw, are there any use cases for multiple stack tabs? > > Do you mean if there are cases for seeing the stack in different ways or do > you mean something else?
I meant, is the [Stack] tab really required? Will there ever be a second tab? Could the buttons be the sole occupant of that row - beneath the stack pane? Actually do like the idea of having a bottom hanging [Stack] tab directly opposing the [Source] tab. Could the buttons be left justified against that, and then if a second tab ever comes along, slide the buttons to the right a little? cheers -ben > > Cheers, > Doru > >> cheers -ben >> >> >> Maybe something like this (sorry no photoshop here :) ): >> >> We need to figure it out a way to improve this situation. >> >> Regards, >> Gabriel >> >> On Sat, Jun 4, 2016 at 3:45 AM, Tudor Girba <tu...@tudorgirba.com> wrote: >> 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> 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 >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Every thing should have the right to be different." >> >> >> >> >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Reasonable is what we are accustomed with." > >
