[prev in list] [next in list] [prev in thread] [next in thread]
List: kfm-devel
Subject: Re: activate vs. click event
From: Germain Garand <germain () ebooksfrance ! org>
Date: 2004-07-12 17:54:11
Message-ID: 200407121854.11175.germain () ebooksfrance ! org
[Download RAW message or body]
Le Lundi 12 Juillet 2004 13:03, bj@altern.org a écrit :
> Ok, last version of my patch.
>
> 1) Regarding the label accesskey, I thought of a new way to handle it,
> simply passing the label's referrer to the accesskey handler. It seems to
> me to be the easiest solution, no need to a HTMLLabelElementImpl::click()
> method...
>
> 2) Clicking on a label will generate a click on it's referrer element. I
> could revert to a simple focus, but still I think the biggest interest in
> the label element is for checkboxes and radio buttons. It's really nice to
> be able to click on their text to check them, like it works in the KDE
> widgets!
>
> Let me know if you wish me to make any changes, I would like to commit soon
> if possible.
I think the idea is great too, but that the khtmlview ID_LABEL test and block
should be displaced within the focus handling block, like:
- if( node->isSelectable()) {
+ if( node->isSelectable() || node->id() == ID_LABEL) {
+ if (node->id()==ID_LABEL) {
+ // if Accesskey is a label, give focus to the label's referrer.
+ node=static_cast<ElementImpl *>(static_cast<
HTMLLabelElementImpl* >( node )->getFormElement());
+ if (!node) return true;
+ guard = node;
+ }
Otherwise that won't work for textareas, because of:
case ID_TEXTAREA:
break; // just focusing it is enough
Testcase:
http://www.htmlgoodies.com/tutors/accesskey.html
(try accessing the lineedits in the middle of the page)
Otherwise, please go ahead!
Germain
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic