On 1 June 2012 12:25, Igor Stasenko <[email protected]> wrote: > On 1 June 2012 10:48, Frank Shearar <[email protected]> wrote: >> On 1 June 2012 00:43, Igor Stasenko <[email protected]> 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. frank >> frank >> >>> 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 <[email protected]> wrote: >>>> http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Cursor_consider_showWhile:_%5BHarmful%5D&entry=3432339015 >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > > > > -- > Best regards, > Igor Stasenko. >
