| Summary: | Please add gui settings support for disabling access keys | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | Anders E. Andersen <andersa> |
| Component: | general | Assignee: | Konqueror Developers <konq-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | bluedzins, cwiesen, dev, ermonnezza, jakubpol, jjm, kde-bugs, lex.lists, vapier, wildlife |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Add option for access keys to kcontrol | ||
|
Description
Anders E. Andersen
2006-03-25 07:26:13 UTC
KDE 4 will have this. *** Bug 125825 has been marked as a duplicate of this bug. *** *** Bug 90808 has been marked as a duplicate of this bug. *** *** Bug 90808 has been marked as a duplicate of this bug. *** It looks like the same problem is comming in other applications like Kmail too. It won't be added until KDE 4? It makes Konqi USELESS! Even entering THIS form, the page incorrectly activated form elements while i was typing and i had to re-enter this text 3 frigging times! "Active Keys" is a BUG, not a feature! Also, it would be nice to have the functionality to disable the automatic accesskeys, so as to only use those accesskeys defined by the website. According to the documentation it only works using site-specific accesskey settings, but this appears to be incorrect: "The proper use of this feature requires that the web designer of the page has specifically assigned, using the accesskey attribute, an access key for the link. Many web designers might not include the accesskey in their links and forms, and consequently this feature will be unusable on the given webpage." The fact is, however, that automatic access keys makes any form-using page unusable. Actually.. I don't really see why it should make form using page unusable. I use plenty of websites with form content and they work fine. For example, on this page: i'm typing to fill in this form field, then the access keys kick in by themselves (without me tapping ctrl). Then one of the letters i type takes me to another form field, and my typing continues in that field. This happened on every form-using page i've used until i learned about the Enabled=false setting in khtmlrc. Had i not found out about that setting (here in the bug db) i would have switched to Firefox rather than continue to fight with konqueror. There must be something else wrong at your end. I have never seen the access key boxes activate 'by themselves'. It only happens when I press ctrl. In response to comment 10 -- I agree with Anders. I have not seen that problem myself, although I don't use Konqueror full-time. This doesn't dilute the importance of this bug though. I feel it's important to have a GUI-like configuration tool for all config-file options. Waiting for KDE 4 isn't terrible, even though this is a minor feature request. To comment #11: i can't tell you why, but the access keys turn on by themselves and off when i tap ctrl. Then, a few seconds later, they turn themselves on again (they also turn on if i tap ctrl). When i'm typing, this automatic activation causes my keystrokes to go to some other arbitrary form element when i tap one of the mapped active keys. i'm using KDE 3.5.1 "Level a" distributed with Suse 10.1. Maybe Suse has patched it to turn them on automatically. In any case, ctrl by itself is probably a bad choice of activation keys because it can be used for copy/paste (e.g.) and a wide variety of shortcuts are mapped to Ctrl-KEY. i would recommend ctrl-space, or similar, which (a) has no default mapping under Konqueror and (b) doesn't have other side effects (e.g. it doesn't enter a space when tapped in a text field). I also have access keys randomly turningo n - it happens without me touchign the k/board at all. This should at the very least be easily configurable. It's mystifying to new users, and it breaks some behavior to boot - I was unable to switch tabs using ctrl-[ or ctrl-, until I disabled Access Keys by editing the rc file. This is a high burden to put on the user; I suppose we COULD wait until KDE4, but should we really have to? Hopefully not. bug 90808 says "please disable access keys per default", however, when I reopen it, Thiago, you reclose it. I beg everyone to vote for this bug in order to show how un-wanted access keys really are. *** This bug has been confirmed by popular vote. *** Access keys suck. They get in the way. They look like a bug. Is it fair to inconvinience a great number of users because just a few have a handicap? I appreciate the fact that some might find this useful, but I really think that enabling this by default is a wrong decision. There is not enough people who benefit to justify it, and when you factor in how annoying it is for those who don't need it, I really don't get why this is enabled by default. Since I've been insulted for arguing against this feature in the past, I'd be content with a mere gui option to disable it manually - so this bug report has my vote. 3 comments: - it should be configurable through the gui - it should be enabled by default because (provided it's configurable through the gui): it's no problem for a non-handicapped user to disable the feature, but it most likely is a problem for a handicapped user to enable it. - the automatic activation without hitting ctrl is a bug, and while it is definately annoying, the right reaction is fixing the bug, not disabling the feature all together. As to a gui to disable it, how about popping up a little dialog the first time the feature is activated that explains what the feature does (as lots of people seemed to be confused by it) and offers the possibility to disable it? This is a good feature for people who don't like using the mouse. I really like this feature a lot along with the Vim navigation key feature. Please don't scrap it. At most, just have an option to disable this feature for people who don't like it. Created attachment 20069 [details]
Add option for access keys to kcontrol
It's starting to really annoy me, too. Here's a patch that adds a GUI
option to kcontrol - Regional & Accessibility - Accessibility - Modifier Keys.
Just to note that this un-asked-for activation also happens under KDE 3.5.6 on [K]ubuntu 7.04. It doesn't happen on ALL form-using pages (e.g., it doesn't happen on this page unless i tap CTRL), but does happen on some pages without any CTRL activation. Again, the konq documentation states that a web page must explicitly enable access keys for this feature^H^H^H^H^H^H^Hbug to activate (but that's not what's happening), and IMO that is the right behaviour. In that scenario it is removed from Konq's default behaviour and the web designers who want it can enable it themselves. :D I think it's besser to allow the user to change the key shortcut. Now it's always Ctrl and this action doesn't appear under "Configure shortcuts", so it can't be changed to "right Ctrl", "AltGr" or something which doesn't interfer so much. If the shortcut can be changed, then disabling the "feature" is trivial: just assign it no key. *** Bug 160992 has been marked as a duplicate of this bug. *** FIXED in KDE4. This is done in KDE 4.0 already. I agree, it's so annoying, and dangerous, it should be off by default, and changeable in the gui settings. Access keys seem to turn on "by themselves" when xine is on, for example, as xine generates ctrl key press events to keep the screensaver from popping out. So if you listen to the radio while surfing it's a nightmare. I don't understand why this bug is considered closed, as it is apparently solved in KDE4. How many people are using 4 already? I use konqueror 3.5.8 and stll see no gui settings for access keys, not even under the Accessibility settings. |