Thanks. What do you think of the new solution? Is it sufficient?

Doru


> On Jan 8, 2016, at 8:05 PM, Johan Fabry <[email protected]> wrote:
> 
> 
> I second Torsten’s comment with regard to the use of space, I also think the 
> original positioning of stack and code panes is more efficient.
> 
>> On Jan 8, 2016, at 14:28, Torsten Bergmann <[email protected]> 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" <[email protected]>
>> An: "Pharo Development List" <[email protected]>, "Moose-dev Moose 
>> Dev" <[email protected]>, "Any question about pharo is welcome" 
>> <[email protected]>
>> 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."
> 
> 
> 
> ---> Save our in-boxes! http://emailcharter.org <---
> 
> Johan Fabry   -   http://pleiad.cl/~jfabry
> PLEIAD and RyCh labs  -  Computer Science Department (DCC)  -  University of 
> Chile
> 
> 

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

"It's not how it is, it is how we see it."


Reply via email to