[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Keyboard traversal of links
From:       Lars Knoll <Lars.Knoll () mpi-hd ! mpg ! de>
Date:       2000-03-22 9:57:02
[Download RAW message or body]


Hope you don't mind me moving this thread to the list. I had too much
private email conversation about khtml in the last weeks, and I think it's
a bad idea, if I'm the only one knowing what each other person is doing.

On Tue, 21 Mar 2000, Richard Moore wrote:
> Tobias Anton wrote:
> > 
> > Hello Richard!
> > 
> > I heard from Lars Knoll that you will probably be implementing in
> > Konqueror
> > the functionality of some kind of cursor in the htmlview, that can be
> > moved
> > from one link to another by pressing tab, so that one can jump to any
> > desired link before moving to the link's destination by pressing enter.
> > 
> > I would like to know about the state of development regarding this
> > feature. If
> > there's work to be done, i would like to offer my help to you.
> 
> I only started thinking about how to do it yesterday, so I don't really
> have a plan yet. The most difficult aspect seems to be that HTML 4.0
> allows the HTML page to define the desired traversal order, and even
> keybindings which makes things a bit more complex than it appears at
> first sight. This is particularly relevent when forms are being used,
> but the solution for links needs to integrate nicely with this.
> 
> Any help/ideas would be much appreciated.

Some ideas:

I'd just go through the document tree the first time some keyboard
navigation is requested and build up a list of anchors and form elements.
One can store these lists in some pointers in KHTMLViewPrivate. A
QList<DOM::NodeImpl> will do probably.

Then, you only need to reorder the list according to tabbing order. If you
want more advanced navigation, this might get a bit more complicated...

You can always get the position of the element in the widget by using:
NodeImpl::renderer()->absolutePosition(), and then move the scrollview, so
that the item is visible.

We'll need to outline the item somehow. I'm still not sure what's the best
way here. Antti has perhaps some ideas.

Anyway, you'll also need to give focus to form elements. For this you'll
need the widget representing the form element. You can get that with
something like the following code (let's use rtti for once... ;-) ):

NodeImpl *n = list->currentItem();
RenderObject *r = n->renderer();
RenderWidget *rw = dynamic_cast<RenderWidget *>(r);
if(rw) 
{ 
    // we have a form element
    QWidget *w = rw->widget(); // widget() has to be added to the class...

    // give w the focus
}

Hope that helps you a bit.

Lars

[prev in list] [next in list] [prev in thread] [next in thread]