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

Am 21.08.2013 um 17:03 schrieb Bob Arning <arning315 at comcast.net>:


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 <Das.Linux at gmx.de>:
Am 19.08.2013 um 20:53 schrieb Chris Muller <asqueaker at gmail.com>:
[…]
  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-----