12 Jan
2016
12 Jan
'16
11:24 p.m.
2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
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.
Accept and Cancel buttons shouldn't be there
or should not act on if the codepane hasn't changed.
(every press on "accept" writes a new method version, although the contents
didn't changed - tested on
Latest update: #50524 )
Most (all?) other tools don't have Accept/Cancel buttons.
- I really miss the "List Methods using 'varname'/List Methods storing into
'varname'
- is "stackTop" now gone ? I thought you wanted to add it to the stack ?
- thisContext is gone as well ?
- the Bytecode/GT button is badly placed, it looks like the "downarrow"
window menu icon
is a dropdown menu with label "Bytecode" (since when do we put buttons in
the title pane?
- the evaluator pane is shown as "dirty", as it does not make a difference
if we
accept the text in this pane, there shouldn't be a dirty indicator.
- you can not use the inspector pane to change inst var values
- there is no way to refresh the inspector pane
I don't open bugtracker entries now, I 'll wait maybe this issues aren't
bugs but
features.
nicolai
12 Jan
12 Jan
11:31 p.m.
New subject: [Pharo-users] [ann] gtdebugger in pharo 5.0
no, I’m quite sure they are bugs :)
I also believe the other tools do not have accept/cancel visible (they are in contextual
menus), so maybe they should be there.
Esteban
On 12 Jan 2016, at 23:24, Nicolai Hess
<nicolaihess(a)gmail.com> wrote:
2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com
<mailto:tudor@tudorgirba.com>>:
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.
Accept and Cancel buttons shouldn't be there
or should not act on if the codepane hasn't changed.
(every press on "accept" writes a new method version, although the contents
didn't changed - tested on
Latest update: #50524 )
Most (all?) other tools don't have Accept/Cancel buttons.
- I really miss the "List Methods using 'varname'/List Methods storing into
'varname'
- is "stackTop" now gone ? I thought you wanted to add it to the stack ?
- thisContext is gone as well ?
- the Bytecode/GT button is badly placed, it looks like the "downarrow" window
menu icon
is a dropdown menu with label "Bytecode" (since when do we put buttons in the
title pane?
- the evaluator pane is shown as "dirty", as it does not make a difference if
we
accept the text in this pane, there shouldn't be a dirty indicator.
- you can not use the inspector pane to change inst var values
- there is no way to refresh the inspector pane
I don't open bugtracker entries now, I 'll wait maybe this issues aren't bugs
but
features.
nicolai
14 Jan
14 Jan
12:59 p.m.
New subject: [Pharo-users] [ann] gtdebugger in pharo 5.0
Hi Nicolai,
Thanks for reporting these issues. They are indeed bugs and we are working
on fixing them.
Cheers,
Andrei
On Tue, Jan 12, 2016 at 11:24 PM, Nicolai Hess <nicolaihess(a)gmail.com>
wrote:
2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
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.
Accept and Cancel buttons shouldn't be there
or should not act on if the codepane hasn't changed.
(every press on "accept" writes a new method version, although the
contents didn't changed - tested on
Latest update: #50524 )
Most (all?) other tools don't have Accept/Cancel buttons.
- I really miss the "List Methods using 'varname'/List Methods storing
into 'varname'
- is "stackTop" now gone ? I thought you wanted to add it to the stack ?
- thisContext is gone as well ?
- the Bytecode/GT button is badly placed, it looks like the "downarrow"
window menu icon
is a dropdown menu with label "Bytecode" (since when do we put buttons
in the title pane?
- the evaluator pane is shown as "dirty", as it does not make a difference
if we
accept the text in this pane, there shouldn't be a dirty indicator.
- you can not use the inspector pane to change inst var values
- there is no way to refresh the inspector pane
I don't open bugtracker entries now, I 'll wait maybe this issues aren't
bugs but
features.
nicolai
15 Jan
15 Jan
1:39 p.m.
New subject: [Pharo-users] [ann] gtdebugger in pharo 5.0
Hi,
Thanks indeed for the feedback. I think not quite all are bugs, but see more details
inside.
On Jan 14, 2016, at 12:59 PM, Andrei Chis
<chisvasileandrei(a)gmail.com> wrote:
Hi Nicolai,
Thanks for reporting these issues. They are indeed bugs and we are working on fixing
them.
Cheers,
Andrei
On Tue, Jan 12, 2016 at 11:24 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote:
2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
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.
Accept and Cancel buttons shouldn't be there
or should not act on if the codepane hasn't changed.
(every press on "accept" writes a new method version, although the contents
didn't changed - tested on
Latest update: #50524 )
Good catch. This will happen even if the button would not be present.
Most (all?) other tools don't have Accept/Cancel
buttons.
The logic is that these are actions that do not depend on the selection, so in Glamour we
map these on actions that are applicable to the entire presentation. A similar approach is
present in the inspector, although probably it does not appear so prominently because
there is no text. We could try to add them in a dropdown menu. Would that help?
- I really miss the "List Methods using
'varname'/List Methods storing into ‘varname'
Please open an issue for this.
- is "stackTop" now gone ? I thought you
wanted to add it to the stack ?
- thisContext is gone as well ?
These were removed due to emergency mail exchange that happened during the last weekend.
- the Bytecode/GT button is badly placed, it looks
like the "downarrow" window menu icon
is a dropdown menu with label “Bytecode"
We could try to fix by adding more space to the left of the menu bar in the theme. Could
you open an issue?
(since when do we put buttons in the title pane?
Since Glamour makes it easy to have them there :). The GTPlayground and GTInspector have
them, too.
- the evaluator pane is shown as "dirty", as
it does not make a difference if we
accept the text in this pane, there shouldn't be a dirty indicator.
This is a problem that seems to exist with basically every pharoScript in Glamour. You
commented on an issue for this:
https://pharo.fogbugz.com/f/cases/16757/GLMHighlighterTextRubEditingMode-al…
- you can not use the inspector pane to change inst
var values
This is a problem but it is not specific to the debugger.
- there is no way to refresh the inspector pane
Indeed. Would it be enough if we added a refresh for the whole debugger?
Cheers,
Doru
I don't open bugtracker entries now, I 'll
wait maybe this issues aren't bugs but
features.
nicolai
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
www.feenk.com
"Not knowing how to do something is not an argument for how it cannot be done."
17 Jan
17 Jan
7:56 p.m.
New subject: [Pharo-dev] [Pharo-users] [ann] gtdebugger in pharo 5.0
2016-01-15 13:39 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
still I don't think this is a good idea. What is the difference between
action buttons in the title pane
and the other one.
Yes this is working nwo in 3.8.
I don't know if there is an easy solution. But it was nice in the old
debugger resp. inspector pane to have auto-updates for this values.
Hi,
Thanks indeed for the feedback. I think not quite all are bugs, but see
more details inside.
This issue is one year old:
14583
<https://pharo.fogbugz.com/f/cases/14583/inspector-and-instvars-list-methods-storing-into-using>
inspector and instvars : list methods storing into/using
On Jan 14, 2016, at 12:59 PM, Andrei Chis
<chisvasileandrei(a)gmail.com>
wrote:
Hi Nicolai,
Thanks for reporting these issues. They are indeed bugs and we are
working on
fixing them.
Cheers,
Andrei
On Tue, Jan 12, 2016 at 11:24 PM, Nicolai Hess <nicolaihess(a)gmail.com>
wrote:
2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
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.
Accept and Cancel buttons shouldn't be there
or should not act on if the codepane hasn't changed.
(every press on "accept" writes a new method version, although the
contents didn't changed - tested on
Latest update: #50524 )
Good catch. This will happen even if the button would not be present.
Most (all?) other tools don't have
Accept/Cancel buttons.
The logic is that these are actions that do not depend on the selection,
so in Glamour we map these on actions that are applicable to the entire
presentation. A similar approach is present in the inspector, although
probably it does not appear so prominently because there is no text. We
could try to add them in a dropdown menu. Would that help?
- I really miss the "List Methods using
'varname'/List Methods storing
into ‘varname'
Please open an issue for this.
- is "stackTop" now gone ? I thought
you wanted to add it to the stack ?
- thisContext is gone as well ?
These were removed due to emergency mail exchange that happened during the
last weekend.
- the Bytecode/GT button is badly placed, it
looks like the "downarrow"
window menu icon
is a dropdown menu with label “Bytecode"
We could try to fix by adding more space to the left of the menu bar in
the theme. Could you open an issue?
(since when do we put buttons in the title pane?
Since Glamour makes it easy to have them there :). The GTPlayground and
GTInspector have them, too.
- the evaluator pane is shown as
"dirty", as it does not make a
difference if we
accept the text in this pane, there
shouldn't be a dirty indicator.
This is a problem that seems to exist with basically every pharoScript in
Glamour. You commented on an issue for this:
https://pharo.fogbugz.com/f/cases/16757/GLMHighlighterTextRubEditingMode-al…
- you can not use the inspector pane to change
inst var values
This is a problem but it is not specific to the debugger.
- there is no way to refresh the inspector pane
Indeed. Would it be enough if we added a refresh for the whole debugger?
Cheers,
Doru
I don't open bugtracker entries now, I
'll wait maybe this issues aren't
bugs but
features.
nicolai
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
www.feenk.com
"Not knowing how to do something is not an argument for how it cannot be
done."
10:09 p.m.
New subject: [Pharo-users] [Pharo-dev] [ann] gtdebugger in pharo 5.0
Hi,
Ok. Thanks. Fixed.
We have now moved the accept and cancel to the contextual menu for now. However, the
longer term goal is to change this pattern. Here is a longer explanation.
We think of the IDE like terms an object-oriented system built using a language. From this
point of view, an action is put in the context that provides enough information to trigger
it. So, for actions that do not rely on the selection, or on the cursor position, we can
safely put them in the toolbar of the presentation. For global actions (like refreshing
the whole inspector), we put them all the way in the title bar.
For example:
- "Do It” depends on the selection or cursor, and thus it is added to the context
menu
- “Accept" is not specific to the current location of the cursor or of the selection
and can be made presentation specific (added to the toolbar of the presentation).
- Switching the whole debugger to a “Bytecode” one is global for the whole debugger, and
it is added to the top of the visual hierarchy.
This choice also documents the scope of an action. For example, imagine having a global
toolbar with actions that only do something in a certain pane (out of possible many). How
will you know before triggering what is the effect going to be? But, if you always put the
action to the scope that it affects, there is a more clear connection because cause and
effect.
And there is yet another advantage. When you stick with this design, you get potentially
reusable components.
This does require some getting used to. And this design will not necessarily work for
general UIs. But, an IDE is not a general UI. It is made for programmers, and in our case,
it is made for object-oriented programmers, and we can use the abilities of such
programmers in our designs.
Does this explanation make more sense?
Cheers,
Doru
--
www.tudorgirba.com
www.feenk.com
"To utilize feedback, you first have to acquire it."
On Jan 17, 2016, at 7:56 PM, Nicolai Hess
<nicolaihess(a)gmail.com> wrote:
[…]
- I really
miss the "List Methods using 'varname'/List Methods storing into
‘varname'
Please open an issue for this.
This issue is one year old:
14583 inspector and instvars : list methods storing into/using
[…]
(since when do
we put buttons in the title pane?
Since Glamour makes it easy to have them there :). The GTPlayground and GTInspector have
them, too.
still I don't think this is a good idea. What is the difference between action
buttons in the title pane
and the other one.
11:16 p.m.
New subject: [Pharo-users] [Pharo-dev] [ann] gtdebugger in pharo 5.0
2016-01-17 22:09 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>om>:
Hi,
Thanks Doru,
I commented on the bug report.
Will this be included in the (left most) inspector pane in the debugger?
(this is difficult to use in the "State"-pane, because as soon as you try to
bring up the popup-menu, the pane "slides away").
nicolai
On Jan 17, 2016, at 7:56 PM, Nicolai Hess
<nicolaihess(a)gmail.com> wrote:
[…]
> - I really miss the "List Methods using
'varname'/List Methods storing
into ‘varname'
Please open an issue for this.
This issue is one year old:
14583 inspector and instvars : list methods storing into/using
Ok. Thanks. Fixed.
--
www.tudorgirba.com
www.feenk.com
"To utilize feedback, you first have to acquire it."
3015
days inactive
3020
days old
6 comments
4 participants
participants (4)
-
Andrei Chis -
Esteban Lorenzano -
Nicolai Hess -
Tudor Girba