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 Das.Linux@gmx.de wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 19.08.2013 um 20:53 schrieb Chris Muller asqueaker@gmail.com:
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-----