[Pharo-project] about cursor: an interesting blog post
frank.shearar at gmail.com
Fri Jun 1 08:23:40 EDT 2012
On 1 June 2012 12:25, Igor Stasenko <siguctua at gmail.com> wrote:
> On 1 June 2012 10:48, Frank Shearar <frank.shearar at gmail.com> wrote:
>> On 1 June 2012 00:43, Igor Stasenko <siguctua at gmail.com> wrote:
>>> I am completely agree with this post.
>>> A showWhile: pattern takes its roots from modal processing,
>>> when user is blocked and have to wait till something will give control
>>> back to him.
>>> This is inacceptable and should be exterminated. It was excusable for 80's ,
>>> partly excusable in 90's .. and completely inexcusable past 0's.
>>> A progress bar is another abomination of same kind.
>>> Look at download bars in your internet browser: do they center it in a
>>> window on top of everything and preventing you from doing anything? or
>>> maybe they just sit in the corner and not interfere?
>>> This is a road where we should put our steps on.
>> "No modes" is something towards which we should strive. However, don't
>> forget that downloading a file in a web browser is completely
>> different to loading a package into an image: the former changes no
>> state, and the latter can do arbitrary things to the image itself.
>> We need _some_ kind of notification, and in fact Chrome _does_ have a
>> progress bar... but it's a little pie-slice thing down on the bottom
>> of the screen. I can see it, but it doesn't stop me carrying on
>> working. So I'd say it's not so much that progress bars are an
>> abomination, but rather progress bars that stop you from working (like
>> Monticello's bars (but remember the "you're changing your own brain"
>> warning previously mentioned)) that are the abomination.
> in smalltalk code & data is the same - it just objects.
> why you think "changing your brain" should stop you from doing something else?
> When you coding in browser, you alsos changing systems brain.
Yes, there is no difference between loading a package and entering the
same code through the browser... except that in the former case
(without the abominatory modal progress dialogs stopping your) you
might ALSO be adding code, or be running something, or or or.
So you start loading some package. That package sadly has a bug in its
replacement of Object >> #printString which accidentally kills the
image. You're busy debugging something while that package loads.
You're inspecting something. You inspect it again... and your image
dies! You know you weren't doing anything crazy, so this time it's not
your fault. But was it a VM bug? Some weird edge case in the base
image noone's run into before? Monticello? The package being loaded?
While that package is loading - while you are busy hacking away - the
image is changing under your feet. That is _never_ safe. Now, in happy
land, we'd have sandboxes and isolation and atomic loading and all
sorts of fun stuff so, in happy land, this wouldn't be a problem. But
_today_ it would be a problem.
>>> We should remember once and for eternity: staying responsible to user
>>> input is most important task for a system. The rest doesn't matters.
>>> On 31 May 2012 21:22, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
>>> Best regards,
>>> Igor Stasenko.
> Best regards,
> Igor Stasenko.
More information about the Pharo-dev