Re: [ 101845 ] Pageup Pagedn do not work

[Alexander Malmberg]

Willem Rein Oudshoorn wrote:
> 
> Alexander Malmberg <alexander@malmberg.org> writes:
> 
> > Willem Rein Oudshoorn wrote:
> > >
> > > In my opinion, navigation through a scrollable area, like a
> > > readonly text field, should be handled by the framework.  Because
> > > if it is not done by the textfield allmost all applications will
> > > end up with texts that are only scrollable by mouse.
> >
> > But the exact method of navigation in non-editable text depends on
> > how it is used. Should the up key move the cursor one line up, or
> > scroll up a bit?
> 
> This question is not limited to non-editable text fields.  Somehow
> people came up with a reasonable default for editable versions.

No, this is no problem for editable text view. They have an insertion
point, and up and down move the insertion point. Any other behavior
would be very awkward. (That said, having a set of keys for scrolling
up/down(/left/right?) one line would be useful. Some day I'd like to
take a very close look at the default key bindings for text views.)

> > Well, we're shifting the responsibility to the application
> > developers. I agree that this has drawbacks since we're likely to
> > end up with quite a few applications where keyboard navigation
> > doesn't work at all, but providing it in NSTextView prevents the
> > applications that want to do it right from doing it.
> 
> I am against a solution that will make it harder for applications to
> do it the right way.

Having keyboard navigation by default does just that in many cases,
though.

> I hope that there is a solution that:
> 
> - Allows keyboard navigation by default
> - Is transparent for applications that take over the scrolling themself.

I doubt it. When apps handle keyboard navigation themselves, they can do
so by picking up the events that the text view doesn't handle. Thus,
when the text view gets the event, it needs to know whether to handle it
or let it continue along the responder chain, but there's no way for
-gui to know until it has actually passed along the responder chain.

> I have not looked at it so I haven't got a clue if this is possible.
> Any other solution is, in my opinion, not worth the trouble.

I've tested the solution I thought of, and (after fixing a bug in -gui)
it works well. It doesn't give you keyboard navigation by default (which
can be a good or a bad thing, depending on your pov), but it's easy to
use and it doesn't require any extensions or changes of behavior.
Basically, you make your text view editable ([textView setEditable:
YES]) and add the following to its delegate:

-(BOOL) textView: (NSTextView *)tv
        shouldChangeTextInRange: (NSRange)r
        replacementString: (NSString *)str
{
        return NO;
}

This makes the text view effectively uneditable, but leaves all standard
keyboard navigation.

> All in all I think this is a rather big useability issue.  At least it
> is for me.  Personally I think GNUstep has too many of these
> useability issues and this is a reason for me to not use GNUstep gui
> applications.
> So I hope to spend some time in tracking down the issues that bother
> me and try to solve them.   But this process will be very slow :-(.

Please do! I'd be happy to try to work any solutions into -gui, although
I can't promise that everything can be handled in -gui. For this reason,
I think it'd be a good idea to have a set of pages that explain these
issues and provide (default) solutions. I've added something like it to
the wiki for now:

http://wiki.gnustep.org/index.php/UserInterfaceIssues

Feedback about this would be much appreciated! :)

> BTW thanks for listening to my whining and keep up the good work.

Thanks, I plan to. :)

- Alexander Malmberg