The Inbox: Morphic-kfr.731.mcz
Locked
 
|
A new version of Morphic was added to project The Inbox:
http://source.squeak.org/inbox/Morphic-kfr.731.mcz ==================== Summary ==================== Name: Morphic-kfr.731 Author: kfr Time: 3 July 2014, 2:28:57.179 pm UUID: 05ec5d84-8101-f94b-847f-d4e467ddeead Ancestors: Morphic-kfr.730 Small fix for keyboard focus. Double flash for morph implementation =============== Diff against Morphic-cmm.729 =============== Item was changed: ----- Method: AlternatePluggableListMorphOfMany>>mouseUp: (in category 'event handling') ----- mouseUp: event + + event hand newKeyboardFocus: self. + hasFocus := true. + ^self! - "Not needed. Overridden to do nothing."! Item was changed: ----- Method: Morph>>flash (in category 'macpal') ----- flash + "Flash me" | originalColor | originalColor := self color. + 1 + to: 2 + do: [:i | [self + color: (originalColor + ifNil: [Color black] + ifNotNil: [((originalColor alpha: 1) + adjustSaturation: 0.8 + brightness: 0) negated])] + ensure: [self world + ifNotNil: [:w | w displayWorldSafely]. + (Delay forMilliseconds: 50) wait. + [self color: originalColor] + ensure: [self world + ifNotNil: [:w | w displayWorldSafely]. + (Delay forMilliseconds: 50) wait]]]! - [ self color: - (originalColor - ifNil: [ Color black ] - ifNotNil: [( (originalColor alpha: 1) adjustSaturation: 0.8 brightness: 0) negated ]) ] - ensure: - [ self world ifNotNil: [ : w | w displayWorldSafely ]. - self color: originalColor ]! Item was changed: ----- Method: TextMorphForEditView>>mouseDown: (in category 'event handling') ----- mouseDown: event event yellowButtonPressed ifTrue: [ + (self editor yellowButtonDown: event) ifTrue:[^self]. - (editor yellowButtonDown: event) ifTrue:[^self]. ^ editView yellowButtonActivity: event shiftPressed]. ^ super mouseDown: event ! |
Re: The Inbox: Morphic-kfr.731.mcz
|
|
I think forcing a double-blink for every possible use-case for #flash won't work. Plus, an arbitrary 50ms delay will not let anyone be happy because some want absolutely no blockage while others wanted more than 50ms.. #flashStyle or #flashIntensity preference would be one way to address those differences. On Thu, Jul 3, 2014 at 7:29 AM, <[hidden email]> wrote: A new version of Morphic was added to project The Inbox: |
Re: The Inbox: Morphic-kfr.731.mcz
|
|
On Mon, Jul 07, 2014 at 07:42:28PM -0500, Chris Muller wrote:
> I think forcing a double-blink for every possible use-case for #flash won't > work. Plus, an arbitrary 50ms delay will not let anyone be happy because > some want absolutely no blockage while others wanted more than 50ms.. OK, I'll bite. What exactly was wrong with the original implementation of Morph>>flash dated 10/10/1999 by Scott Wallace? It seems to do a very nice job of flashing the morph, and it plays nicely with the "Reuse Windows" preference. What's not to like? The cmm 8/22/2013 version does not flash nicely, and the kfr 7/3/2014 version uses delays, which may be problematic. The sw 10/10/1999 version works well and does not have either problem. How about just using the one the works? > > #flashStyle or #flashIntensity preference would be one way to address those > differences. > We have enough obscure preferences that have entered the system for reasons that nobody can even remember. Let's not add another. Dave > > > On Thu, Jul 3, 2014 at 7:29 AM, <[hidden email]> wrote: > > > A new version of Morphic was added to project The Inbox: > > http://source.squeak.org/inbox/Morphic-kfr.731.mcz > > > > ==================== Summary ==================== > > > > Name: Morphic-kfr.731 > > Author: kfr > > Time: 3 July 2014, 2:28:57.179 pm > > UUID: 05ec5d84-8101-f94b-847f-d4e467ddeead > > Ancestors: Morphic-kfr.730 > > > > Small fix for keyboard focus. > > Double flash for morph implementation > > > > =============== Diff against Morphic-cmm.729 =============== > > > > Item was changed: > > ----- Method: AlternatePluggableListMorphOfMany>>mouseUp: (in category > > 'event handling') ----- > > mouseUp: event > > + > > + event hand newKeyboardFocus: self. > > + hasFocus := true. > > + ^self! > > - "Not needed. Overridden to do nothing."! > > > > Item was changed: > > ----- Method: Morph>>flash (in category 'macpal') ----- > > flash > > + "Flash me" > > | originalColor | > > originalColor := self color. > > + 1 > > + to: 2 > > + do: [:i | [self > > + color: (originalColor > > + ifNil: [Color black] > > + ifNotNil: [((originalColor > > alpha: 1) > > + > > adjustSaturation: 0.8 > > + > > brightness: 0) negated])] > > + ensure: [self world > > + ifNotNil: [:w | w > > displayWorldSafely]. > > + (Delay forMilliseconds: 50) wait. > > + [self color: originalColor] > > + ensure: [self world > > + ifNotNil: > > [:w | w displayWorldSafely]. > > + (Delay > > forMilliseconds: 50) wait]]]! > > - [ self color: > > - (originalColor > > - ifNil: [ Color black ] > > - ifNotNil: [( (originalColor alpha: 1) > > adjustSaturation: 0.8 brightness: 0) negated ]) ] > > - ensure: > > - [ self world ifNotNil: [ : w | w > > displayWorldSafely ]. > > - self color: originalColor ]! > > > > Item was changed: > > ----- Method: TextMorphForEditView>>mouseDown: (in category 'event > > handling') ----- > > mouseDown: event > > > > event yellowButtonPressed ifTrue: [ > > + (self editor yellowButtonDown: event) ifTrue:[^self]. > > - (editor yellowButtonDown: event) ifTrue:[^self]. > > ^ editView yellowButtonActivity: event shiftPressed]. > > ^ super mouseDown: event > > ! > > > > > > > |
Re: The Inbox: Morphic-kfr.731.mcz
|
I remember a discussion about #flash somewhere on this mailing list a year ago or two maybe... Blocking the GUI process explicitely is evil. It slows down things unexpectedly (and not debugger-friendly) if triggered programmatically by side-effects.
Best, Marcel |
Re: The Inbox: Morphic-kfr.731.mcz
|
|
Re: The Inbox: Morphic-kfr.731.mcz
|
|
On Tue, Jul 08, 2014 at 03:58:59AM -0700, Marcel Taeumel wrote:
> Here we go: > http://forum.world.st/computers-too-fast-these-days-td4704067.html > Thanks Marcel, I understand now. I should have remembered that thread! Dave |
Re: The Inbox: Morphic-kfr.731.mcz
|
|
In reply to this post by Chris Muller-3
Hi Chris,
|
Re: The Inbox: Morphic-kfr.731.mcz
|
|
In reply to this post by David T. Lewis
On Mon, Jul 7, 2014 at 10:09 PM, David T. Lewis <[hidden email]> wrote:
> On Mon, Jul 07, 2014 at 07:42:28PM -0500, Chris Muller wrote: >> I think forcing a double-blink for every possible use-case for #flash won't >> work. Plus, an arbitrary 50ms delay will not let anyone be happy because >> some want absolutely no blockage while others wanted more than 50ms.. > > OK, I'll bite. What exactly was wrong with the original implementation of > Morph>>flash dated 10/10/1999 by Scott Wallace? Dave, could you possibly try this out to find the answer to your question? - In a trunk image, add this repository to the Morphic package: MCHttpRepository location: 'http://box4.squeak.org:8888/trunk' user: 'squeak' password: 'squeak' - Revert Morph>>#flash to the one you're interested in knowing about -- (cmm 10/6/2012 15:54) which the one that is just after Scott Wallace's 1999 version. - In a Browser or Hierarchy browser, now select that Morph>>#flash, then right click on it. Be patient, it might take a second or two for the menu to appear (to properly determine whether those options should be enabled in the menu). - Select "browse mc origin". Wait up to 10 seconds (hey, it's a lot faster than doing it manually!). The MCVersion inspector appears documenting all changes that went in along with that change of #flash. The answer to your question is the 2nd bullet line. > It seems to do a very nice > job of flashing the morph, and it plays nicely with the "Reuse Windows" preference. > What's not to like? Please see this note from Bob Arning which succinctly describes what's not to like about the original: http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-August/172823.html > The cmm 8/22/2013 version does not flash nicely, and the kfr 7/3/2014 version > uses delays, which may be problematic. The sw 10/10/1999 version works well and > does not have either problem. How about just using the one the works? >> >> #flashStyle or #flashIntensity preference would be one way to address those >> differences. >> > > We have enough obscure preferences that have entered the system for reasons > that nobody can even remember. Let's not add another. So, no more preferences at all then? Ever? Look, I know what you're trying to say about Preferences, and I think many of them could be removed, but its clear that we all have different interpretations about what #flash is supposed to be for; a low-level notifier or a high-level notifier that can integrate into application-UI's without blocking the UI. |
Re: The Inbox: Morphic-kfr.731.mcz
|
|
In reply to this post by Eliot Miranda-2
Hi,
> I think forcing a double-blink for every possible use-case for #flash won't > work. Plus, an arbitrary 50ms delay will not let anyone be happy because > some want absolutely no blockage while others wanted more than 50ms.. > > #flashStyle or #flashIntensity preference would be one way to address those > differences. > > > > It's a hack. It complicates without adding anything. Perceptually, a flash It's hackish, but as I said before, consumption is from one single method, so its NOT complicated at all. What it "adds" is the ability for each image to treat flash as a low-level or high-level notification (e.g., blocking or not). > needs to last something like a 1/10th if a second to be easily visible > Clearly a simple reverse won't work. Bert has explained that using alarms, > rather than delays, can implement flash without blocking. Surely we can do > the right thing here and implement flash having a consistent duration and > not blocking? Someone already proposed an alarms based solution in the original thread, but it was disapproved by mulitple parties as "way too much" (see the thread). Maybe everyone has changed their minds, which is fine, but the TSTTCPW approach I'm proposing lets us play and understand how we want to use #flash until then, WITHOUT a complicated, irreversible implementation like alarms. It's totally reversible, buys us time to think about it in real-world contexts. Besides that, I'm kind of stunned that you would believe one-flash-fits-all. I never needed ANY flash for Reuse Windows, but I could tolerate a single flash when a window was already open. A double flash though? That could get annoying to see that every time a window is topped. So, I think there should be a preference even if we go with the Alarms-based solution.. |
Re: The Inbox: Morphic-kfr.731.mcz
|
|
On 08-07-2014, at 9:29 AM, Chris Muller <[hidden email]> wrote: > Besides that, I'm kind of stunned that you would believe > one-flash-fits-all. I never needed ANY flash for Reuse Windows, but I > could tolerate a single flash when a window was already open. A > double flash though? That could get annoying to see that every time a > window is topped. I don’t think a flash is suitable at all for the usage originally discussed. It’s transitory (too much so when implemented simply, as we’ve seen) and minimally informative. Adding something with tab-like functionality would be much more useful as a way to improve stacked-up multi-windows. It’s an idiom already understood widely, with easily intuitable purpose and behaviour. A simple flash has some value in a debugging scenario - it’s not a bad way to show an area marked for redrawing, for example, when trying to make sense of why something isn’t redrawing properly. And in that case a Delay is a perfectly tolerable way to make it last long enough to see on a fast machine. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: IBLU: Ignore Basic Laws of Universe |
Re: The Inbox: Morphic-kfr.731.mcz
|
|
In reply to this post by Chris Muller-4
Chris,
Thanks, and yes I'll definitely try the version browsing when I get home tonight. Marcel Taeumel pointed me to our earlier discussions on this topic, which I had entirely forgotten. Sorry for the confusion. Dave > On Mon, Jul 7, 2014 at 10:09 PM, David T. Lewis <[hidden email]> > wrote: >> On Mon, Jul 07, 2014 at 07:42:28PM -0500, Chris Muller wrote: >>> I think forcing a double-blink for every possible use-case for #flash >>> won't >>> work. Plus, an arbitrary 50ms delay will not let anyone be happy >>> because >>> some want absolutely no blockage while others wanted more than 50ms.. >> >> OK, I'll bite. What exactly was wrong with the original implementation >> of >> Morph>>flash dated 10/10/1999 by Scott Wallace? > > Dave, could you possibly try this out to find the answer to your question? > > - In a trunk image, add this repository to the Morphic package: > > MCHttpRepository > location: 'http://box4.squeak.org:8888/trunk' > user: 'squeak' > password: 'squeak' > > - Revert Morph>>#flash to the one you're interested in knowing about > -- (cmm 10/6/2012 15:54) which the one that is just after Scott > Wallace's 1999 version. > - In a Browser or Hierarchy browser, now select that Morph>>#flash, > then right click on it. Be patient, it might take a second or two for > the menu to appear (to properly determine whether those options should > be enabled in the menu). > - Select "browse mc origin". Wait up to 10 seconds (hey, it's a lot > faster than doing it manually!). The MCVersion inspector appears > documenting all changes that went in along with that change of #flash. > > The answer to your question is the 2nd bullet line. > >> It seems to do a very nice >> job of flashing the morph, and it plays nicely with the "Reuse Windows" >> preference. >> What's not to like? > > Please see this note from Bob Arning which succinctly describes what's > not to like about the original: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-August/172823.html > >> The cmm 8/22/2013 version does not flash nicely, and the kfr 7/3/2014 >> version >> uses delays, which may be problematic. The sw 10/10/1999 version works >> well and >> does not have either problem. How about just using the one the works? >>> >>> #flashStyle or #flashIntensity preference would be one way to address >>> those >>> differences. >>> >> >> We have enough obscure preferences that have entered the system for >> reasons >> that nobody can even remember. Let's not add another. > > So, no more preferences at all then? Ever? Look, I know what you're > trying to say about Preferences, and I think many of them could be > removed, but its clear that we all have different interpretations > about what #flash is supposed to be for; a low-level notifier or a > high-level notifier that can integrate into application-UI's without > blocking the UI. > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |