One comment to new Pharo5 debugger

On Sat, Jun 4, 2016 at 11:28 PM, Gabriel Cotelli <[hidden email]> 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?

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 <[hidden email]> 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:

But, because we have PetitParser code on the stack, we can switch to a custom debugger:

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:

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 <[hidden email]> 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."