Re: setNextKeyView: dangling pointers

[Nicola Pero]

> A relatively minor issue is that MacOS-X has no -setPreviousKeyView: method 
> ...
> which means that all changes to the key-view chain are done by the 
> -setNextKeyView:
> method (except for some stuff done in -dealloc).
> 
> More importantly, the documentation talks about a key view loop ... but 
> neither
> MacOS-X nor GNUstep implement any such thing.
> 
> GNUstep implemented a simple doubly linked list terminated with nil at either
> end, which *could* be made into a loop by joining the ends.
> 
> MacOS-X implemented a directed graph of one-to-many/many-to-one relationships,
> which *could* be made into a loop as a special case.

I didn't know what the MacOS-X implementation was, and now that I know, it
doesn't make any sense to me :-)

It's called a 'key view loop' because it should be set up in such a way
(by joining the ends) that by pressing TAB enough times, you should walk
once through all the accept-first-responder controls in the window, till
you finally get back to the original one.

That's the basic point of key views ... that you can do things with the
keyboard.  To do things with the keyboard, you must be able to visit all
controls by pressing TAB.  If there is a control which can't be reached,
keyboard navigation is useless, because that control can't be visited and
edited using the keyboard.

Now, if you do

[A setNextKeyView: C];
[B setNextKeyView: C];

and if that means that both A and B go to C, then you've broken this
assumption.

 * if you are in C, by pressing TAB enough times, no matter how you set up
the rest of the key view chain, you never walk through all controls.  
Because if by pressing TAB you are sent to A at a certain point, you are
immediately afterwards sent to C (and so you don't pass through B!), while
if you at a point are sent to B, you are not sent to A.  So if you start
from C, and press TAB, you will either pass through A or pass through B.  
You will never pass through both of them, so one of them will be out of
the key view loop - it will be *impossible* to reach it by pressing TAB
enough times.  IMO this is certainly a mistake in the key view setup.

 * if you are in A, and press TAB, you go to C.  If you now realize you
didn't want to do that, and want to go back to A, and press Shift+TAB to
go back/undo your operation, you are sent back to B instead of A.  Not
very friendly I'd say.

So I'd say any code such as 

[A setNextKeyView: C];
[B setNextKeyView: C];

(in the MacOS-X interpretation) is always an error in the key view setup.

Anyway - I understand your point of being compatible with MacOS-X (even if
I wish we were better than MacOS-X :-), and as soon as the thing works
correctly in the only 'proper' usage (which is the key view loop, every
key view has a single next, and the last key view has the first one as its
next), it's Ok.

I don't know why they spent time implementing a one-to-many relationship
when it's obvious that using this 'feature' can only be a bug in the
program ...


> Basically, what I did was try to mimic the MacOS-X behavior as closely 
> as I could.

Ok ... I wonder if that's what we want, but since you made the effort to
be compatible, it's nice to have it.

I've not tested it, but I assume you did. :-)