key navigation and visible area of the page
Tobias Anton
TA at ESC-Electronics.de
Tue May 18 21:07:00 BST 2004
On Dienstag, 18. Mai 2004 10:17, Lubos Lunak wrote:
> On Monday 17 of May 2004 20:59, Tobias Anton wrote:
> > On Montag, 17. Mai 2004 17:19, Lubos Lunak wrote:
> > > I already described the problem. The Tab behaviour is weird if the
> > > focused item is not visible. Go e.g. to
> > > http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/khtml/khtmlview.cpp ,
> > > hit Tab few times, scroll ten pages down, and start hitting Tab again.
> > > I doubt you can guess what it will do, but even if you do, I don't
> > > consider that to be known behaviour, in fact I was pretty confused when
> > > that happened to me.
> >
> > I admit that mixing keyboard and mouse navigation does not work well.
>
> No mouse navigation involved, that "scroll ten pages down" was
> 10xPageDown.
Correction: "I admit that mixing tabbing with other navigational methods does
not work well."
> > The tiny detail I don't like about your change is that you added a bool
> > argument to a function in order to make it behave like another, already
> > existing function. That looks like code bloat to me. For that, I'd
> > propose that you use ensureVisible, we remove the "bool" argument of the
> > scrollTo() function again
>
> I would, if you show me that right way. Open the attached page in your
> Konqy and press accesskeys 9 or 0 (i.e. Ctrl+Alt+9/0). With ensureVisible()
> the results are (in some cases noticeably) worse.
Please explain me the problems you encounter, because to find out by myself,
I'd need to implement the solution which you already have, recompile
everything and view the test page.
Actually, with the current codebase, Ctrl+Alt+[012] tries to open a new page
which doesn't exist. Before that, it scrolls somewhere but it's gone too fast
to see what it does.
Cheers
Tobias
More information about the kfm-devel
mailing list