computers too fast these days?
Locked
12
12
 
|
I've often wondered why, when I search for some string that isn't
there, I see the text morph flash sometimes, but not always. Here's
a fix.
Cheers, Bob 'From Squeak4.4 of 1 March 2013 [latest update: #12489] on 18 August 2013 at 11:49:45 am'! !Morph methodsFor: 'macpal' stamp: 'raa 8/18/2013 06:44'! flash | originalColor | originalColor := self color. [ self color: (originalColor ifNil: [ Color black ] ifNotNil: [ (originalColor alpha: 1) negated ]) ] ensure: [ self world ifNotNil: [ : w | w displayWorldSafely. (Delay forMilliseconds: 100) wait ]. self color: originalColor ]! ! |
Re: computers too fast these days?
|
|
I see you added the 100ms delay. I'll put that into trunk.
Are you interested in registering at source.squeak.org? You should be in the core-dev group so you can commit to trunk directly. On Sun, Aug 18, 2013 at 10:52 AM, Bob Arning <[hidden email]> wrote: > I've often wondered why, when I search for some string that isn't there, I > see the text morph flash sometimes, but not always. Here's a fix. > > Cheers, > Bob > > 'From Squeak4.4 of 1 March 2013 [latest update: #12489] on 18 August 2013 at > 11:49:45 am'! > > !Morph methodsFor: 'macpal' stamp: 'raa 8/18/2013 06:44'! > flash > | originalColor | > originalColor := self color. > [ self color: > (originalColor > ifNil: [ Color black ] > ifNotNil: [ (originalColor alpha: 1) negated ]) ] > ensure: > [ self world ifNotNil: [ : w | w displayWorldSafely. (Delay > forMilliseconds: 100) wait ]. > self color: originalColor ]! ! > > > > |
Re: computers too fast these days?
|
In reply to this post by Bob Arning-2
Well, I don't think you should block the event loop with this kind of feedback. 100 milliseconds are quite many... Maybe just use Morphic Alarms:
flash self color in: [:c | self color: ((c ifNil: [Color white]) alpha: 1) negated. self addAlarm: #color: with: c after: 100]. Best, Marcel |
Re: computers too fast these days?
|
|
In reply to this post by Bob Arning-2
On Sun, 18 Aug 2013, Bob Arning wrote:
> I've often wondered why, when I search for some string that isn't there, I see the text morph flash sometimes, but not always. Here's a fix. > > Cheers, > Bob > > 'From Squeak4.4 of 1 March 2013 [latest update: #12489] on 18 August 2013 at 11:49:45 am'! > > !Morph methodsFor: 'macpal' stamp: 'raa 8/18/2013 06:44'! > flash > | originalColor | > originalColor := self color. > [ self color: > (originalColor > ifNil: [ Color black ] > ifNotNil: [ (originalColor alpha: 1) negated ]) ] > ensure: > [ self world ifNotNil: [ : w | w displayWorldSafely. (Delay forMilliseconds: 100) wait ]. Levente > self color: originalColor ]! ! > > > |
Re: computers too fast these days?
|
|
Yup, not the best idea. That's why I voted for the use of Morphic Alarms. :)
Best, Marcel |
Re: computers too fast these days?
|
|
The trouble with using an alarm is if #flash gets called again before
the alarm fires, it will think its negated color is its normal color and add yet another alarm to reverse it again, leaving it in the flashed color. Could you (or Levente) elaborate by why it might not be a good idea? I think describing use-cases really helps understand context. For me, I use flash as a debugging tool, I open an inspector on a Morph and type "self flash" and press and hold Command+d to DoIt. I don't really need the Delay since the key-repeat takes care of it.. On Sun, Aug 18, 2013 at 3:32 PM, Marcel Taeumel <[hidden email]> wrote: > Yup, not the best idea. That's why I voted for the use of Morphic Alarms. :) > > Best, > Marcel > > > > -- > View this message in context: http://forum.world.st/computers-too-fast-these-days-tp4704067p4704077.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > |
Re: computers too fast these days?
|
|
On Sun, 18 Aug 2013, Chris Muller wrote:
> The trouble with using an alarm is if #flash gets called again before > the alarm fires, it will think its negated color is its normal color > and add yet another alarm to reverse it again, leaving it in the > flashed color. > > Could you (or Levente) elaborate by why it might not be a good idea? IIUC if you flash multiple Morphs, the delays will stack. So flashing 10 morphs will cause a second delay. Levente > > I think describing use-cases really helps understand context. For me, > I use flash as a debugging tool, I open an inspector on a Morph and > type "self flash" and press and hold Command+d to DoIt. I don't > really need the Delay since the key-repeat takes care of it.. > > > > On Sun, Aug 18, 2013 at 3:32 PM, Marcel Taeumel > <[hidden email]> wrote: >> Yup, not the best idea. That's why I voted for the use of Morphic Alarms. :) >> >> Best, >> Marcel >> >> >> >> -- >> View this message in context: http://forum.world.st/computers-too-fast-these-days-tp4704067p4704077.html >> Sent from the Squeak - Dev mailing list archive at Nabble.com. >> > > |
Re: computers too fast these days?
|
|
I'm not clear on who wants to flash 10 morphs,
but if you do this
m _ (1 to: 10) collect: [ :i | Morph new position: (i@i*75); openInWorld] then try this: m do: [ :e | e flash] The standard version of #flash *occasionally* causes a visible change in the first morph, but I never notice a change in any of the others. The 100 ms delay version makes all of the flashes clearly noticeable, in sequence. A 10 ms delay in #flash makes them mostly (but briefly) detectable. I suspect if you really want to flash 10 morphs, you may do well with a rather different approach. Cheers, Bob On 8/18/13 9:10 PM, Levente Uzonyi
wrote:
On Sun, 18 Aug 2013, Chris Muller wrote: |
Re: computers too fast these days?
|
|
In reply to this post by Chris Muller-3
Hi! :)
One point against blocking the event loop: You never know who will call #flash as it is public API. It is not guaranteed that the flashing morph is "visible" at all and not occluded by some other morph. Then, strange short image freezes will be noticed. Best, Marcel |
Re: computers too fast these days?
|
|
In reply to this post by Bob Arning-2
Here a better version:
(self valueOfProperty: #colorBeforeFlashing ifAbsent: [self color]) in: [:c | self setProperty: #colorBeforeFlashing toValue: c. self color: ((c ifNil: [Color white]) alpha: 1) negated. ActiveWorld displayWorldSafely. self removeAlarm: #color:; removeAlarm: #removeProperty:. self addAlarm: #color: with: c after: 100; addAlarm: #removeProperty: with: #colorBeforeFlashing after: 100]. I am not exactly sure, why an explicit call to the render loop is needed... But this way, it works without blocking the event loop. This "ActiveWorld displayWorldSafely" is still annoying... Best, Marcel |
Re: computers too fast these days?
|
|
This is just waaay too much.
- It makes little sense to talk about a "public API" in Squeak. All methods are visible and executable from anywhere. To think that some subset of all methods have been vetted and will never do anything unpleasant is not supported by the facts. - If you look at the senders of flash in the image, it pretty much all about , "I just asked a tool to do something and it could not. Oops!" No need for anything fancy here - just DTSTTCPW. - The introduction of alarms made me nervous. I understand delays, but alarms are a gray area. How do they work? Will they do what I think they will? In this case, they do *not*. If we go back to my example: m _ (1 to: 10) collect: [ :i | Morph new position: (i@i*75); openInWorld] m do: [ :e | e flash] Using the alarming version of #flash, we see the first morph flash ever so briefly. Each successive morph flashes for a longer time, until the last one stays inverted for 600 ms. Huh! If you look at: WorldState>>triggerAlarmsBefore:, you see the claim: "Trigger all pending alarms that are to be executed before nowTime." when, in fact, it triggers one at most: triggered := OrderedCollection new. self lockAlarmsDuring: [:pending | (pending isEmpty not and: [pending first scheduledTime < nowTime]) ifTrue: [triggered add: pending removeFirst]]. triggered do: [:alarm | alarm value: nowTime]. makes me want to Smalltalk destroyAllComments ;-) Cheers, Bob On 8/19/13 5:56 AM, Marcel Taeumel
wrote:
Hi! :) One point against blocking the event loop: You never know who will call #flash as it is public API. It is not guaranteed that the flashing morph is "visible" at all and not occluded by some other morph. Then, strange short image freezes will be noticed. On 8/19/13 6:07 AM, Marcel Taeumel
wrote:
|
Re: computers too fast these days?
|
|
On Mon, Aug 19, 2013 at 08:02:02AM -0400, Bob Arning wrote:
> This is just waaay too much. > +1 > - It makes little sense to talk about a "public API" in Squeak. All > methods are visible and executable from anywhere. To think that some > subset of all methods have been vetted and will never do anything > unpleasant is not supported by the facts. > > - If you look at the senders of flash in the image, it pretty much all > about , "I just asked a tool to do something and it could not. Oops!" No > need for anything fancy here - just DTSTTCPW. > > - The introduction of alarms made me nervous. I understand delays, but > alarms are a gray area. How do they work? Will they do what I think they > will? In this case, they do *not*. If we go back to my example: > > m _ (1 to: 10) collect: [ :i | Morph new position: (i@i*75); openInWorld] > > m do: [ :e | e flash] > > Using the alarming version of #flash, we see the first morph flash ever > so briefly. Each successive morph flashes for a longer time, until the > last one stays inverted for 600 ms. Huh! > > If you look at: WorldState>>triggerAlarmsBefore:, you see the claim: > > "Trigger all pending alarms that are to be executed before nowTime." > > when, in fact, it triggers one at most: > > triggered := OrderedCollection new. > self lockAlarmsDuring: [:pending | > (pending isEmpty not and: [pending first scheduledTime < nowTime]) > ifTrue: [triggered add: pending removeFirst]]. > triggered do: [:alarm | alarm value: nowTime]. > > makes me want to > > Smalltalk destroyAllComments ;-) > > Cheers, > Bob Class MorphicAlarm does not even *have* a comment. MorphicAlarmQueue has a comment, but the comment only describes its internal implementation, nothing about why it exists or what it is supposed to do. If Morphic alarms are a good thing, then perhaps someone could (please?) take the time to provide some class comments with a clear explanation of what they are and how they are supposed to work. Dave > > On 8/19/13 5:56 AM, Marcel Taeumel wrote: > >Hi! :) > > > >One point against blocking the event loop: You never know who will call > >#flash as it is public API. It is not guaranteed that the flashing morph is > >"visible" at all and not occluded by some other morph. Then, strange short > >image freezes will be noticed. > On 8/19/13 6:07 AM, Marcel Taeumel wrote: > >Here a better version: > > > > (self valueOfProperty: #colorBeforeFlashing ifAbsent: [self color]) > > in: [:c | > > self setProperty: #colorBeforeFlashing toValue: c. > > self color: ((c ifNil: [Color white]) alpha: 1) negated. > > ActiveWorld displayWorldSafely. > > > > self > > removeAlarm: #color:; > > removeAlarm: #removeProperty:. > > self > > addAlarm: #color: with: c after: 100; > > addAlarm: #removeProperty: with: #colorBeforeFlashing after: 100]. > > > >I am not exactly sure, why an explicit call to the render loop is needed... > >But this way, it works without blocking the event loop. This "ActiveWorld > >displayWorldSafely" is still annoying... > > > >Best, > >Marcel > > > > > > > >-- > >View this message in context: > >http://forum.world.st/computers-too-fast-these-days-tp4704067p4704117.html > >Sent from the Squeak - Dev mailing list archive at Nabble.com. > > > > > > |
Re: computers too fast these days?
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Am 19.08.2013 um 14:21 schrieb "David T. Lewis" <[hidden email]>: On Mon, Aug 19, 2013 at 08:02:02AM -0400, Bob Arning wrote: This is just waaay too much. +1 - -1 Out of principle, I am against any change that adds Delays to the ui. I consider that plain wrong (<-personal opinion). IMHO, flashing is an animation that should not use plain Delays directly. While alarms may be insufficiently documented (as is the vast majority of Morphic…), I think it is the proper level of abstraction. Best -Tobias -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) iEYEARECAAYFAlISEkUACgkQcPVIrP6PLKvmLgCdGzgUU3KJPh1rJ7saeLBwcjkK nTwAoIES9bHsMLIGLi+UyZN2a/floQ2A =eTJr -----END PGP SIGNATURE----- |
Re: computers too fast these days?
|
|
In reply to this post by Bob Arning-2
Seems to me there are two rather different usages here
a) an alert within the normal UI, to let you know something odd happened b) a diagnostic when debugging where you need a 'bigger' alert. For b) a 100mS simple delay is probably perfectly fine. I've done debugging where it would be really nice for there to be a good way of 'interrupting the delay' to get in to the problem process; an associated visual widget to click on or something. For a) a delay that holds up everything is not a good idea. Some form of alarm (like the morphicalarm is supposed to be) that keeps the UI moving is going to be least annoying. I think it's likely that there are better feedback concepts than simply flashing the morph. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim A paperless office has about as likely as a paperless bathroom. |
Re: computers too fast these days?
|
|
Think about where it's used in the image now. I
search for some text and it's not found. The screen flashes to let
me know. I can't think of *anything* I want the UI process to be
doing for the next 100ms while I wait for the photons to hit my
retina. I'm even thinking a bit longer delay might even be better.
Here are some experiments:
Make a morph. m _ Morph new openInWorld. Then try this, with different proposed #flash implementations. m flash; delete. Another experiment. How low can you set the delay and still reliably see red? Try this in a completely empty project. m color: Color red. World displayWorldSafely. (Delay forMilliseconds: 20) wait. m color: Color blue. World displayWorldSafely. I think the senders of #flash want it to be seen and I don't think the UI needs to do anything else while the message is being received by the user (the U in UI). Cheers, Bob On 8/19/13 12:58 PM, tim Rowledge
wrote:
Seems to me there are two rather different usages here a) an alert within the normal UI, to let you know something odd happened b) a diagnostic when debugging where you need a 'bigger' alert. For b) a 100mS simple delay is probably perfectly fine. I've done debugging where it would be really nice for there to be a good way of 'interrupting the delay' to get in to the problem process; an associated visual widget to click on or something. For a) a delay that holds up everything is not a good idea. Some form of alarm (like the morphicalarm is supposed to be) that keeps the UI moving is going to be least annoying. I think it's likely that there are better feedback concepts than simply flashing the morph. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim A paperless office has about as likely as a paperless bathroom. |
Re: computers too fast these days?
|
|
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. 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. On Mon, Aug 19, 2013 at 1:34 PM, Bob Arning <[hidden email]> wrote: > Think about where it's used in the image now. I search for some text and > it's not found. The screen flashes to let me know. I can't think of > *anything* I want the UI process to be doing for the next 100ms while I wait > for the photons to hit my retina. I'm even thinking a bit longer delay might > even be better. Here are some experiments: > > Make a morph. > > m _ Morph new openInWorld. > > Then try this, with different proposed #flash implementations. > > m flash; delete. > > Another experiment. How low can you set the delay and still reliably see > red? Try this in a completely empty project. > > m color: Color red. > World displayWorldSafely. > (Delay forMilliseconds: 20) wait. > m color: Color blue. > World displayWorldSafely. > > I think the senders of #flash want it to be seen and I don't think the UI > needs to do anything else while the message is being received by the user > (the U in UI). > > Cheers, > Bob > > On 8/19/13 12:58 PM, tim Rowledge wrote: > > Seems to me there are two rather different usages here > a) an alert within the normal UI, to let you know something odd happened > b) a diagnostic when debugging where you need a 'bigger' alert. > > For b) a 100mS simple delay is probably perfectly fine. I've done debugging > where it would be really nice for there to be a good way of 'interrupting > the delay' to get in to the problem process; an associated visual widget to > click on or something. > > For a) a delay that holds up everything is not a good idea. Some form of > alarm (like the morphicalarm is supposed to be) that keeps the UI moving is > going to be least annoying. I think it's likely that there are better > feedback concepts than simply flashing the morph. > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > A paperless office has about as likely as a paperless bathroom. > > > > > > > > |
Re: computers too fast these days?
|
|
What does the protocol "macpal", where #flash is located, mean?
Best, Marcel |
Re: computers too fast these days?
|
|
Well, google offered up this:
http://comments.gmane.org/gmane.comp.lang.smalltalk.squeak.general/55749 On 8/20/13 2:55 AM, Marcel Taeumel
wrote:
What does the protocol "macpal", where #flash is located, mean? Best, Marcel -- View this message in context: http://forum.world.st/computers-too-fast-these-days-tp4704067p4704256.html Sent from the Squeak - Dev mailing list archive at Nabble.com. |
Re: computers too fast these days?
|
|
In reply to this post by marcel.taeumel (old)
On 2013-08-20, at 08:55, Marcel Taeumel <[hidden email]> wrote: > What does the protocol "macpal", where #flash is located, mean? > > Best, > Marcel MacPal was one of the projects Alan Kay's group did at Apple. Others were Fabrik, Constructo, Playground, etc. - Bert - |
Re: computers too fast these days?
|
|
In reply to this post by Bob Arning-2
On Monday, Bob Arning wrote: > If you look at: WorldState>>triggerAlarmsBefore:, you see the claim: > > "Trigger all pending alarms that are to be executed before nowTime." > > when, in fact, it triggers one at most: > > triggered := OrderedCollection new. > self lockAlarmsDuring: [:pending | > (pending isEmpty not and: [pending first scheduledTime < nowTime]) > ifTrue: [triggered add: pending removeFirst]]. > triggered do: [:alarm | alarm value: nowTime]. > > makes me want to > > Smalltalk destroyAllComments ;-) > > Cheers, > Bob Whoops! That ifTrue: should be whileTrue: John > > On 8/19/13 5:56 AM, Marcel Taeumel wrote: > > Hi! :) > > One point against blocking the event loop: You never know who will call > #flash as it is public API. It is not guaranteed that the flashing morph is > "visible" at all and not occluded by some other morph. Then, strange short > image freezes will be noticed. > > On 8/19/13 6:07 AM, Marcel Taeumel wrote: > > Here a better version: > > (self valueOfProperty: #colorBeforeFlashing ifAbsent: [self color]) > in: [:c | > self setProperty: #colorBeforeFlashing toValue: c. > self color: ((c ifNil: [Color white]) alpha: 1) negated. > ActiveWorld displayWorldSafely. > > self > removeAlarm: #color:; > removeAlarm: #removeProperty:. > self > addAlarm: #color: with: c after: 100; > addAlarm: #removeProperty: with: #colorBeforeFlashing after: 100]. > > I am not exactly sure, why an explicit call to the render loop is needed... > But this way, it works without blocking the event loop. This "ActiveWorld > displayWorldSafely" is still annoying... > > Best, > Marcel > > > > -- > View this message in context: http://forum.world.st/computers-too-fast-these-days-tp4704067p4704117.html > Sent from the Squeak - Dev mailing list archive at Nabble.com. > > > > -- jmck.seasidehosting.st |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |