Smalltalk › Pharo › Pharo Smalltalk Developers

Debugger Button Positioning

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Eliot Miranda-2

Debugger Button Positioning

Hi All,

I've been using Pharo intensively for the first time, Pharo 7. Forgive me for starting with a complaint, but I don't have time to state all the things that are great about it; you already now ;-)

One thing I find painful is the positioning of the debugger into/over/through buttons. Because these are above the context list, and you read the code like I do, one has to mouse further to reach them. I find my focus is on the highlighted method, and my cursor is typically within it (I'm dong implementors, or senders, or just looking at the code). Further, there's lots of space between the Source tab and the "Where Is?" and "Browse" buttons. Doesn't it make more sense to put the into/over/through buttons between the Source tab and the "Where Is?" button? If not, doesn't it make sense to put a copy of the buttons there where they're in much easier reach?

_,,,^..^,,,_

best, Eliot

Esteban A. Maringolo

Re: Debugger Button Positioning

On 14/06/2018 15:13, Eliot Miranda wrote:

> Hi All,
>
> I've been using Pharo intensively for the first time, Pharo 7.
> Forgive me for starting with a complaint, but I don't have time to state
> all the things that are great about it; you already now ;-)
>
> One thing I find painful is the positioning of the debugger
> into/over/through buttons. Because these are above the context list,
> and you read the code like I do, one has to mouse further to reach
> them. I find my focus is on the highlighted method, and my cursor is
> typically within it (I'm dong implementors, or senders, or just looking
> at the code). Further, there's lots of space between the Source tab and
> the "Where Is?" and "Browse" buttons. Doesn't it make more sense to put
> the into/over/through buttons between the Source tab and the "Where Is?"
> button? If not, doesn't it make sense to put a copy of the buttons
> there where they're in much easier reach?

I agree with you in all your remarks, and IMO not only the buttons
position is suboptimal, also their shortcuts.

But AFAIR this was discussed some time ago when the GTDebugger was set
as the default debugger.

But the discussion was settled to "you can create your own". Which I
don't like, but it's fair enough. :)

Regards!

--
Esteban A. Maringolo

CyrilFerlicot

Re: Debugger Button Positioning

In reply to this post by Eliot Miranda-2

Le 14/06/2018 à 20:13, Eliot Miranda a écrit :
> Hi All,
>

Hi,

> I've been using Pharo intensively for the first time, Pharo 7.
> Forgive me for starting with a complaint, but I don't have time to state
> all the things that are great about it; you already now ;-)
>

No problem. It's always easier to talk about the bad things than to good
ones. :) I hope you will like your usage of Pharo.

> One thing I find painful is the positioning of the debugger
> into/over/through buttons. Because these are above the context list,
> and you read the code like I do, one has to mouse further to reach
> them. I find my focus is on the highlighted method, and my cursor is
> typically within it (I'm dong implementors, or senders, or just looking
> at the code). Further, there's lots of space between the Source tab and
> the "Where Is?" and "Browse" buttons. Doesn't it make more sense to put
> the into/over/through buttons between the Source tab and the "Where Is?"
> button? If not, doesn't it make sense to put a copy of the buttons
> there where they're in much easier reach?
>

It was raised many times before but apparently it was not easy to change.

Peter did some scripts to change it and I currently use them.

The code can be found here:

https://github.com/jecisc/pharo-scripts/tree/master/settings/PharoSettings5.package

There are some extensions to the debugger and to replace the current
behaviour of the debugger I use Metalinks
(https://github.com/jecisc/pharo-scripts/blob/master/settings/PharoSettings5.package/Pharo5CommonSettings.class/class/addMetaLinksForDebugger.st)

If we can have a way to get it directly into the debugger it would be
great. :)

> _,,,^..^,,,_
> best, Eliot

--
Cyril Ferlicot
https://ferlicot.fr

signature.asc (836 bytes) Download Attachment

Henrik-Nergaard

Re: Debugger Button Positioning

Hi,

Moving the icons down to the middle row is as simple as changing:

***
codeActionsPragmas
^ #( stackDebuggingActions codeDebuggingActions )
***
***
stackDebuggingActionsPragmas
^ #()
***

in GTGenericStackDebugger.

Best regards,
Henrik

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Ben Coman

Re: Debugger Button Positioning

On 15 June 2018 at 03:47, Henrik-Nergaard <[hidden email]> wrote:

Hi,

Moving the icons down to the middle row is as simple as changing:

***
codeActionsPragmas
^ #( stackDebuggingActions codeDebuggingActions )

Thanks for the tip. Note this needs to be stackDebuggingAction

cheers -ben

Ben Coman

Re: Debugger Button Positioning

On 15 June 2018 at 06:51, Ben Coman <[hidden email]> wrote:

On 15 June 2018 at 03:47, Henrik-Nergaard <[hidden email]> wrote:
Hi,

Moving the icons down to the middle row is as simple as changing:

***
codeActionsPragmas
^ #( stackDebuggingActions codeDebuggingActions )

Thanks for the tip. Note this needs to be stackDebuggingAction

cheers -ben

Anyone know how to do an experiment duplicating the debugging buttons vertically to the left of the code pane,

but only the small icon, no text ?

cheers -ben

Eliot Miranda-2

Re: Debugger Button Positioning

In reply to this post by Henrik-Nergaard

Hi Henrik,

On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard <[hidden email]> wrote:

Hi,

Moving the icons down to the middle row is as simple as changing:

***
codeActionsPragmas
^ #( stackDebuggingActions codeDebuggingActions )
***
***
stackDebuggingActionsPragmas
^ #()
***

in GTGenericStackDebugger.

Best regards,
Henrik

Thanks. I have to say that the renaming from #stackDebuggingActions to gtStackDebuggingAction, as in

StepIntoDebugAction class>>gtStackDebuggingActionFor: aDebugger

is a cruel joke. The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible.

_,,,^..^,,,_

best, Eliot "I designed pragmas to be useful and natural, not painful and obscure" Miranda

Tim Mackinnon

Re: Debugger Button Positioning

The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible.

Hi Eliot - I’ve been caught out by that belief too - but if you select a pragma and do cmd-b, cmd-n (or menu code-search, senders of it) - it works How I think you are expecting and shows you all the senders of that pragma. I use this all of the time for remember how to implement GT-Inspector tabs , as I was always impressed with the one in Date and use it as a way to find lots of good examples.

It could be, that you tried “implementers of” - and that one always confuses me - partly because they aren’t a real thing (and I guess I agree with you on a distaste for them - it feels like we could have done better somehow?).

Tim

On 15 Jun 2018, at 00:23, Eliot Miranda <[hidden email]> wrote:

Hi Henrik,

On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard <[hidden email]> wrote:
Hi,

Moving the icons down to the middle row is as simple as changing:

***
codeActionsPragmas
^ #( stackDebuggingActions codeDebuggingActions )
***
***
stackDebuggingActionsPragmas
^ #()
***

in GTGenericStackDebugger.

Best regards,
Henrik

Thanks. I have to say that the renaming from #stackDebuggingActions to gtStackDebuggingAction, as in

StepIntoDebugAction class>>gtStackDebuggingActionFor: aDebugger
<gtStackDebuggingAction>

is a cruel joke. The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible.

_,,,^..^,,,_
best, Eliot "I designed pragmas to be useful and natural, not painful and obscure" Miranda

Eliot Miranda-2

Re: Debugger Button Positioning

Hi Tim,

On Fri, Jun 15, 2018 at 2:21 PM, Tim Mackinnon <[hidden email]> wrote:

The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible.

Hi Eliot - I’ve been caught out by that belief too - but if you select a pragma and do cmd-b, cmd-n (or menu code-search, senders of it) - it works How I think you are expecting and shows you all the senders of that pragma. I use this all of the time for remember how to implement GT-Inspector tabs , as I was always impressed with the one in Date and use it as a way to find lots of good examples.

It could be, that you tried “implementers of” - and that one always confuses me - partly because they aren’t a real thing (and I guess I agree with you on a distaste for them - it feels like we could have done better somehow?).

These aren't the issues here. The issue here is the classic one of name mangling, a.k.a. constructing selectors from fragments, so that the reference (the elements of the arrays in codeDebuggingPragmas and stackDebuggingActionPragmas, which are #codeDebuggingAction #stackDebuggingAction) don't match the pragmas in the methods, which are <gtCodeDebuggingAction> & <gtStackDebuggingAction>. Why the mismatch? I would expect the references to use #gtCodeDebuggingAction & #gtStackDebuggingAction, and finding the implementations would be trivial. Instead one has to hunt. This is bad.

Tim

On 15 Jun 2018, at 00:23, Eliot Miranda <[hidden email]> wrote:

Hi Henrik,

On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard <[hidden email]> wrote:
Hi,

Moving the icons down to the middle row is as simple as changing:

***
codeActionsPragmas
^ #( stackDebuggingActions codeDebuggingActions )
***
***
stackDebuggingActionsPragmas
^ #()
***

in GTGenericStackDebugger.

Best regards,
Henrik

Thanks. I have to say that the renaming from #stackDebuggingActions to gtStackDebuggingAction, as in

StepIntoDebugAction class>>gtStackDebuggingActionFor: aDebugger
<gtStackDebuggingAction>

is a cruel joke. The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible.

_,,,^..^,,,_
best, Eliot "I designed pragmas to be useful and natural, not painful and obscure" Miranda

_,,,^..^,,,_

best, Eliot

Tudor Girba-2

Re: Debugger Button Positioning

Hi,

This is indeed an issue we should have solved. The concatenation of pragma selectors is unnecessary in this case, but we did not clean it up and it remained like this.

Cheers,
Doru

> On Jun 16, 2018, at 8:58 AM, Eliot Miranda <[hidden email]> wrote:
>
> Hi Tim,
>
> On Fri, Jun 15, 2018 at 2:21 PM, Tim Mackinnon <[hidden email]> wrote:
>> The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible.
>
> Hi Eliot - I’ve been caught out by that belief too - but if you select a pragma and do cmd-b, cmd-n (or menu code-search, senders of it) - it works How I think you are expecting and shows you all the senders of that pragma. I use this all of the time for remember how to implement GT-Inspector tabs , as I was always impressed with the one in Date and use it as a way to find lots of good examples.
>
> It could be, that you tried “implementers of” - and that one always confuses me - partly because they aren’t a real thing (and I guess I agree with you on a distaste for them - it feels like we could have done better somehow?).
>
> These aren't the issues here. The issue here is the classic one of name mangling, a.k.a. constructing selectors from fragments, so that the reference (the elements of the arrays in codeDebuggingPragmas and stackDebuggingActionPragmas, which are #codeDebuggingAction #stackDebuggingAction) don't match the pragmas in the methods, which are <gtCodeDebuggingAction> & <gtStackDebuggingAction>. Why the mismatch? I would expect the references to use #gtCodeDebuggingAction & #gtStackDebuggingAction, and finding the implementations would be trivial. Instead one has to hunt. This is bad.
>
>
> Tim
>
>
>> On 15 Jun 2018, at 00:23, Eliot Miranda <[hidden email]> wrote:
>>
>> Hi Henrik,
>>
>> On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard <[hidden email]> wrote:
>> Hi,
>>
>> Moving the icons down to the middle row is as simple as changing:
>>
>> ***
>> codeActionsPragmas
>> ^ #( stackDebuggingActions codeDebuggingActions )
>> ***
>> ***
>> stackDebuggingActionsPragmas
>> ^ #()
>> ***
>>
>> in GTGenericStackDebugger.
>>
>> Best regards,
>> Henrik
>>
>> Thanks. I have to say that the renaming from #stackDebuggingActions to gtStackDebuggingAction, as in
>>
>> StepIntoDebugAction class>>gtStackDebuggingActionFor: aDebugger
>> <gtStackDebuggingAction>
>>
>> is a cruel joke. The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible.
>>
>> _,,,^..^,,,_
>> best, Eliot "I designed pragmas to be useful and natural, not painful and obscure" Miranda
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot

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

"There are no old things, there are only old ways of looking at them."

Eliot Miranda-2

Re: Debugger Button Positioning

Hi Doru,

On Sat, Jun 16, 2018 at 2:25 AM, Tudor Girba <[hidden email]> wrote:

Hi,

This is indeed an issue we should have solved. The concatenation of pragma selectors is unnecessary in this case, but we did not clean it up and it remained like this.

If the issue is that one wants generosity at the reference (in the actions methods that provide what should be pragma names) and specificity at the referent (the methods containing the pragmas) then one can add a second pragma and use and "and" function to insist on the pragma plus another qualifier. For example,

StepOverDebugAction class>>gtStackDebuggingActionFor: aDebugger

^ (self forDebugger: aDebugger)

icon: GLMUIThemeExtraIcons glamorousOver

could become

StepOverDebugAction class>>gtStackDebuggingActionFor: aDebugger

^ (self forDebugger: aDebugger)

icon: GLMUIThemeExtraIcons glamorousOver

but I suspect that's not necessary here because all these methods exist in a class hierarchy that can provide the context and specificity required.

But in this case it seems to me that there's a deeper weakness/opportunity. The meat of each class is the executeAction method, for example

StepOverDebugAction >>executeAction

self session stepOver: self currentContext

why not add the pragma there and dispense with the gtStackDebuggingActionFor: methods altogether. For example, you could include a pragma identifying the method as an action, and a pragma to be used by a builder to add the action, or at least specify the parameters:

StepOverDebugAction >>executeAction

<uiThemeIcon: #glamorousOver hotKey: $H> "This could be performed by a builder class specific to building glamorous debuggers, or glamorous tools, or..."

self session stepOver: self currentContext

This second pragma could have as many keywords and arguments as one wants, and serves to reduce the additional machinery one needs to "plug" something in.

In general the pattern is to annotate some action or entry point method with pragmas that specify how the method fits in to some larger context, so for example,

- an action method on a menu, where a single pragma can specify the label, icon, hot key, and menu name, using a message understood by a menu decorator that would perform the pragma to add it to the menu (and then if there is a hook on the class side that is looking for method additions and removals, menus in live tools can update as soon as a method containing such a pragma is added or removed)

- an entry point for some exported interface, such as a COM interface, where the pragma specifies the types of the incoming parameters, and hence as the method is installed into some built interface, the relevant marshaling machinery is built, rather than being specified off to the side

Used in this way, information about how a component fits in can be localized in the key method(s) providing the component, instead of being spread over several methods, reducing load on the programmer in comprehending and adding similar actions.

Cheers,
Doru

> On Jun 16, 2018, at 8:58 AM, Eliot Miranda <[hidden email]> wrote:
>
> Hi Tim,
>
> On Fri, Jun 15, 2018 at 2:21 PM, Tim Mackinnon <[hidden email]> wrote:
>> The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible.
>
> Hi Eliot - I’ve been caught out by that belief too - but if you select a pragma and do cmd-b, cmd-n (or menu code-search, senders of it) - it works How I think you are expecting and shows you all the senders of that pragma. I use this all of the time for remember how to implement GT-Inspector tabs , as I was always impressed with the one in Date and use it as a way to find lots of good examples.
>
> It could be, that you tried “implementers of” - and that one always confuses me - partly because they aren’t a real thing (and I guess I agree with you on a distaste for them - it feels like we could have done better somehow?).
>
> These aren't the issues here. The issue here is the classic one of name mangling, a.k.a. constructing selectors from fragments, so that the reference (the elements of the arrays in codeDebuggingPragmas and stackDebuggingActionPragmas, which are #codeDebuggingAction #stackDebuggingAction) don't match the pragmas in the methods, which are <gtCodeDebuggingAction> & <gtStackDebuggingAction>. Why the mismatch? I would expect the references to use #gtCodeDebuggingAction & #gtStackDebuggingAction, and finding the implementations would be trivial. Instead one has to hunt. This is bad.
>
>
> Tim
>
>
>> On 15 Jun 2018, at 00:23, Eliot Miranda <[hidden email]> wrote:
>>
>> Hi Henrik,
>>
>> On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard <[hidden email]> wrote:
>> Hi,
>>
>> Moving the icons down to the middle row is as simple as changing:
>>
>> ***
>> codeActionsPragmas
>> ^ #( stackDebuggingActions codeDebuggingActions )
>> ***
>> ***
>> stackDebuggingActionsPragmas
>> ^ #()
>> ***
>>
>> in GTGenericStackDebugger.
>>
>> Best regards,
>> Henrik
>>
>> Thanks. I have to say that the renaming from #stackDebuggingActions to gtStackDebuggingAction, as in
>>
>> StepIntoDebugAction class>>gtStackDebuggingActionFor: aDebugger
>> <gtStackDebuggingAction>
>>
>> is a cruel joke. The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible.
>>
>> _,,,^..^,,,_
>> best, Eliot "I designed pragmas to be useful and natural, not painful and obscure" Miranda
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot

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

"There are no old things, there are only old ways of looking at them."

_,,,^..^,,,_

best, Eliot