[PATCH] Automatic assignment of accesskeys

[Lubos Lunak]

On Friday 08 of April 2005 14:46, Lubos Lunak wrote:
> Dne so 9. dubna 2005 0:22 Tobias Anton napsal(a):
[...]
> > So, every element that isFocusable() also is a candidate for an accesskey
> > and every one that is not can't be focused or activated anyway.
> >
> > The bottom line:
> > I'd suggest removing this:
> >             default:
> >                     ignore = true;
> >                     break;
> >             }
> >             if( ignore )
> >                 continue;
> > , adding a:
> >  if (!element->isFocusable())
> >   continue;
> > before the switch(), and implementing a generic way for picking the
> > accesskey for generic DOM elements in the
> >  default:
> > section of the switch-statement.
>
>  If isFocusable() can change dynamically then I don't think it would be
> right to use it there - that'd mean the relatively random assignment of
> accesskeys could become even more random and changing. Adding it in the
> default switch case is fine but I'd rather have few accesskeys assigned to
> disabled controls than having one accesskey assigned to more elements of
> one form at different times.

 Ok, attached is the latest version which I consider final, unless somebody 
finds some problem there. Or if some of the things can be done in a better 
way, because I'm unsure if there's perhaps a better way to implement the 
functionality of getElementText() and buildLabels().

>
> > Picking the first unused non-whitespace character of the
> > descendant::text() nodes seems appropriate.

 Done. Now it seems to be quite good at finding the matching text even for 
elements that don't have any text themselves, it reads either the matching 
<label> text or the adjacent text.

> >
> > Note: This is only my HO. I still haven't understood what the
> > fallbackAccessKeysPriorityWords() thingie is about. How does it work?
>
>  It's a list of expressions that increase priority of various elements if
> they contain some of the texts (so that you can make e.g. 'Next' and
> 'Previous' always have an accesskey). But I've already changed my mind on
> this, I think it would be better to be able to specify 'N:Next in
> thread,P:Previous in thread' etc., so that one would be able to specify
> exact accesskey for some of the often used links and it would not change
> randomly as it does now (e.g. the already mentioned 'next in thread' at
> lists.kde.org). I wonder if that would be worth a GUI setting (probably
> not).

 Done as well. Now e.g. specifying "FallbackAccessKeysAssignments=P:prev in 
thread,N:next in thread" in [HTML Settings] in konquerorrc takes care of the 
random assignment of accesskeys at lists.kde.org .


-- 
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 --------------
A non-text attachment was scrubbed...
Name: khtml.patch
Type: text/x-diff
Size: 16550 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050412/d38f39e0/attachment.patch>