dale@boing.UUCP (Dale Luck) (06/24/88)
In article <2166@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: =In article <135@quintus.UUCP=, pds@quintus.uucp (Peter Schachte) writes: == Suppose when intuition took the "focus" (keyboard ownership) from window == A and gave it to window B, it recorded the fact that A was the previous == owner in B. Then, when B is closed, ownership is given back to A. = =It already does something like this. When you open a window it records what =the active window was when it opened. When it closes, it reactivates that =window (if it's open). This can be viewed as a stack. I don't think this is the proper way of handling input refocusing either. The order of my windows open is usually quite abit different then the order that I use them in. I would prefer it keep a last active stack, and when I close the window it should reactivate the last window I had active before closing this window. Dale -- Dale Luck Boing, Inc. {cbmvax|oliveb|pyramid}|!amiga!boing!dale Although I do contract work for Amiga-LosGatos, my opinions probably don't represent those of Commodore or its management or its engineers, but I think the world would be a better place if they did.
UH2@PSUVM.BITNET (Lee Sailer) (06/25/88)
I haven't tried it yet, but wouldn't DMouse help with the problem of
Requestor Activation? What happens if I keep the mouse arrow over to the
right side and an "active" requestor pops up. Does DMouse reactivate the
window the arrow is over?
leekaz@cadovax.UUCP (Kerry Zimmerman) (06/25/88)
In article <2166@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >[deleted] >What the original >poster was complaining about was the black-hole effect when the window you're >typing into becomes inactive because of the requestor. I really don't know >if there's a good solution to that problem acceptable to everyone. Making the >requestor come up inactive wouldn't do it for me. > An interesting side affect of using Dmouse with the auto activate feature enabled, is that if your mouse pointer is not in the upper left hand corner when a requestor comes up, than the requestor is not active, and you can't use the Amiga keyboard short cuts to cancel or retry until you move the mouse pointer over the requestor. Kerry Zimmerman # {ucbvax,decvax}!trwrb!cadovax!kaz Contel Business Systems 213-323-8170 A difference between an amateur and a professional, is that a professional has the right tools.
pds@quintus.uucp (Peter Schachte) (06/25/88)
In article <339@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >In article <2166@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >=In article <135@quintus.UUCP=, pds@quintus.uucp (Peter Schachte) writes: >== Suppose when intuition took the "focus" (keyboard ownership) from window >== A and gave it to window B, it recorded the fact that A was the previous >== owner in B. Then, when B is closed, ownership is given back to A. >= >= When you open a window it records what the active window was when it opened. >= When it closes, it reactivates that window (if it's open). > >I don't think this is the proper way of handling input refocusing either. >I would prefer it keep a last active stack, and when I close the window it >should reactivate the last window I had active before closing this window. I think that's what I was asking for. If each window has a pointer to the window to give focus to if it was active when it closed, this pointer should be set not only when the window is first opened, but also every time it is given focus by being clicked in. Clear as mud? Wouldn't this be good enough for what you're looking for, Dale? I don't think you want a REAL stack, as it would grow pretty fast if you click around much, unless you took the trouble to remove an element from the middle of the stack when wanted to add it to the top. And that would take time. If maintained properly, a single pointer per window shoule be good enough, non? -Peter Schachte pds@quintus.uucp ..!sun!quintus!pds
mwm@eris.berkeley.edu (Mike (I'm in love with my car) Meyer) (06/25/88)
In article <137@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes:
<I think that's what I was asking for. If each window has a pointer to
<the window to give focus to if it was active when it closed, this
<pointer should be set not only when the window is first opened, but also
<every time it is given focus by being clicked in. Clear as mud?
Yup. Sounds like what I did for mg. But there's some gotchas. Like
where does the "previous-window" pointer for the only window on a
screen point? That one's easy - it points to NULL, and you have to
check for that case when the window closes (sigh).
Second problem: Open three windows, and delete the second one. The
first one activates. But the third one has a pointer to the (now
non-existent) second one. So what happens if you delete the first one
without activating it (send it a signal from the first one, say)?
Solution is easy again: you scan the list of all windows before you
delete one, and change any that point to the current one to point to
something else. But that's the same as scanning a stack, as suggested
here:
<I don't think you want a REAL stack, as it would grow pretty fast if you
<click around much, unless you took the trouble to remove an element
<from the middle of the stack when wanted to add it to the top. And
<that would take time.
So this method isn't much of a win over a stack. And both have the
question of "what do you do with that old pointer?" after you delete a
window. Just delete it from the stack, if it's a stack.
For mg, I just copied the pointer of the window that was closed. This
doesn't maintain the "stackiness" of the resulting structure. You wind
up with two pointers to the same window often.
On the other hand, if you delete elements from the stack, you have a
problem. In order, activate window A, window B and then window A.
Guess what - A says go to B after it's closed, and B says go to A.
That's not a stack! That's a loop.
<If maintained properly, a single pointer per window shoule be good
<enough, non?
Yes. You could also maintain a strictly ordered list (something akin
to a stack, but solving the above problem) with that same single
pointer.
Ok, Dale, you wanna tell us what it _really_ does now, so we can start
making suggestions from reality, instead of conjecture?
<mike
--
Lather was thirty years old today, Mike Meyer
They took away all of his toys. mwm@berkeley.edu
His mother sent newspaper clippings to him, ucbvax!mwm
About his old friends who'd stopped being boys. mwm@ucbjade.BITNETdale@boing.UUCP (Dale Luck) (06/26/88)
In article <137@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: > >The pointer should be set not only when the window is first opened, but also >every time it is given focus by being clicked in. >I don't think you want a REAL stack, as it would grow pretty fast if you >click around much. Right, the implementation does not necesarily need to follow the semantics of the feature. All it needs to do is look like a stack. When ever a window becomes active, a time stamp could be placed in the window structure. When the window is deleted intuition just looks for the most recently activated window. Simple enough? This method also gets around, stale backward activation pointers. And what do you do when the window you are now going to activate because the present one is being deleted does not exist. Dale -- Dale Luck Boing, Inc. {cbmvax|oliveb|pyramid}|!amiga!boing!dale Although I do contract work for Amiga-LosGatos, my opinions probably don't represent those of Commodore or its management or its engineers, but I think the world would be a better place if they did.
joe@cbmvax.UUCP (Joe O'Hara) (06/27/88)
In article <341@boing.UUCP> dale@boing.UUCP (Dale Luck) writes: >In article <137@quintus.UUCP> pds@quintus.UUCP (Peter Schachte) writes: >> >>The pointer should be set not only when the window is first opened, but also >>every time it is given focus by being clicked in. >>I don't think you want a REAL stack, as it would grow pretty fast if you >>click around much. > >Right, the implementation does not necesarily need to follow the >semantics of the feature. All it needs to do is look like a stack. >When ever a window becomes active, a time stamp could be placed in the >window structure. When the window is deleted intuition just looks for >the most recently activated window. Simple enough? > This method also gets around, stale backward activation pointers. >And what do you do when the window you are now going to activate because >the present one is being deleted does not exist. Another approach would be two pointers in the window structure, PREV_Window and NEXT_Window. When a window in the middle of the chain closes, it's a simple matter to update the pointers in the affected windows. -- ======================================================================== Joe O'Hara || Comments represent my own opinions, Commodore Electronics Ltd || not my employers. Any similarity to Software QA || to any other opinions, living or dead, || is purely coincidental. ========================================================================
pds@quintus.uucp (Peter Schachte) (06/29/88)
In article <4120@cbmvax.UUCP> joe@cbmvax.UUCP (Joe O'Hara) writes: >Another approach would be two pointers in the window structure, PREV_Window >and NEXT_Window. When a window in the middle of the chain closes, it's a >simple matter to update the pointers in the affected windows. This seems like the most efficient (and simple) approach. There's one detail that needs to be considered, though: these chains can easily be circular. Click in one window, then a second, then back in the first. Now both pointers of each window point to the other. Now close one window. The other becomes the active one, and has both pointers pointing to itself. Now when you close THIS window, you have to be careful you don't find yourself in GURU-land. Also, there could be other windows on the screen, one of which SHOULD be given the focus. A small modification to this algorithm could fix this problem. Here's a rough code fragment: new_focus_window->PREV_Window->NEXT_Window = new_focus_window->NEXT_Window; new_focus_window->NEXT_Window->PREV_Window = new_focus_window->PREV_Window; new_focus_window->NEXT_Window = current_focus_window; new_focus_window->PREV_Window = NULL; current_focus_window = new_focus_window; This way, you avoid cycles, and keep all the windows in this "focus stack." An interesting, and I believe positive, side-effect of this is that there would ALWAYS be a focus window as long as there are ANY windows on the current screen. I think I would find this the best possible focus management scheme, much better than the real-estate (sun) approach. So how about it? Doesn't seem like it would be too difficult to implement. -Peter Schachte pds@quintus.uucp ..!sun!quintus!pds
kim@amdahl.uts.amdahl.com (Kim DeVaughn) (06/30/88)
In article <46087UH2@PSUVM>, UH2@PSUVM.BITNET (Lee Sailer) writes: > I haven't tried it yet, but wouldn't DMouse help with the problem of > Requestor Activation? What happens if I keep the mouse arrow over to the > right side and an "active" requestor pops up. Does DMouse reactivate the > window the arrow is over? About 70% of the time, the window gets activated; about 30% of the time the (string gadget in the) requester does. Exactly *which* will be active after the requester pops up seems to be entirely random, as repeated experimentation using vt100's "change dir" function will produce either result ... without moving the mouse, or doing anything else to the system (until, of course, the window gets activated instead of the requester ... in which case, you must move the mouse to click into the requester in order to respond to it). Any ideas for fixing this bug? /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
michael@stb.UUCP (Michael) (06/30/88)
Here's a simple (?) suggestion: Add a new flag SYSREQ. Semantics are: Any keyboard input that would go to this window has the possibility of being passed to another window (technically to another IDCMP port). Whether it is passed or not depends on whether it is a keystroke associated with something intuition can check, such as a menu selection. Give system requesters a menu consisting of amiga-v/b. Presto. Anything you type at a SYSREQ window will go to whoever was active when it was created. Then you have the best of both worlds. Michael : --- : Michael Gersten uunet.uu.net!denwa!stb!michael : sdcsvax!crash!gryphon!denwa!stb!michael : What would have happened if we had lost World War 2. Well, the west coast : would be owned by Japan, we would all be driving foreign cars, hmm...