Le 9/1/16 11:02, Esteban Lorenzano a écrit :
you have to confess that with text and icons looks a lot better than
the old one :P
you mean both old ones GT and Spec.
I hated the the GT icons because I was forced to wait for the fly by help
I hate this interfaces that looks nice but are not efficient.
On 09 Jan 2016, at 11:01, Esteban Lorenzano <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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"?
