Debugger Button Positioning

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Debugger Button Positioning

Eliot Miranda-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Debugger Button Positioning

Esteban A. Maringolo
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

Reply | Threaded
Open this post in threaded view
|

Re: Debugger Button Positioning

CyrilFerlicot
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
Reply | Threaded
Open this post in threaded view
|

Re: Debugger Button Positioning

Henrik-Nergaard
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

Reply | Threaded
Open this post in threaded view
|

Re: Debugger Button Positioning

Ben Coman


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
 
Reply | Threaded
Open this post in threaded view
|

Re: Debugger Button Positioning

Ben Coman


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
Reply | Threaded
Open this post in threaded view
|

Re: Debugger Button Positioning

Eliot Miranda-2
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
<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
Reply | Threaded
Open this post in threaded view
|

Re: Debugger Button Positioning

Tim Mackinnon
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

Reply | Threaded
Open this post in threaded view
|

Re: Debugger Button Positioning

Eliot Miranda-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Debugger Button Positioning

Tudor Girba-2
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."





Reply | Threaded
Open this post in threaded view
|

Re: Debugger Button Positioning

Eliot Miranda-2
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
<gtStackDebuggingAction>
^ (self forDebugger: aDebugger)
icon: GLMUIThemeExtraIcons glamorousOver

could become

StepOverDebugAction class>>gtStackDebuggingActionFor: aDebugger
<stackDebuggingAction>
<GlamorousDebugger>
^ (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
<stackDebuggingAction>
<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