Am 09.01.2016 11:03 vorm. schrieb "Esteban Lorenzano" <estebanlm@gmail.com>:
>
> you have to confess that with text and icons looks a lot better than the old one :P
>

Yes alot better

>> On 09 Jan 2016, at 11:01, Esteban Lorenzano <estebanlm@gmail.com> wrote:
>>
>> again re-send because of exceed limits with the image (that���s new?)
>>
>> with a small tweak, texts (AND icons :P):
>>
>>
>> <Screen Shot 2016-01-09 at 10.59.20.png>
>>
>> would that be aceptable for you?
>>
>> cheers!
>> Esteban
>>
>>> On 09 Jan 2016, at 09:43, Esteban Lorenzano <estebanlm@gmail.com> wrote:
>>>
>>> (re-send because I exceeded limit.)
>>>
>>> Hi,
>>>
>>> let���s think positive.��
>>> the GTDebugger is a step forward��� it allow a lot of better interactions and of course, it needs some iterations to make it appealing to everybody.��
>>> For instance, I took me 2��� to tweak the debugger presentation and to get this:��
>>>
>>> <Screen Shot 2016-01-09 at 09.29.59.png>
>>>
>>> (I changed all available��� is a trivial task)
>>>
>>> and like IMO feels a lot better��� and I think is a good compromise between the old and the new.��
>>> Reasons to suggest this approach:��
>>>
>>> - it keeps old approach who(I think) was good (I can see the stack, and the flow feels natural from top to down)
>>> - it preserves ���the important��� (the code) as central.
>>> - it gives space for adding columns (like the bytecode).��
>>>
>>> Now��� I can understand you want icons with text, and that can be hacked too�����
>>>
>>> So��� can we have an agreement?
>>>
>>> Esteban
>>>
>>> ps: btw��� using GT with Fast Table we can also avoid those annoying paginated lists too
>>>
>>>> On 09 Jan 2016, at 08:53, stepharo <stepharo@free.fr> wrote:
>>>>
>>>> Thanks for your testimony.
>>>>
>>>> I'm not against GTDebugger per se. I believe that we should have better tools
>>>> but we should take time for building better tools (even if this is two years that moosers use or not this new debugger).
>>>> I would appreciate a process where users can give real feedback and we can simplify/shape our tools nicely.
>>>>
>>>> Now for the mooc I will not present GTDebugger. So students will not use Pharo 50
>>>>
>>>> Stef
>>>>
>>>>> Le 08/01/2016 21:22, stepharo a ��crit :
>>>>>>
>>>>>> I'm sorry but this debugger should not be the default one.
>>>>>> MONDAY we are filming our mooc and we have to explain the debugger and
>>>>>> personally I do not see the gain:
>>>>>> ��������- It looks a lot more complex to me and I do not want to have to
>>>>>> redo all the screenshots
>>>>>> ��������of our lecture.
>>>>>> ��������- Just that I have to learn the meaning of small icons.
>>>>>> ��������- Why do we need a special pane for the evaluator
>>>>>> ��������- Why there is a type column.
>>>>>> ��������- Sorry but I'm not convinced about the moldable aspect behind the
>>>>>> story (no need to argue I know it)
>>>>>>
>>>>>> I would like to avoid to be forced to use not the latest version of
>>>>>> Pharo for the mooc.
>>>>>>
>>>>>> Such changes are arriving far too late in the release. We do not change
>>>>>> the debugger itself the day of code freeze.
>>>>>>
>>>>>> We decided that the GTDebugger can be included but to me it never meant
>>>>>> that it should be the default one.
>>>>>> I think that experts can choose the debugger they want. The newbies don't.
>>>>>>
>>>>>> Stef
>>>>>>
>>>>>>
>>>>> IMO the old debugger is way more intuitive.
>>>>> When I used the debugger of Eclipse for java I was lost. When I used
>>>>> Spec debugger I thought "Oh, this is not so hard in fact". And I lose
>>>>> the feeling with GTDebugger. And the debugger is one of the main source
>>>>> of interest for newbies.
>>>>>
>>>>> Maybe we could have a button on the spec Debugger "Switch to GTDebugger"?
>>>>>
>>>>
>>>>
>>>
>>
>