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

List:       kfm-devel
Subject:    Re: 2D Navagation - Custom Key Events for Web Browsing
From:       Tobias Anton <TA () ESC-Electronics ! de>
Date:       2001-08-30 10:28:40
[Download RAW message or body]

On Thursday 30 August 2001 00:17, michael chrabaszcz wrote:
> Tobias,
>
> Thank you for the pointers, they have been very helpful.  I tracked through
> the DOM:DocumentImpl::findNextLink code.  Next, how difficult would it be
> to enhance the DOM tree to allow for NextUp, NextDown, NextLeft, NextRight?
Those functions IMO do not belong into the DOM tree, because their behaviour 
depends on how the renderer's state. So i'd propose to insert a function into 
KHTMLView, that repeatedly calls findSelectableElement() and checks that 
element via getRect(), if it better suits for the next Link as the current 
"candidate", and, if so, makes it the new candidate.


> As I discovered, findNextLink is called by KHTMLView::gotoLink, which is
> called by KHTMLView::focusNextPrevChild.  While in KHTMLView::gotoLink,
> there is a call to DocumentImpl::setFocusNode, which calls
> ElementImpl::setFocus(), which applies the changes and draws the new box at
> the next link.  How exactly does it know to draw the box as a "dashed black
> line"?  Are these drawing parameters configured somewhere or initially hard
> coded as such?
btw, this "dashed" black line is really thought of as a "dotted" inverting 
line.

They are configured in the default style sheet, found in css/html4.css
look for the ":focus" and ":active" selectors.
By adding similar style rules you can modify the link indicator appearance.

Cheers,
Tobias

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