discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSTextView and key events, WAS: [ 101845 ] Pageup Pagedn do not work


From: Willem Rein Oudshoorn
Subject: Re: NSTextView and key events, WAS: [ 101845 ] Pageup Pagedn do not work
Date: 31 Mar 2003 07:41:31 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Alexander Malmberg <alexander@malmberg.org> writes:

> Willem Rein Oudshoorn wrote:
> > 
> >   superclass
> 
> Passing it to super effectively means sending it further down the
> responder chain.

Yes, I know.

> > 
> > Why is in -[NSTextView keyDown:]  the decission:
> > 
> > [non-editable] pass event to superclass, do NOT touch the
> >                key down at all.
> 
> Non-editable text views don't handle key events, so it's just passed to
> the next responder.

Why not?  I understand that it does not handle most key events, but
why should not -[textView:doCommandBySelector] be called when you
press arrow up or down?

> 
> > [editable]     pass to delegate or handle in NSTextView, but
> >                DO NOT PASS to superclass, even when the event
> >                can not be handled by the NSTextView + delegate.
> 
> Where do you see this? When editable, the key event is passed to the
> NSInputManager. All key events are swallowed by it, and the delegate
> isn't involved. 
> (The input manager will then parse the key events and
> figure out what to do with them, and the delegate is involved when the
> input manager passes this information back to the text view. See the
> NSTextInput protocol.)

Yes. I see.  But after reading the NSResponder information I think
that the doCommandBySelecter should travel the NSResponder chain.  But
the NSTextView does not (and the source documentation states that it
does not, but the documentation does not say why)

Could that not be the right behaviour?  Regardless if
the view is non-editable, involve the NSInputManager and
let the insertText and doCommandBySelector travel the 
NSResponder chain.
 
> You can't both handle the key event (at least not using the input
> manager) and pass it on.

Yes you ar right.

> > * In the NSTextView documentation provided by Apple I do not
> >   see any reference to special behaviour for non-editable
> >   textviews with respect to the NSResponder chain.
> 
> This could be considered an implementation detail, though.

Not really, namely deciding to bypass the NSInputManager when
the textview is non-editable changes the behaviour of how
keyDown events are handled.
 
> > * [the real reason]  If the situation is as I expect we can
> >   quite easily implement pageup/pagedown for non-editable textviews.
> >   Namely:
> >   - Implement keyDown in NSScrollView (trivial and it works)

After reading the documentation, nothing need to be changed
in the NSScrollView, just make sure that doCommandBySelector:
travels the responder chain and pageDown: in NSScrollView
will be called if it arrives there.

> However, this is an even bigger deviation from OPENSTEP/OpenStep, and
> potentially affects tons of things that use scroll views. 

Yes, it will add keyboard scrolling if the content of the NSScrollView
does not do anything special.    

> Compared to
> handling it in NSTextView, you'd also lose all text view specific key
> handling, eg. selecting text with the keyboard.

Why?  NSTextView and friends is earlier in the NSResponder chain, 
so the pagedown/pageup key events will never reach the NSScrollView,
neither by doCommandWithSelector, nor keyDown.

 
> >   - Applications that want to handle their own scrolling,
> >     should register themself as delegate and handle the
> >     textView:doCommandBySelector:
> 
> This method of overriding wouldn't work. By the time you get to
> -textView:doCommandBySelector:, you must already have decided whether to
> handle it or not.

Why does this not work?  The documentation states that the delegate
of the NSTextView will get these events, and can indicate
that it handled it by returning YES. 

Wim Oudshoorn.  (Who is still a little confused).





reply via email to

[Prev in Thread] Current Thread [Next in Thread]