|
Bug Notes |
|
|
hbernard
|
|
2004-11-27 21:26
|
|
Well, where is the patch ;-) ?
And, another think about 'button' access key :
It would be nice to make them customizable (maybe by using some rule in the language file - Co_#py would mean Copy and access key is 'P'. |
|
|
|
|
Well, we need also customize short letters like 'A', 'C', 'P', 'V', 'D' used with text links.
But anyway I would like to see a patch for this. |
|
|
|
marianov
|
|
2004-11-29 21:28
|
|
|
I uploaded the patch two days ago. |
|
|
|
hbernard
|
|
2004-11-29 22:11
|
|
It's that simple ? Great !
But can we use
<button><U>A</U>dd</button> syntax to show which access key is active ?
Hmm, not sure this will be compatible with all browser. |
|
|
|
hbernard
|
|
2004-11-30 09:31
|
|
Some ideas on this :
API for such thing is most of the time (AFAIK)
'name' => 'my #Name',
where 'N' will be the access key.
There are very good reasons for this :
- you don't have to add explicit API everywhere, you just handle this or not.
- you have more information than with 'accesskey' => ... API, because you know which letter should be magnified.
As an accessibility concern, this is very important to DISPLAY accesskeys.
We could change language files to know about this, and this could be a progressive change (BC) : if there is no accesskey, there is no access key ;-)
At the field level, user would just have to write
'name' => 'my #Name'
same with tab names.
I uploaded a patch. Change your language file (using above API) and calling script to have a try.
Because <button> </button> html is not really well handled by MSIE (but ok in FFox), I made "#label" became "label (L)" for buttons. But it could be possible to enhance later.
only side effect would be to require different language file when using subforms, what I suspect would already be done (because 'Add' is maybe too generic ;-) |
|
|
|
hbernard
|
|
2005-03-05 12:48
|
|
So what happend with this.
The uploaded patch is not perfect, there are some things to clean up, but can someone have a look and give its opinion ? |
|
|
|
|
|
Just a question: People are supposed to change their language file in order to get this working? |
|
|
|
hbernard
|
|
2005-03-05 14:06
|
|
No, not exactly. The change is BC.
There are two types of accesskey :
- field (which are set by the user into the 'name' value)
- and button :
My guess is that PME simply provide updated language file with default accesskey, which are defined into the language file with
'Copy' => 'Co#py'
So, no, people don't have to change their language file themself.
But langages files have to be updated in order to activate the feature.
Does it answer to your question ?
edited on: 2005-03-05 14:13 |
|
|
|
|
Yes, it does, however I'm not sure how such update will be issued.
You can update french, I can update slovak, we can update english language file. However I'm not how about others. We can simply was for translators to follow this feature. Is it OK with you?
Btw. letter in the brackets after the button label does not impress me much. There isn't any better way? Just a question. If not, we have no choice... |
|
|
|
hbernard
|
|
2005-03-06 21:21
|
|
- Because this is BC, we can just wait for translators for other languages. It s OK for me. + an anouncement and a related bug report like we did for the goto stuff.
- the letter in the brackets :
my initial patch was using the <button> tag, which allows theorically to put HTML as text into the button. (so I was able to underline access key)
allas, this is well handled by firefox. but not by MSIE, AFAIK.
I suggest to have a global flag in the display array to allow users to disable the feature (I agree, brackets are not very smart). |
|
|
|
|
What does it mean that MSIE does not suport this? Is there something significantly broken or text letter is just not underlined?
If so we can ignore MSIE silently as it can follow the standards and not annoy the developers :-) |
|
|
|
hbernard
|
|
2005-03-08 21:03
|
|
AFAIR, it was more than something that we may silently ignore.
But I will give it another try, and make a patch up2date against current cvs.
For the global API, my proposal is :
$opts['display']['access-key-show'] =(boolean)
... for making _visible_ the access-key or not.
$opts['display']['access-key'] =(boolean)
... for activating the feature or not. |
|
|
|
|
|
The second one is clear for me. The first one will control the used approach? If "false" old aproach will used, if true new with letter in brackets will be used. Right? |
|
|
|
hbernard
|
|
2005-03-09 06:51
|
|
yes, the first one is just a usuability flag.
$opts['display'][ 'access-key-show'] =true:
...means brackets on buttons and <u></u> tags in fields names
Another maybe nice possibility is to use the $opts['navigation']
if you want to display underlined access-keys inside the buttons,you just put 'A' into.
if you want to display brackets around access key, you just put 'R' ?
I'm trying to find an API which could allow the use of the <button> tag if possible (mozilla/opera user-base). |
|
|
|
hbernard
|
|
2005-03-12 22:29
|
|
uploaded a new patch
the new global API is put in $opts['navigation']
'K' => Enable access keys
'L' => underLine access keys in buttons (and use <button> tag...)
'R' => put the access keys in buttons inside brackets
the rest of the API didn't change. |
|
|
|
hbernard
|
|
2005-03-12 22:35
|
|
it's possible to have much more access key for
- tabs
- columns in list mode
however, I first need to know what you think of this patch |
|
|
|
|
|
I think this is OK, except fact, that 'K' is completely not neccessary. You can have nothing, or 'L', or 'R', or 'L' with 'R' as well. |
|
|
|
hbernard
|
|
2005-03-13 11:39
|
|
[note that the patch is not _ok_, there are some things to be cleaned]
the'K'stuff is there to allow to have access keys working without brackets and without <button> tag. It allows to make access key working on browser that don't honor the <button> tag, without the hidous brackets. |
|
|
|
|
|
Oh yes, nice catch! I agree. Let me know when patch will be ready for review. |
|
|
|
|
|
hbernard, did you have a time to work on this? |
|