> 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. :-) _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
