evaluate deselects in ws - possible to disable?

Hi...

today for the first time I noticed that selecting some lines in a workspace
and evaluating them deselects the lines. This is quite annoying as I would
like to start the same procedure several times. Can I somehow disable it? (a
hack would also be ok ;-).

My conclusion so far is that deselection is never useful on evaluate anyway.

Ciao

...Jochen

Jochen,

> today for the first time I noticed that selecting some lines in a
> workspace and evaluating them deselects the lines. This is quite
> annoying as I would like to start the same procedure several times.
> Can I somehow disable it? (a hack would also be ok ;-).

Hacks we can do :-) In

SmalltalkWorkspace>>evaluateItIfFail:debug:

change the last few lines to read ...

    self isOpen
        ifTrue: [
            (self view)
                resetCharFormat;
                selectionRange: evalRange].
    ^result

... which seems to do what you want?

> My conclusion so far is that deselection is never useful on evaluate
> anyway.

Can't say its something that has ever bothered me, but you could be right.

--
Ian

Jochen,

sorry, I couldn't resist to comment, but if you never noticed it before,
how annoying might it be? =8-)

Don't beat me, ouch!

Joe

> sorry, I couldn't resist to comment, but if you never noticed it before,
> how annoying might it be? =8-)

Hehe, thought this would pop up ;-). It seems that I never needed to perform
the same set of operations in rapid succession before. This might be due to
the fact that my frequent use of ST is only since about half a year.

>Don't beat me, ouch!
BTW: All things are bothering you only once you notice them, e.g. dripping,
ticking of a clock etc.
(consider this a light form of mental punishment ;-)

Ciao

...Jochen

Aah, much better! Ian, you saved my day :-).
Now that you showed me the place, I managed to improve it a bit further
(changedcode appended).
Now, the reselection occurs only if something was selected before. But her I
think it is a matter of taste what one likes more.

Ciao

...Jochen

SmalltalkWorkspace>>evaluateItIfFail: failBlock debug: aDebugBoolean
...
| noSelection evalRange result |
noSelection := self view selectionRange isEmpty.
...
self isOpen
ifTrue:
[self view resetCharFormat.
noSelection ifFalse: [self view selectionRange: evalRange]].
^result

Jochen,

> My conclusion so far is that deselection is never useful on evaluate
anyway.

I think one reason that it is useful is that it acts as feedback to show
that your evaluation has really been actioned.  One of the first principles
of GUI design is to give immediate feedback to the user so there is some
certainty that the computer has actually received a request and processed
it.  Typically this is done by making buttons appear to depress under the
mouse and making characters appear immediately they are typed.  In the case
of something "hidden" like the evaluation of a piece of code I think that
the deselection provides good feedback.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

> I think one reason that it is useful is that it acts as feedback to show
> that your evaluation has really been actioned.  One of the first
principles
> of GUI design is to give immediate feedback to the user so there is some
> certainty that the computer has actually received a request and processed
> it.  Typically this is done by making buttons appear to depress under the
> mouse and making characters appear immediately they are typed.  In the
case
> of something "hidden" like the evaluation of a piece of code I think that
> the deselection provides good feedback.

Yes, I agree in general. However in this particular case there are issues.

1. When evaluating several lines that the user has manually selected, and
this is then deselected, it is undoing some of the users work, that has to
be redone. While this most of the time is ok as the evaluation has to be
done only once anyway, for multiple invocations it is a nuisance to select
the rows again and again. (In my case I set up 2 simulations with a couple
of ws-lines and redisplay them both repeatedly. The data under investigation
changes on each evaluation).

2. There is already feedback via the hourglass mouse cursor display.

3. If feedback in the ws, maybe a nondestructive way is possible, e.g.
special selection color or animated evaluate logo?

Ciao

...Jochen

"Jochen Riekhof" <[hidden email]> wrote in message
news:3e39116d$[hidden email]...
> > I think one reason that it is useful is that it acts as feedback to show
> > that your evaluation has really been actioned.  One of the first
> principles
> > of GUI design is to give immediate feedback to the user so there is some
> > certainty that the computer has actually received a request and
processed
> > it.  Typically this is done by making buttons appear to depress under
the
> > mouse and making characters appear immediately they are typed.  In the
> case
> > of something "hidden" like the evaluation of a piece of code I think
that investigation
> changes on each evaluation).

You might want to consider putting that into a method, rather than workspace
code. Perhaps, if it is for testing purposes, you might want to consider
using SUnit.

>
> 2. There is already feedback via the hourglass mouse cursor display.

A great many evaluations operate so quickly that there is no time to display
the wait cursor.
>
> 3. If feedback in the ws, maybe a nondestructive way is possible, e.g.
> special selection color or animated evaluate logo?

The problem with that would be that it would have to persist after the
evaluation in order that short running evals had a visible effect. Also what
would it do on subsequent evaluations - cycle through all the colours of the
rainbow? :-)

Joking aside there is also the consideration of consistency of behaviour
with Display-It. The latter clears the selection in order to display the
result selected. This is very useful in that it allows one to delete the
result with a single keystroke.

Regards

Blair

> You might want to consider putting that into a method, rather than
workspace
> code. Perhaps, if it is for testing purposes, you might want to consider
> using SUnit.

Shure, but it is just not as convenient as simply leaving my selection
untouched. SUnit is not usable for my problem, as I repeat the evaluation to
find clues about whats going on visually. I could also wrap the stuff with a
block closure, assign it to a ws-var and evaluate that, but still the above
point remains, it is just not as convenient. After all this is MY workspace,
my daily used tool to work with.

I admit that I often use Smalltalk in general and Dolphin in particular very
much like a playground,  evaluate ws-quickhacked code over and over, blast
graphics directly to the desktop canvas etc. This is ;-) different than
working e.g. in my Java environment, but that's a lot of why smalltalk is so
much more fun and creative.

> > 2. There is already feedback via the hourglass mouse cursor display.
>
> A great many evaluations operate so quickly that there is no time to
display
> the wait cursor.

Well this holds true for the selection and then deselection in the ws as
well, (when utilizing the great feature to be able to evaluate the entire
line the cursor is in when nothing is selected) :-).

> > 3. If feedback in the ws, maybe a nondestructive way is possible, e.g.
> > special selection color or animated evaluate logo?
>
> The problem with that would be that it would have to persist after the
> evaluation in order that short running evals had a visible effect. Also
what
> would it do on subsequent evaluations - cycle through all the colours of
the
> rainbow? :-)

Hum, I though of something like just setting the selection to red during
evaluation. on short running evals with no selection you have almost no
feedback now as well.

> Joking aside there is also the consideration of consistency of behaviour
> with Display-It. The latter clears the selection in order to display the
> result selected. This is very useful in that it allows one to delete the
> result with a single keystroke.

Oh, this has to remain untouched! Evaluate is a completely distinct beast
from evaluate. In the latter I deliberately choose not to display some
result. However, regarding display,  see below...

I don't want to dig too deep into this - after all I can patch the image
however I want ;-). Anyway, since I introduced Ians and my changes, I am a
lot happier and never missed the old behaviour so far. I can imagine that
others could feel the same.
Maybe you change your ws-code for a day and see if you like it.

I looked at Squeak to see what they do (my old favorite playground before I
tried dolphin :-) , they are selecting the row on evaluate and just keep the
selection (just like Ians patch). Moreover I noticed: on printing (display
it) they first select the row, then the result. An undo not only deletes the
result but also reselects the old selection, so that I can reevaluate with
two commandkeys as often as I want even  when displaying. Isn't this a nice
behaviour? Maybe for beginners it is a little less intuitive as reevalation
has no feedback, but for advanced users it's behaviour  is IMO hardly
improvable. I am not shure, but I believe Squeak uses the identical
behaviour as the original ST-80 except for autoselecting the current line
(didn't see an ST-80 system since 1989).

Otherwise, my original request was only if there is an OPTION to enable the
non-deselecting behaviour somewhere. Maybe this is the best way?

Ciao

...Jochen