key navigation and visible area of the page
Lubos Lunak
l.lunak at suse.cz
Tue May 18 09:17:03 BST 2004
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.
> > But perhaps this problem would go away after changing Tab to start from
> > the visible area, like Arend suggested. What's your opinion on this?
>
> I consider it a good idea. This behaviour is already implemented, but it is
> only active if there's no currently focused node. If you have a look at
> khtmlview.cpp:1682, you'll notice that this is supported already, but is
> only active if no node is currently focused. I could fix it by restoring
> the old behaviour, but I need some information on how you are using
> d->scrollBarMoved.
That'd be nice.
>
> > I found using scrollTo() to be better than ensureVisible() - it takes
> > QRect instead of just a point, and seems to be a bit better at
> > positioning. So I'd like to keep the onepage argument. Scrolling by one
> > page for accesskeys definitely doesn't make sense.
>
> I agree with your opinion on the accesskey behaviour.
> But scrollTo() is just a replacement for ensureVisible(), differing only in
> its one-page-per-click scrolling behaviour. If you don't want that, don't
> use that function.
>
> I claim that there is no advantage of
> scrollTo(QR)
> over
> ensureVisible(QR.center().x(), QR.center().y());
> . The latter does exactly the same as the former if you use it The Right
> Way.
>
> 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.
--
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20040518/e96d12fa/attachment.html>
More information about the kfm-devel
mailing list