-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 21.08.2013 um 17:03 schrieb Bob Arning arning315@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@gmx.de: Am 19.08.2013 um 20:53 schrieb Chris Muller asqueaker@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