Smalltalk › Pharo › Pharo Smalltalk Users

One comment to new Pharo5 debugger

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

26 messages Options

Sabine Manaa

One comment to new Pharo5 debugger

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

Peter Uhnak

Re: One comment to new Pharo5 debugger

Hi,

yes, this question was raised before, but there are some disagreements over how it should be, so it may take some time http://forum.world.st/GTDebugger-shortcuts-usability-td4890316.html

You can also use a startup script to reassign them, such as this one. https://github.com/peteruhnak/pharo-scripts/blob/master/config/5.0/uniformDebugger.st

But a startup script is a temporary solution.

On Wed, 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.

demarey

Re: One comment to new Pharo5 debugger

Hi Sabine,

this point was also « discussed » (no answer) here: http://forum.world.st/gtdebugger-debug-actions-buttons-td4874316.html

Yes, the new buttons are counter-productive and there is even no setting to have them usable …

You can still with to the SpecDebugger through settings

Le 25 mai 2016 à 22:49, Peter Uhnák <[hidden email]> a écrit :

Hi,

yes, this question was raised before, but there are some disagreements over how it should be, so it may take some time http://forum.world.st/GTDebugger-shortcuts-usability-td4890316.html

You can also use a startup script to reassign them, such as this one. https://github.com/peteruhnak/pharo-scripts/blob/master/config/5.0/uniformDebugger.st
But a startup script is a temporary solution.

On Wed, 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.

Sabine Manaa

Re: One comment to new Pharo5 debugger

In reply to this post by Peter Uhnak

Hi Peter,

Thanks. I geht all the nabble mails and try to read at least the subject but I missed this one.

I create my own shortcuts as first solution.

Regards

Sabine

Am Mittwoch, 25. Mai 2016 schrieb Peter Uhnák [via Smalltalk] :

Hi,

yes, this question was raised before, but there are some disagreements over how it should be, so it may take some time http://forum.world.st/GTDebugger-shortcuts-usability-td4890316.html

You can also use a startup script to reassign them, such as this one. https://github.com/peteruhnak/pharo-scripts/blob/master/config/5.0/uniformDebugger.st
But a startup script is a temporary solution.

On Wed, 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.

If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390p4897397.html

To start a new topic under Pharo Smalltalk Users, email <a href="javascript:_e(%7B%7D,'cvml','ml-node%2Bs1294792n1310670h65@n4.nabble.com');" target="_blank">ml-node+s1294792n1310670h65@...
To unsubscribe from Pharo Smalltalk Users, click here.
NAML

Denis Kudriashov

Re: One comment to new Pharo5 debugger

In reply to this post by demarey

Hi.

Maybe me should give chance to standard Moose debugger view? (where stack pane on the left)

2016-05-26 9:37 GMT+02:00 Christophe Demarey <[hidden email]>:

Hi Sabine,

this point was also « discussed » (no answer) here: http://forum.world.st/gtdebugger-debug-actions-buttons-td4874316.html
Yes, the new buttons are counter-productive and there is even no setting to have them usable …
You can still with to the SpecDebugger through settings

Le 25 mai 2016 à 22:49, Peter Uhnák <[hidden email]> a écrit :

Hi,

yes, this question was raised before, but there are some disagreements over how it should be, so it may take some time http://forum.world.st/GTDebugger-shortcuts-usability-td4890316.html

You can also use a startup script to reassign them, such as this one. https://github.com/peteruhnak/pharo-scripts/blob/master/config/5.0/uniformDebugger.st
But a startup script is a temporary solution.

On Wed, 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.

stepharo

Re: One comment to new Pharo5 debugger

In reply to this post by Sabine Manaa

Thanks Sabine!

This is important that you report such problems.

Several people including me already reported this problem that we will
have to address for real.

Stef

Le 25/5/16 à 21:43, Sabine Manaa a écrit :

> 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.
>
>

jfabry

Re: One comment to new Pharo5 debugger

In reply to this post by demarey

Yes, and there was also some discussion on the Pharo-users mailing list. Apparently the same comments more or less ...

I give a big +1 on moving the buttons down, so that they are between the stack and the code pane. I still don’t understand why they need to be so far away from the code pane, it makes much more sense above the code pane + we save on mouse movements.

Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org .

Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

On May 26, 2016, at 04:37, Christophe Demarey <[hidden email]> wrote:

Hi Sabine,

this point was also « discussed » (no answer) here: http://forum.world.st/gtdebugger-debug-actions-buttons-td4874316.html
Yes, the new buttons are counter-productive and there is even no setting to have them usable …
You can still with to the SpecDebugger through settings

Le 25 mai 2016 à 22:49, Peter Uhnák <[hidden email]> a écrit :

Hi,

yes, this question was raised before, but there are some disagreements over how it should be, so it may take some time http://forum.world.st/GTDebugger-shortcuts-usability-td4890316.html

You can also use a startup script to reassign them, such as this one. https://github.com/peteruhnak/pharo-scripts/blob/master/config/5.0/uniformDebugger.st
But a startup script is a temporary solution.

On Wed, 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.

EstebanLM

Re: One comment to new Pharo5 debugger

On 26 May 2016, at 14:49, Johan Fabry <[hidden email]> wrote:

Yes, and there was also some discussion on the Pharo-users mailing list. Apparently the same comments more or less ...

I give a big +1 on moving the buttons down, so that they are between the stack and the code pane. I still don’t understand why they need to be so far away from the code pane, it makes much more sense above the code pane + we save on mouse movements.

is because of the “moldable” nature of the debugger, since the code panel could be anything (like a custom browser, etc.), it is not certain that buttons can be there… only “constant” place is the top of the browser…

that does not means I do not agree it would be better closer to the code itself… but I will need to take a care look to that before proposing a possible change.

Esteban

--
Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org .

Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

On May 26, 2016, at 04:37, Christophe Demarey <[hidden email]> wrote:

Hi Sabine,

this point was also « discussed » (no answer) here: http://forum.world.st/gtdebugger-debug-actions-buttons-td4874316.html
Yes, the new buttons are counter-productive and there is even no setting to have them usable …
You can still with to the SpecDebugger through settings

Le 25 mai 2016 à 22:49, Peter Uhnák <[hidden email]> a écrit :

Hi,

yes, this question was raised before, but there are some disagreements over how it should be, so it may take some time http://forum.world.st/GTDebugger-shortcuts-usability-td4890316.html

You can also use a startup script to reassign them, such as this one. https://github.com/peteruhnak/pharo-scripts/blob/master/config/5.0/uniformDebugger.st
But a startup script is a temporary solution.

On Wed, 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.

stepharo

Re: One comment to new Pharo5 debugger

In reply to this post by jfabry

Yes, and there was also some discussion on the Pharo-users mailing list. Apparently the same comments more or less ...

I give a big +1 on moving the buttons down, so that they are between the stack and the code pane. I still don’t understand why they need to be so far away from the code pane, it makes much more sense above the code pane + we save on mouse movements.

Because doru got trapped into his own view on "UI design".

Even apple does not respect its own design documents.

Stef

jfabry

Re: One comment to new Pharo5 debugger

I will just leave this here, so that people that prefer the buttons in their original place can get them back ...

I did some quick investigating, and it’s straightforward. Just change the implementation of GTGenericStackDebugger>>codeActionsPragmas to the following:

codeActionsPragmas

^ #( codeDebuggingAction stackDebuggingAction )

Et voila, the stack debugging action buttons now are also available just above the code pane!

For extra goodness, the following two-liner is now also going into my startup preferences, run-once code part:

GTGenericStackDebugger compile: 'codeActionsPragmas

^ #(stackDebuggingAction codeDebuggingAction)' classified: 'building actions'

Voila, I will never miss those buttons again :-)

On May 26, 2016, at 11:01, stepharo <[hidden email]> wrote:

Yes, and there was also some discussion on the Pharo-users mailing list. Apparently the same comments more or less ...

I give a big +1 on moving the buttons down, so that they are between the stack and the code pane. I still don’t understand why they need to be so far away from the code pane, it makes much more sense above the code pane + we save on mouse movements.

Because doru got trapped into his own view on "UI design".

Even apple does not respect its own design documents.

Stef

Sabine Manaa

Re: One comment to new Pharo5 debugger

Johan,

thank you, this works fine!

regards

Sabine

2016-05-27 2:33 GMT+02:00 jfabry [via Smalltalk] <[hidden email]>:

I will just leave this here, so that people that prefer the buttons in their original place can get them back ...

I did some quick investigating, and it’s straightforward. Just change the implementation of GTGenericStackDebugger>>codeActionsPragmas to the following:

codeActionsPragmas

^ #( codeDebuggingAction stackDebuggingAction )

Et voila, the stack debugging action buttons now are also available just above the code pane!

For extra goodness, the following two-liner is now also going into my startup preferences, run-once code part:

GTGenericStackDebugger compile: 'codeActionsPragmas
^ #(stackDebuggingAction codeDebuggingAction)' classified: 'building actions'

Voila, I will never miss those buttons again :-)

--
Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org .

Johan Fabry - http://pleiad.cl/~jfabry
PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

On May 26, 2016, at 11:01, stepharo <[hidden email]> wrote:

Yes, and there was also some discussion on the Pharo-users mailing list. Apparently the same comments more or less ...

I give a big +1 on moving the buttons down, so that they are between the stack and the code pane. I still don’t understand why they need to be so far away from the code pane, it makes much more sense above the code pane + we save on mouse movements.

Because doru got trapped into his own view on "UI design".

Even apple does not respect its own design documents.

Stef

If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390p4897659.html

To start a new topic under Pharo Smalltalk Users, email [hidden email]
To unsubscribe from Pharo Smalltalk Users, click here.
NAML

Denis Kudriashov

Re: One comment to new Pharo5 debugger

In reply to this post by jfabry

2016-05-27 2:08 GMT+02:00 Johan Fabry <[hidden email]>:

codeActionsPragmas

^ #( codeDebuggingAction stackDebuggingAction )

I am wondering. Why people from GT team not do this? I was think it not easy.

Anyway change following method to remove buttons from top pane:

"protocol: building actions"

stackDebuggingActionsPragmas

^ #( )

jfabry

Re: One comment to new Pharo5 debugger

I think the reason not to change, is not a difficulty in implementation but a design view that is different from yours and mine. And from Sabine’s. And from Stef’s. And maybe from other persons too …

Just to say that I think this should have been discussed more.

On May 27, 2016, at 05:39, Denis Kudriashov <[hidden email]> wrote:

I am wondering. Why people from GT team not do this? I was think it not easy.

Anyway change following method to remove buttons from top pane:

"protocol: building actions"
stackDebuggingActionsPragmas

^ #( )

Ben Coman

Re: One comment to new Pharo5 debugger

In reply to this post by EstebanLM

On Thu, May 26, 2016 at 9:59 PM, Esteban Lorenzano <[hidden email]> wrote:

>
> On 26 May 2016, at 14:49, Johan Fabry <[hidden email]> wrote:
>
> Yes, and there was also some discussion on the Pharo-users mailing list.
> Apparently the same comments more or less ...
>
> I give a big +1 on moving the buttons down, so that they are between the
> stack and the code pane. I still don’t understand why they need to be so far
> away from the code pane, it makes much more sense above the code pane + we
> save on mouse movements.
>
>
> is because of the “moldable” nature of the debugger, since the code panel
> could be anything (like a custom browser, etc.), it is not certain that
> buttons can be there… only “constant” place is the top of the browser…

I wonder about buttons down the left margin of the stack pane? With
modern wide aspect displays and even two inspector panes at the
bottom, I find I have a huge amount of white space to the right of the
stack pane, so there would be little impact on this stack info.
Perhaps a default wide margin to fit labels for newbies (though
Through could be Thru, and Proceed could be Run), but also be able to
shrink in width so that only the button icons are visible. What do
you think?

cheers -ben

> that does not means I do not agree it would be better closer to the code
> itself… but I will need to take a care look to that before proposing a
> possible change.
>
> Esteban
>
>
> --
> Does this mail seem too brief? Sorry for that, I don’t mean to be rude!
> Please see http://emailcharter.org .
>
> Johan Fabry - http://pleiad.cl/~jfabry
> PLEIAD and RyCh labs - Computer Science Department (DCC) - University of
> Chile
>
> On May 26, 2016, at 04:37, Christophe Demarey <[hidden email]>
> wrote:
>
> Hi Sabine,
>
> this point was also « discussed » (no answer) here:
> http://forum.world.st/gtdebugger-debug-actions-buttons-td4874316.html
> Yes, the new buttons are counter-productive and there is even no setting to
> have them usable …
> You can still with to the SpecDebugger through settings
>
>
> Le 25 mai 2016 à 22:49, Peter Uhnák <[hidden email]> a écrit :
>
> Hi,
>
> yes, this question was raised before, but there are some disagreements over
> how it should be, so it may take some time
> http://forum.world.st/GTDebugger-shortcuts-usability-td4890316.html
>
> You can also use a startup script to reassign them, such as this one.
> https://github.com/peteruhnak/pharo-scripts/blob/master/config/5.0/uniformDebugger.st
> But a startup script is a temporary solution.
>
> On Wed, 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.
>>
>
>
>
>

Tudor Girba-2

Re: One comment to new Pharo5 debugger

In reply to this post by Sabine Manaa

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."

Sabine Manaa

Re: One comment to new Pharo5 debugger

Hi Tudor,

thank you for the explanation, which explains the situation.

Speaking only for me: I never used custom debuggers, I always used the default debugger in different smalltalk IDEs and so, I am used to a kind of "standard". But as your signature points out "Every thing should have the right to be different." :-)

I can live with the given alternatives (create my now shortcuts and move the buttons).

I ask myself, how many people know, need and use specific debuggers. And in this context, which debugger should be the "default" debugger. Perhaps it is an important point for the first impression of new people coming to pharo (coming from other smalltalks) and people coming from other languages. If you come to a new IDE, I assume it will not be the first step to customize the debugger (at least not for me).

But, again - for me everything is fine as it is. I love working with pharo an I was very impressed by several new features of the new version. Eg. the new integrated code critics is an insanely great new feature (which is also not like this in other smalltalk IDEs!!).

Regards
Sabine

EstebanLM

Re: One comment to new Pharo5 debugger

Hi,

On 04 Jun 2016, at 12:18, Sabine Manaa <[hidden email]> wrote:

Hi Tudor,

thank you for the explanation, which explains the situation.

Speaking only for me: I never used custom debuggers, I always used the default debugger in different smalltalk IDEs and so,

one could say you never used custom debuggers because you never had the chance :)

I am used to a kind of "standard". But as your signature points out "Every thing should have the right to be different." :-)

I can live with the given alternatives (create my now shortcuts and move the buttons).

I ask myself, how many people know, need and use specific debuggers. And in this context, which debugger should be the "default" debugger. Perhaps it is an important point for the first impression of new people coming to pharo (coming from other smalltalks) and people coming from other languages. If you come to a new IDE, I assume it will not be the first step to customize the debugger (at least not for me).

But, again - for me everything is fine as it is. I love working with pharo an I was very impressed by several new features of the new version. Eg. the new integrated code critics is an insanely great new feature (which is also not like this in other smalltalk IDEs!!).

I’m sure we can find a solution that appeals everybody, we just need to reflect/experiment a bit more.

cheers!

Esteban

ps: I’m also think the highest impact for this version (the one who can more directly help users) is QA… and I’m very thankful yuri made such a tool. Next versions will start to feel the impact of reflectivity (breakpoints being just the first “smell” of what can be achieved there, but we are just starting to build the tools for benefit from it...

Regards
Sabine

View this message in context: Re: One comment to new Pharo5 debugger
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Tudor Girba-2

Re: One comment to new Pharo5 debugger

In reply to this post by Sabine Manaa

Hi,

> On Jun 4, 2016, at 12:18 PM, Sabine Manaa <[hidden email]> wrote:
>
> Hi Tudor,
>
> thank you for the explanation, which explains the situation.
>
> Speaking only for me: I never used custom debuggers, I always used the default debugger in different smalltalk IDEs and so, I am used to a kind of "standard”.

That is because they do not exist anywhere else at this point in time :).

> But as your signature points out "Every thing should have the right to be different." :-)

Indeed :)

> I can live with the given alternatives (create my now shortcuts and move the buttons).

Great. Please note that there is an open issue with externalizing shortcuts which we did not get to address until Pharo 5, but we will certainly address for Pharo 6.

> I ask myself, how many people know, need and use specific debuggers.

This is absolutely a legitimate question. I will open another thread to address it.

But, given that this is a new concept, it is very important for us to get your opinion on what works and what does not. We think there is value in the concept of moldability, but we are at the beginning and I am convinced we need more iteration to strike a better balance between extensibility and usability.

> And in this context, which debugger should be the "default" debugger. Perhaps it is an important point for the first impression of new people coming to pharo (coming from other smalltalks) and people coming from other languages. If you come to a new IDE, I assume it will not be the first step to customize the debugger (at least not for me).

Indeed, it will not be the first step. Just like it will not be the first step to extend the inspector. The main use case is for the framework builders to ship custom debuggers specific for their frameworks. See more in the other thread.

> But, again - for me everything is fine as it is. I love working with pharo an I was very impressed by several new features of the new version. Eg. the new integrated code critics is an insanely great new feature (which is also not like this in other smalltalk IDEs!!).

Indeed, this is a useful addition and we need to make more room for this our tools.

Cheers,
Doru

> Regards
> Sabine
>
> View this message in context: Re: One comment to new Pharo5 debugger
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

--
www.tudorgirba.com
www.feenk.com

"The coherence of a trip is given by the clearness of the goal."

gcotelli

Re: One comment to new Pharo5 debugger

In reply to this post by Tudor Girba-2

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).

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."

Ben Coman

Re: 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."