Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!uakari.primate.wisc.edu!caesar.cs.montana.edu!ogccse!orstcs!uther.CS.ORST.EDU!osbornk
From: osbornk@uther.CS.ORST.EDU (Kasey S. Osborn)
Newsgroups: comp.os.os2
Subject: Re: Focus cycling
Message-ID: <13958@orstcs.CS.ORST.EDU>
Date: 23 Nov 89 19:10:35 GMT
References: <627646071.19046@minster.york.ac.uk>
Sender: usenet@orstcs.CS.ORST.EDU
Reply-To: osbornk@uther.CS.ORST.EDU (Kasey S. Osborn)
Organization: Oregon State Univ. - CS - Corvallis, OR
Lines: 68

In article <627646071.19046@minster.york.ac.uk> writes:
>In article 92, osbornk@uther.CS.ORST.EDU (Kasey S. Osborn) writes:
>>Okay, fine, to go one of the two directions, I set the focus to the
>>bottommost child window.  That takes care of Shift-Tab.
>>
>>However, when it comes to setting the focus to the window that is
>>just below the focus window, I am having difficulty.  Somehow I need
>>to make the focus window become the bottommost window.  This is what
>>OS/2 does to windows listed in Task List when one hits Alt-Esc.
>>
>>Setting the focus to the window next to the top causes the focus
>>window to be moved second.  This limits you to switching between the
>>two topmost windows, so that's out.  Any ideas?  (Proven, please.)
>
>I think the problem here is one of interface design, rather than a
>programming problem.  There is no way in which you can cycle through the
>windows based upon their order on the screen, as you change the order
>when you bring a window to the top.

I disagree.  A direct analogy would be a circular queue:  When you move
the head pointer, the ordering does not change, only the ranks of the
members of the queue.  (By rank, I mean distance from the head.)

>If you think about it there's no sensible way to handle this.

I have though about it.  And thought about it, and thought about it...
I remain convinced that the capability is there, if not the means.

>Imagine a user in this position; he brings
>the second window to the top with shift tab, and then goes away for a
>day.  When he comes back, he wants to look at the window which is now
>second, and (sensibly) presses shift tab again, only to get the THIRD
>window.

Ah, but I want the top window to be moved LAST.  Thus, the second window
becomes the first, and the third the second...  When the user hits
shift-tab the second time, there is conceptually no difference than
when he hits it the first time.  This is what PM already does to Task
List windows, so it CAN be done.

>The way I have coded this, is to impose another order on the windows,
>(e.g. the order in which the windows were opened), maintain a separate
>list in this order, and cause shift tab to cycle through this list.

Yes, adding another layer of indirection would work.  However, windows
would not overlap consistently with the ordering presented to the
user through the tab keys.  Is this the case with your application?
With PM's Task List windows, the overlapping is correct.

In addition, I would like the user to be able to change the ordering
on the fly (i.e. by right clicking the mouse on a window, moving it to
the top).  With your method, the user would be locked into a particular
ordering.  Correct?

>If you examine the task manager, I think you'll find that this is the
>method that it uses.

But PM ALREADY knows the window ranking.  If it creates another list
on top of this, that list would be redundant.  The problem is that
PM will not manipulate the window ranking in the manner I desire.  (Or
more precisely, I don't know how to tell it to.)  It seems a shame to
have to create a linked list just to track information that PM already
has.  There must be an elegant solution.

And yes, I would like very much to examine the task manager.  Please
mail me the source.  :-)

Kasey