Re: cursor ills
Re: cursor ills
- Subject: Re: cursor ills
- From: "Alastair J.Houghton" <email@hidden>
- Date: Fri, 3 Oct 2003 11:00:06 +0100
On Thursday, October 2, 2003, at 10:43 pm, robert l clair wrote:
And aside from a brief and extremely unpleasant experience with
windows98 I have never worked on a single-tasked OS.
Windows 98 and 95 aren't single-tasked, they have pre-emptive
multitasking.
It is a nice thought that the user should be able to work
while the difficult things happen in the background - but sometimes
it just doesn't work that way. Consider a drawing/paint program.
For a large design the screen redraw may become slow. But the
appearance of the screen is pretty much the most important thing
here. While I'm sure you can contrive a case, in fact there is
very little you useful you can do (other than quit) until the screen
redraws, whether or not you are spinning the event loop.
I can think of several non-contrived cases... Operating on a another
document might be useful (e.g. if I have two drawings open, I'd be
happy to work on a smaller/simpler one whilst a larger/more complex one
redraws). Being able to look in the menus or explore the help would be
useful. Editing the application's preferences might be handy (perhaps
I could lower the rendering quality or do something else to speed it
up?). Aborting the redraw could be handy as well... e.g. if I know
that I want to zoom in on a particular area of the drawing straight
away (so it doesn't need to waste time drawing the rest of it).
I don't think the beachball is really there for you (as a programmer)
to use as an indication that your application is busy. It's there for
the user, to tell them when your application isn't responding to input
for some reason. If you aren't responding to events, then they can't
even *abort* whatever it is you might be doing, and they often have no
indication of how long it's going to take either, which is why they
view it, quite rightly, as "the spinning beach-ball of death", and it
is one reason that the window server is in charge of it (after all,
your application couldn't be relied upon to tell the system when it has
stopped responding ;->).
It is easy enough in most cases to push long-running tasks into a
separate thread, or to perform them in the background whilst continuing
to process events. IMHO we should be trying to write our software so
that the beachball never appears, and if it does, then it should only
do so for reasons beyond our control (system load, user wilfully
abusing our application, that sort of thing).
Artists in general do not like to draw blindfolded even if it is
theoretically possible.
:-) Indeed not. They also don't like having to wait indefinitely, and
they particularly don't like not being able to abort things that are
taking too long, both of which are potential problems whenever the
spinning beachball appears.
Kind regards,
Alastair.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.