Re: [Pharo-dev] [ann] gtdebugger in pharo 5.0

On Jan 8, 2016, at 7:28 PM, Torsten Bergmann <[hidden email]> wrote:

Hi,

with a moldable debugger we should (in the future) be able to support
debugging also different/other programming languages/DSLs in Pharo :) 

- although usually one does necessary have such a use case. So I guess
GTInspector or other will be adopted to own needs more than GTDebugger. 

However:
The only objection so far is that I dislike the order/size of the panes.

The placement of the panes in GTDebugger (as for instance found in Moose)
requires often to use the scrollbars of the pane showing the stack because
of the text length. 

In GTDebugger the stack is at the top left, the source at the top right with 
a common splitter beneath the two panes: therefore the height (depth) of the 
stack pane is always the height of the code pane.
When you have a long method to debug on the right much space is wasted for 
a deep stack on the left although you might only be interested in a few top frames.

Contrary when you have are interested in a deep/full stack and you increase the
height of the stack pane on the left you directly increase the height of the code
pane and for short methods you waste a lot of space in the source pane as well.

This is much better solved with the positioning in the traditinal Debugger:
- Stack 
- Source
- other 

So in my opinion We should preserve:

 - TOP:    the stack at the top (using the full width of the window, so only vertical scrolling
           has to be done to "roll" on the stack, no need for horizontal scrolling as the area
           is wide enough)
 - MIDDLE: the source code pane in the middle (also using the full width of the window and there
           fore in alignment with code pane in the the usual tools like Nautilus, change sorter, ...)
 - BOTTON: one or more panel for inspection at the bottom

It would be OK for me if others like the new layout better - but at least there should be an 
option to support the traditional layout as well (or support pane movemen/docking as in other IDEs) 

Also the debugger window in Moose wastes a lot of space/has unused space within the 
windows client are itself. For instance the splitters are very thick which might be an issue of 
the moose theme.

Thanks
T. 

Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr
Von: "Tudor Girba" <[hidden email]>
An: "Pharo Development List" <[hidden email]>, "Moose-dev Moose Dev" <[hidden email]>, "Any question about pharo is welcome" <[hidden email]>
Betreff: [Pharo-dev] [ann] gtdebugger in pharo 5.0

Hi,
 
We are about to integrate in Pharo a new member of the Glamorous Toolkit: the GTDebugger. As this is a significant change that might affect your workflow, here is some background information to help you deal with the change.
 
First, you should know that the change is not irreversible and it is easily possible to disabled the new debugger through a setting. However, please do take the time to provide us feedback if something does not work out for you. We want to know what can be improved and we try to react as fast as we can.
 
A practical change comes from the fact that the variables are manipulated through a GTInspector, which makes it cheaper to maintain in the longer run.
 

 While the first thing that will capture the attention is the default generic interface, the real power comes from the moldable nature of the debugger. Like all other GT tools, GTDebugger is also moldable by design. This means that we can construct custom debuggers for specific libraries at small costs (often measured in a couple of hundred lines of code).
 

 
Here is an introductory overview blog post that also includes some links for further reading:
http://www.humane-assessment.com/blog/gtdebugger-in-pharo/
 
Please let us know what you think.
 
Cheers,
Doru
 
 
--
www.tudorgirba.com[http://www.tudorgirba.com]
www.feenk.com[http://www.feenk.com]

"Beauty is where we see it."

On Jan 8, 2016, at 7:28 PM, Torsten Bergmann <[hidden email]> wrote:

Hi,

with a moldable debugger we should (in the future) be able to support
debugging also different/other programming languages/DSLs in Pharo :) 

- although usually one does necessary have such a use case. So I guess
GTInspector or other will be adopted to own needs more than GTDebugger. 

However:
The only objection so far is that I dislike the order/size of the panes.
The placement of the panes in GTDebugger (as for instance found in Moose)
requires often to use the scrollbars of the pane showing the stack because
of the text length. 

In GTDebugger the stack is at the top left, the source at the top right with 
a common splitter beneath the two panes: therefore the height (depth) of the 
stack pane is always the height of the code pane.
When you have a long method to debug on the right much space is wasted for 
a deep stack on the left although you might only be interested in a few top frames.

Contrary when you have are interested in a deep/full stack and you increase the
height of the stack pane on the left you directly increase the height of the code
pane and for short methods you waste a lot of space in the source pane as well.

This is much better solved with the positioning in the traditinal Debugger:
- Stack 
- Source
- other 

So in my opinion We should preserve:

 - TOP:    the stack at the top (using the full width of the window, so only vertical scrolling
           has to be done to "roll" on the stack, no need for horizontal scrolling as the area
           is wide enough)
 - MIDDLE: the source code pane in the middle (also using the full width of the window and there
           fore in alignment with code pane in the the usual tools like Nautilus, change sorter, ...)
 - BOTTON: one or more panel for inspection at the bottom

It would be OK for me if others like the new layout better - but at least there should be an 
option to support the traditional layout as well (or support pane movemen/docking as in other IDEs) 

Also the debugger window in Moose wastes a lot of space/has unused space within the 
windows client are itself. For instance the splitters are very thick which might be an issue of 
the moose theme.

Thanks
T. 

Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr
Von: "Tudor Girba" <[hidden email]>
An: "Pharo Development List" <[hidden email]>, "Moose-dev Moose Dev" <[hidden email]>, "Any question about pharo is welcome" <[hidden email]>
Betreff: [Pharo-dev] [ann] gtdebugger in pharo 5.0

Hi,
 
We are about to integrate in Pharo a new member of the Glamorous Toolkit: the GTDebugger. As this is a significant change that might affect your workflow, here is some background information to help you deal with the change.
 
First, you should know that the change is not irreversible and it is easily possible to disabled the new debugger through a setting. However, please do take the time to provide us feedback if something does not work out for you. We want to know what can be improved and we try to react as fast as we can.
 
A practical change comes from the fact that the variables are manipulated through a GTInspector, which makes it cheaper to maintain in the longer run.
 

 While the first thing that will capture the attention is the default generic interface, the real power comes from the moldable nature of the debugger. Like all other GT tools, GTDebugger is also moldable by design. This means that we can construct custom debuggers for specific libraries at small costs (often measured in a couple of hundred lines of code).
 

 
Here is an introductory overview blog post that also includes some links for further reading:
http://www.humane-assessment.com/blog/gtdebugger-in-pharo/
 
Please let us know what you think.
 
Cheers,
Doru
 
 
--
www.tudorgirba.com[http://www.tudorgirba.com]
www.feenk.com[http://www.feenk.com]

"Beauty is where we see it."