Re: Proposed deletion of checkpoint on spawning windows

But a well constructed desktop is an interface for dealing with the kernel -
and I should be able to move from my audio desktop to my visual desktop and
back naturally.

In the usual model this is what happens - you get a window pop up, you deal
with it, while the old one lies on the stack, and when you get sck of it you
kill it and go back to where you were. What is missing is that you don't know
the difference between getting a new window pop up and having the contents of
your old window replaced - and there are a bunch of confusing factors that
make it worse like the use of refresh for redirects.

Charles

On Wed, 25 Aug 1999, Al Gilman wrote:

  At 03:02 PM 8/25/99 -0400, Charles McCathieNevile wrote:
  >
  >So I think I'm close to agreeing that the user needs to be able to say "no,
  >don't open a new window. Does this mean "force the new window content into
  >this window instead"? Or "forget it"? which is what happens in lynx when I am
  >reading a page written by some clown who thinks
  >javascript:popout_window('some_uri') is a URI. (Should we specify an answer
  >to that question at all?)
  >
  >Charles McCN
  >
  
  I think that the ideal answer is that the structure for indexing currently
  open processes is part of the desktop, not the kernel.  Then the user has a
  prayer of recalling how it works.  Emacs and screen are close what one
  would do in speech; I have not read Raman's book to see how much he
  develops this topic.
  
  One option in the above scenario is "pop it on the stack" a_la what has
  been considered in SMIL: current process suspends and resumes when added
  process terminates, all if the user OKs.
  
  Al
  

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

Received on Wednesday, 25 August 1999 19:13:10 UTC