Chris Muller uploaded a new version of Morphic to project The Inbox:
http://source.squeak.org/inbox/Morphic-cmm.728.mcz ==================== Summary ==================== Name: Morphic-cmm.728 Author: cmm Time: 30 June 2014, 12:23:11.962 pm UUID: 09c9997d-d2e2-4e71-9077-c768f21a0071 Ancestors: Morphic-dtl.727 - If the Reuse Windows preference is set, and an existing window on the desktop qualifies as reusable for a request, #flash it after activating it to ensure the user's attention will be guided to its on-screen location. =============== Diff against Morphic-dtl.727 =============== Item was changed: ----- Method: SystemWindow>>openInWorld:extent: (in category 'open/close') ----- openInWorld: aWorld extent: extent "This msg and its callees result in the window being activeOnlyOnTop" ^ self anyOpenWindowLikeMe ifEmpty: [ self position: (RealEstateAgent initialFrameFor: self initialExtent: extent world: aWorld) topLeft ; extent: extent. self openAsIsIn: aWorld ] ifNotEmptyDo: [ : windows | windows anyOne expand ; activate ; + postAcceptBrowseFor: self ; + flash ]! - postAcceptBrowseFor: self ]! |
TSTTCPW but I think we should revisit #flash again because sometimes it's so fast I barely saw it. I'll try this unconditional flash for a few days, make sure it won't become, ahem, annoying, before trunking it.. ;-)
On Mon, Jun 30, 2014 at 12:23 PM, <[hidden email]> wrote: Chris Muller uploaded a new version of Morphic to project The Inbox: |
On Mon, Jun 30, 2014 at 10:33 AM, Chris Muller <[hidden email]> wrote:
Then flash needs a 1/16 - 1/8 sec or thereabouts delay to make it visible right?
best, Eliot
|
On Mon, Jun 30, 2014 at 2:34 PM, Eliot Miranda <[hidden email]> wrote:
It's already been proposed, see thread:
We probably need to decide whether we want #flash to be a debugging tool or something any morph should be able to do in a way that properly integrates with the Morphic framework...
It seems we want it fairly often-enough as a IDE tool, I wouldn't be opposed to a small delay... |
On 30-06-2014, at 12:52 PM, Chris Muller <[hidden email]> wrote: > > We probably need to decide whether we want #flash to be a debugging tool or something any morph should be able to do in a way that properly integrates with the Morphic framework... > > It seems we want it fairly often-enough as a IDE tool, I wouldn't be opposed to a small delay... > > Seems pretty obvious to me - add a #slowFlashAlert method and leave the plain flash alone. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim "Bother" said Pooh, as his trigger finger tired. |
On 30.06.2014, at 21:54, tim Rowledge <[hidden email]> wrote: > > On 30-06-2014, at 12:52 PM, Chris Muller <[hidden email]> wrote: > >> >> We probably need to decide whether we want #flash to be a debugging tool or something any morph should be able to do in a way that properly integrates with the Morphic framework... >> >> It seems we want it fairly often-enough as a IDE tool, I wouldn't be opposed to a small delay... >> >> > Seems pretty obvious to me - add a #slowFlashAlert method and leave the plain flash alone. > > tim self confirm: 'foo' For a general (non-modal) version it would be nicer to use alarms instead of delays, but I like the "double blink" effect. - Bert - smime.p7s (5K) Download Attachment |
In reply to this post by timrowledge
On 30.06.2014, at 21:54, tim Rowledge <[hidden email]> wrote: > > On 30-06-2014, at 12:52 PM, Chris Muller <[hidden email]> wrote: > >> >> We probably need to decide whether we want #flash to be a debugging tool or something any morph should be able to do in a way that properly integrates with the Morphic framework... >> >> It seems we want it fairly often-enough as a IDE tool, I wouldn't be opposed to a small delay... >> >> > Seems pretty obvious to me - add a #slowFlashAlert method and leave the plain flash alone. > > tim self confirm: 'foo' For a general (non-modal) version it would be nicer to use alarms instead of delays, but I like the "double blink" effect. - Bert - smime.p7s (5K) Download Attachment |
In reply to this post by Bert Freudenberg
On Mon, Jun 30, 2014 at 4:04 PM, Bert Freudenberg <[hidden email]> wrote:
I think a separate method like #slowFlash may not satisfy those who are objecting to UI-blockage. For them, it's not about #flash blocking or not, it's about the entire UI ever blocking, or not. If we introduce UI-blocking methods in and start calling them from the Tools, that may be denying them their objection.
An alarms-based solution was proposed, but there was resistance to its complexity. It seems like we want to support a variety of flash types, maybe simply let each image configure its own preferred #flashIntensity? Like, #nonBlocking, #singleFrame, #doubleBlink, and #swizzleZoom.
Consumption of the preference would be from just one method, #flash, so, a simple implementation. |
In reply to this post by timrowledge
On Mon, Jun 30, 2014 at 12:54 PM, tim Rowledge <[hidden email]> wrote:
-1. flash is supposed to be visible and on today's machinery it often isn't. So it's broken. I second Bert's suggestion of using alarms for a non-blocking implementation.
best, Eliot
|
In reply to this post by Bert Freudenberg
On Mon, Jun 30, 2014 at 11:04:47PM +0200, Bert Freudenberg wrote:
> > On 30.06.2014, at 21:54, tim Rowledge <[hidden email]> wrote: > > > > > On 30-06-2014, at 12:52 PM, Chris Muller <[hidden email]> wrote: > > > >> > >> We probably need to decide whether we want #flash to be a debugging tool or something any morph should be able to do in a way that properly integrates with the Morphic framework... > >> > >> It seems we want it fairly often-enough as a IDE tool, I wouldn't be opposed to a small delay... > >> > >> > > Seems pretty obvious to me - add a #slowFlashAlert method and leave the plain flash alone. > > > > tim As a general rule, it is a good idea to try things like this in MVC and see if they still make sense. If it can only be made to work in a single UI framework, it might be a questionable feature. So #flash works with View and with Morph, but adding #slowFlashAlert might be too much clutter in the api. The "api" here is de-facto but it should still make sense if you think of it being dispatched through UIManager or Project. > > UserDialogBoxMorph has a special flash method that is nicely visible. Try this and click outside: > > self confirm: 'foo' > > For a general (non-modal) version it would be nicer to use alarms instead of delays, but I like the "double blink" effect. > +1 The "double blink" effect works very well in Morphic and gives very nice UI feedback. In MVC it does nothing, and that seems reasonable too. Dave p.s. Yes I know, the "Reuse Windows" preference does not work in MVC either. That would be a bug, but I'm not complaining ;-) Here I am referring to basic UI functions like "beep" and "flash" that might reasonably be expected to do something in a variety of UI frameworks. |
In reply to this post by Bert Freudenberg
That would be this: flash "Flash me" 1 to: 2 do:[:i|
self color: Color black. self world doOneCycleNow. (Delay forMilliseconds: 50) wait.
self color: Color white. self world doOneCycleNow. (Delay forMilliseconds: 50) wait.
]. Karl On Mon, Jun 30, 2014 at 11:04 PM, Bert Freudenberg <[hidden email]> wrote:
|
In reply to this post by timrowledge
> "Bother" said Pooh, as his trigger finger tired. Don't you mean his Tigger finger? -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
On 01-07-2014, at 5:06 AM, Craig Latta <[hidden email]> wrote: > >> "Bother" said Pooh, as his trigger finger tired. > > Don't you mean his Tigger finger? Groan. That would cause all sorts of problems with bounce firing. But it reminds of a new form of logic gate I just read about; no, not the memristor; a fuzzy-logic item called the eyore-gate. It does an EOR operation if it isn’t too depressed to bother. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Talks to plants on their own level. |
Free forum by Nabble | Edit this page |