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, commits@source.squeak.org wrote:
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 ]!
On Mon, Jun 30, 2014 at 10:33 AM, Chris Muller asqueaker@gmail.com wrote:
TSTTCPW but I think we should revisit #flash again because sometimes it's so fast I barely saw it.
Then flash needs a 1/16 - 1/8 sec or thereabouts delay to make it visible right?
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, commits@source.squeak.org wrote:
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 ]!
On Mon, Jun 30, 2014 at 2:34 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mon, Jun 30, 2014 at 10:33 AM, Chris Muller asqueaker@gmail.com wrote:
TSTTCPW but I think we should revisit #flash again because sometimes it's so fast I barely saw it.
Then flash needs a 1/16 - 1/8 sec or thereabouts delay to make it visible right?
It's already been proposed, see thread:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-August/172823.ht...
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 asqueaker@gmail.com 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; tim@rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh, as his trigger finger tired.
On 30.06.2014, at 21:54, tim Rowledge tim@rowledge.org wrote:
On 30-06-2014, at 12:52 PM, Chris Muller asqueaker@gmail.com 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
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.
- Bert -
On Mon, Jun 30, 2014 at 4:04 PM, Bert Freudenberg bert@freudenbergs.de wrote:
On 30.06.2014, at 21:54, tim Rowledge tim@rowledge.org wrote:
On 30-06-2014, at 12:52 PM, Chris Muller asqueaker@gmail.com 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
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.
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.
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 bert@freudenbergs.de wrote:
On 30.06.2014, at 21:54, tim Rowledge tim@rowledge.org wrote:
On 30-06-2014, at 12:52 PM, Chris Muller asqueaker@gmail.com 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
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.
- Bert -
On 30.06.2014, at 21:54, tim Rowledge tim@rowledge.org wrote:
On 30-06-2014, at 12:52 PM, Chris Muller asqueaker@gmail.com 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
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.
- Bert -
On Mon, Jun 30, 2014 at 11:04:47PM +0200, Bert Freudenberg wrote:
On 30.06.2014, at 21:54, tim Rowledge tim@rowledge.org wrote:
On 30-06-2014, at 12:52 PM, Chris Muller asqueaker@gmail.com 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.
On Mon, Jun 30, 2014 at 12:54 PM, tim Rowledge tim@rowledge.org wrote:
On 30-06-2014, at 12:52 PM, Chris Muller asqueaker@gmail.com 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.
-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.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "Bother" said Pooh, as his trigger finger tired.
On 01-07-2014, at 5:06 AM, Craig Latta craig@netjam.org 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; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Talks to plants on their own level.
squeak-dev@lists.squeakfoundation.org