computers too fast these days?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 19.08.2013 um 20:53 schrieb Chris Muller <[hidden email]>:

I agree with Bob.  100ms only "slows the UI" down to 10 fps for one
"frame."  By holding everything else static for that one frame, it
reinforces the purpose of flash which is to draw the users attention
to that one particular morph.

what if the morph is behind another one? Then the UI goes
halt for no apparent reason.


In an extremely busy-animated UI, flash might otherwise not fulfill
this goal as effectively.

Animation in morphic is normally handled by implementing #step and
#stepTime, not alarms.  But #flash is not animation, it's like #beep.
It's a user poke, not program output.

Which should be non-blocking nonetheless.
When my terminal on OSX flashes (visual bell, the exact same
concept), it does not do it in a blocking fashion, all
other UI stuff continues to work.
  Again, I am strongly opposed agains any change that introduces
blocking into the UI. It just does not belong there. Modal dialogs
that also draw the attention to the current screen activity also
do not block the UI. The same way, a #beep should not block
the UI.
  Think of a typical Game loop that adjusts its calculation based
on the measured fps (for example by adjusting stepping time). This
would introduce unwanted jumps in that game loop just because some
morph somewhere flashed.

 I agree that a #flash like a #beep should be always noticeable[1]
but I think a Delay for: whatevernumber is the wrong way.

 I just tested Bobs fix and then did the following:
Open a browser, focus the Protocol pane, start typing like crazy
(say 50 character in very short time). The effect was that my UI
was blocked for more than thee (3) seconds. This should really
not happen.

Best
        -Tobias


[1] side note: there should be a preference to turn a #beep into a
    #flash automatically, akin to a terminal’s infamous visual bell,
    and probably vice versa.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)

iEYEARECAAYFAlIUyUYACgkQcPVIrP6PLKsOCgCdFoODDTV0QuZDr+xesVResYeb
K7gAniOwZnUwUB26w0QEkJ9xlSjT9wWV
=5Nkq
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 21.08.2013 um 16:05 schrieb Tobias Pape <[hidden email]>:
Am 19.08.2013 um 20:53 schrieb Chris Muller <[hidden email]>:
[…]
  Think of a typical Game loop that adjusts its calculation based

would introduce unwanted jumps in that game loop just because some
morph somewhere flashed.

I agree that a #flash like a #beep should be always noticeable[1]
but I think a Delay for: whatevernumber is the wrong way.

I just tested Bobs fix and then did the following:
Open a browser, focus the Protocol pane, start typing like crazy
(say 50 character in very short time). The effect was that my UI
was blocked for more than thee (3) seconds. This should really
not happen.

Interestingly, repeatedly flashing a UserDialogBoxMorph does
_not_ block the UI _although_ it is implemented using two
delays; you can drag the box around while it is flashing.
I think this is due to the modality implementation using
the doOneSubCycle (which I frankly do not yet understand)

Best
        -Tobias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)

iEYEARECAAYFAlIUy0IACgkQcPVIrP6PLKt4PQCggapRrM5yo4Brj+XVOO0/+jov
L6EAn39Zw1Fpu8PN3i83Lcc5U201oEMp
=QU+5
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 21.08.2013 um 15:30 schrieb John McKeon <[hidden email]>:

On Monday, Bob Arning wrote:

Whoops! That ifTrue: should be whileTrue:

John

I'll fix that.

Best
        -Tobias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)

iEYEARECAAYFAlIU0KYACgkQcPVIrP6PLKuifQCfZtYT5e7Nr7m++xUN/urjBvFc
1CAAoIRC1v1dC/Gt2Zcrj8H4l7fGfIjk
=71U+
-----END PGP SIGNATURE-----

On 8/21/13 10:14 AM, Tobias Pape wrote: I'm not sure how timing-critical games relate to the current users of
#flash. I can't really get my head around playing such a game *while*
typing 50 characters really fast in a browser pane. The delay,
introduced in direct response to user input, is probably a good bit less
that that for searching all methods with "foo" in their source or adding
an instance variable to a class with 50 subclasses. If you are
programming while gaming, both may suffer. Note that none of this
prevents someone from creating a gentler #flashEverSoDiscreetly for
special cases where you don't want to cause offense.
>
> I agree that a #flash like a #beep should be always noticeable[1]
> but I think a Delay for: whatevernumber is the wrong way.
>
> I just tested Bobs fix and then did the following:
> Open a browser, focus the Protocol pane, start typing like crazy
> (say 50 character in very short time). The effect was that my UI
> was blocked for more than thee (3) seconds. This should really
> not happen.
One thing that helps is if senders of #flash like this one also flushed
any pending input events. If you are really that fast a typist and do

     <cmd-f>foo<return>bar

and "foo" is not found, then "bar" gets entered at the previous
selection, not replacing "foo" as desired. #flash means the last thing
you did didn't work and there's a strong possibility any stuff you
already types in is wrong.
>
> Interestingly, repeatedly flashing a UserDialogBoxMorph does
> _not_ block the UI _although_ it is implemented using two
> delays; you can drag the box around while it is flashing.
> I think this is due to the modality implementation using
> the doOneSubCycle (which I frankly do not yet understand)
It's just a recursion into event processing. It allows the world to
display, but also user input to be processed and #step processing. In my
#flash, try using #doOneCycleNow in place of #displayWorldSafely. You
may be a bit happier with the results.

Cheers,
Bob

Tobias, when we use reasons like "should" and "does not belong", I
understand you're saying how it feels in your guts, but unfortunately
it does not provide a basis for us to engage in logical debate and
decision making.

You raise a good point about it possibly being covered by another
Morph.  No answer for that other than the user could instruct the
morph they're about to flash (its parent-most Morph under the World)
to comeToFront first..

I think most of us agree we don't normally want to "block" the UI and
doing so certainly goes against Morphic principles.  But this is just
#flash so -- 1) the blockage is for one "frame", what are we going to
miss?  2) the blockage reinforces it's function -- because what if
there are 100 Morphs already on the screen (perhaps as part of the
Game loop you mentioned), which all have a flashing-effect as part of
their stepping.  It would be difficult to see the 101st one I'm
flashing deliberately.  So, one could argue, blocking the UI pausing
briefly is actually *by design* for the flash function.  Finally, 3) a
Delay is simply TSTTCPW.  Sure we could introduce a complicated
stepping / alarms, whatever, but at the end of the day, what have we
gained by that?

Right now #flash doesn't really work at all so our choices are to 1)
leave it broken, 2) put in a brief Delay, or 3) something else.
Keeping in mind, until someone DOES the "something else" it's
essentially the same as (1).


On Wed, Aug 21, 2013 at 9:05 AM, Tobias Pape <[hidden email]> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 21.08.2013 um 17:03 schrieb Bob Arning <[hidden email]>:


On 8/21/13 10:14 AM, Tobias Pape wrote:
- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 21.08.2013 um 16:05 schrieb Tobias Pape <[hidden email]>:
Am 19.08.2013 um 20:53 schrieb Chris Muller <[hidden email]>:
[…]
  Think of a typical Game loop that adjusts its calculation based

would introduce unwanted jumps in that game loop just because some
morph somewhere flashed.
I'm not sure how timing-critical games relate to the current users of #flash. I can't really get my head around playing such a game *while* typing 50 characters really fast in a browser pane. The delay, introduced in direct response to user input, is probably a good bit less that that for searching all methods with "foo" in their source or adding an instance variable to a class with 50 subclasses. If you are programming while gaming, both may suffer. Note that none of this prevents someone from creating a gentler #flashEverSoDiscreetly for special cases where you don't want to cause offense.

Well it was just being an example :)
But to give a typical scenario: you have some sort of
list morph that supports filtering (nearly every PluggableListMorph…)
let it be a browser pane or whatever; you play your high-performance
game (lets say you have to hit some keys as fast as you can), and
accidentally lose input focus to the list while still hitting the keys.
Thats how I imagine such things come into being.


I agree that a #flash like a #beep should be always noticeable[1]
but I think a Delay for: whatevernumber is the wrong way.

I just tested Bobs fix and then did the following:
Open a browser, focus the Protocol pane, start typing like crazy
(say 50 character in very short time). The effect was that my UI
was blocked for more than thee (3) seconds. This should really
not happen.
One thing that helps is if senders of #flash like this one also flushed any pending input events. If you are really that fast a typist and do

   <cmd-f>foo<return>bar

and "foo" is not found, then "bar" gets entered at the previous selection, not replacing "foo" as desired. #flash means the last thing you did didn't work and there's a strong possibility any stuff you already types in is wrong.

Interestingly, repeatedly flashing a UserDialogBoxMorph does
_not_ block the UI _although_ it is implemented using two
delays; you can drag the box around while it is flashing.
I think this is due to the modality implementation using
the doOneSubCycle (which I frankly do not yet understand)
It's just a recursion into event processing. It allows the world to display, but also user input to be processed and #step processing. In my #flash, try using #doOneCycleNow in place of #displayWorldSafely. You may be a bit happier with the results.

Probably.
What if we forked the delay?

Best
        -Tobias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)

iEYEARECAAYFAlIV17sACgkQcPVIrP6PLKsBoACgmixTPZX8AryKDxST4AN0OO41
7MwAnjo8LtGboe9NytE/4zmC0xYZYxIY
=r6jV
-----END PGP SIGNATURE-----

On 2013-08-22, at 11:19, Tobias Pape <[hidden email]> wrote:

> What if we forked the delay?


Then you need to resync with the UI thread using addDeferredUIMessage:. Much simpler to use a future/alarm directly.

FWIW, I'm normally using #flashBounds to find any morph on the screen, which also works when it's hidden:

        World allMorphs atRandom flashBounds

Yes, this is low-level and blocking, but I only use it interactively anyway.

- Bert -