Summary: | shift key may not be the alphabet in uppercase in all languages | ||
---|---|---|---|
Product: | [Applications] ktouch | Reporter: | Vivek <vivek.rai> |
Component: | general | Assignee: | Andreas Nicolai <Andreas.Nicolai> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | sebastian.gottfried |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 2.0.0 | |
Sentry Crash Report: |
Description
Vivek
2005-12-19 19:24:55 UTC
Interesting suggestions, I will incorporate them into the new concept for the reworked keyboard drawing engine for the next major release version. Hi Andreas, Thanks for your reply. I had developed a quick (javascript based) keyboard tutor which stores upto 4 unicode charaters per key, and prompts for the appropriate modifier, (0= no modifier, 1=Shift, 2=Alt Gr, 3= AltGr + Shift) depending on the index of the next character from the lession. Let me know if you want to have a look at it, it is not at a "fully finished" state, but serves well to illustrate what might be really handy for many languages. Cheers, Vivek On 5 Apr 2006 05:03:26 -0000, Andreas Nicolai <Andreas.Nicolai@gmx.net> wrote: [bugs.kde.org quoted mail] This sounds like something I had in mind for the new keyboard engine. Currently two design are proposed: 1. whenever a modifier key is pressed, the keyboard shows only the accessible characters 2. the keyboard shows all characters always (like in the Bangla keyboard) but highlights the currently active keys (with a colored shadow or something like that) Looking from the "character to type" point of view, each character would require knowledge of necessary modifier keys. That's at least how far I got in the design process. I'll keep you updated... Fixed in version 2.0.0: no special rules for shift keys anymore: instead all characters on key indicate their associated modifiers. |