Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support customizable key layouts? #13

Open
GoogleCodeExporter opened this issue Jan 22, 2016 · 34 comments
Open

Support customizable key layouts? #13

GoogleCodeExporter opened this issue Jan 22, 2016 · 34 comments

Comments

@GoogleCodeExporter
Copy link

It would be useful if users could customize the key layout, for example 
switching keys around or modifying the contents of the popup mini keyboards.

This is a bit tricky since the current XML-based keyboard definitions aren't 
really designed to be modified at runtime, they are compiled into static 
resources and saved in the APK at build time, and they have some 
interdependencies including indirections pointing to separate string resources. 
See for example: 
http://code.google.com/p/hackerskeyboard/source/browse/java/res/xml/kbd_full.xml

Also, there needs to be a way to save or load modified layouts, but I don't 
want to add Internet access permission for the keyboard, and would prefer not 
to have to use SD card access permission. I'm thinking about some other 
alternatives to handle this.

Original issue reported on code.google.com by Klaus.We...@gmail.com on 26 May 2011 at 1:58

@GoogleCodeExporter
Copy link
Author

AnySoftKeyboard supports seperately-installed layouts ("language packs"). Since 
it appears to be licensed under Apache License v2.0, as does Hacker's Keyboard, 
there should be no legal problem taking the code from there. This would not 
allow editing layout on the Android device, but would allow layouts to be 
downloaded from Android Market.
http://code.google.com/p/softkeyboard/

Original comment by k...@bijna.net on 6 Jun 2011 at 5:25

@GoogleCodeExporter
Copy link
Author

I'll take a look to see if it's feasible to integrate those, but I'm a bit 
short on time to work on the project at the moment so it may take a while.

Original comment by Klaus.We...@gmail.com on 6 Jun 2011 at 5:50

@GoogleCodeExporter
Copy link
Author

I'd like to state my interest in this feature.  I can understand why it would 
be difficult to implement, however :)

Original comment by kaishi.a...@gmail.com on 7 Jun 2011 at 2:05

@GoogleCodeExporter
Copy link
Author

...and my axe!

Original comment by ripp...@gmail.com on 30 Jul 2011 at 6:57

@GoogleCodeExporter
Copy link
Author

On a phone, I switch to landscape mode when I need to type something more than 
a few words/lines. Larger buttons means a little more accuracy.

It would be convenient to be able to switch to a layout mode which offers large 
buttons at the cost of fewer buttons on screen.

Maybe you could have a, built into apk, library of useful custom layouts 
instead of allowing users to customise at runtime?

Original comment by jcho...@gmail.com on 28 Aug 2011 at 5:06

@GoogleCodeExporter
Copy link
Author

agreed.. unfortunately in landscape mode this keyboard is only useful in 
connectbot as I will gladly go more slowly to gain all these keys.. but for a 
text msg or something i need large keys for its not practical. 

Original comment by tgwa...@gmail.com on 30 Aug 2011 at 8:56

@GoogleCodeExporter
Copy link
Author

Issue 71 has been merged into this issue.

Original comment by Klaus.We...@gmail.com on 26 Sep 2011 at 10:26

@GoogleCodeExporter
Copy link
Author

I think it would be useful to also support special keys as alternates, for 
example adding Home/End as alternates to the arrow keys. The current 
string-based alternates don't support that, but the new system ought to be more 
flexible.

Original comment by Klaus.We...@gmail.com on 29 Sep 2011 at 6:56

@GoogleCodeExporter
Copy link
Author

FYI, I'm starting to make progress on this, I have a partial implementation for 
layout definitions based on simple text files with whitespace-separated entries 
as a replacement for the XML files. It's currently looking something like this:

title   English (Dvorak)
#
key_tlde        `       ~       ` ~
key_ae01        1       !       1 ! ¡ ¹ ½ ⅓ ¼ ⅛
key_ae02        2       @       2 @ ² ⅔
key_ae03        3       #       3 # ³ ¾ ⅜ ♥ ♠ ♦ ♣
key_ae04        4       $       4 $ ⁴ ¢ £ € ¥
key_ae05        5       %       5 % ⅝ ‰
key_ae06        6       ^       6 ^ ↑ ↓ ← →
key_ae07        7       &       7 & ⅞ ♪
key_ae08        8       *       8 * • ★ ∞ † ‡
key_ae09        9       (       9 ( √
key_ae10        0       )       0 ) ⁿ °
key_ae11        [       {       [ {
key_ae12        ]       }       ] }
#
key_ad01        '       "       ' " ‘ ’ “ ”
key_ad02        ,       <       , < ≤ « ‹
key_ad03        .       >       > ≥ » › …
key_ad04        p       P       4 π ₱
key_ad05        y       Y       5 ý ÿ ¥
key_ad06        f       F       6 ₣
key_ad07        g       G       7
key_ad08        c       C       8 ç č ć ¢
key_ad09        r       R       9
key_ad10        l       L       0 £ ₤ λ
key_ad11        /       ?       / ? ¿
key_ad12        =       +       = + ≈ ≠ ± × ÷
key_bksl        \       |       \ |

(Please don't start making definitions based on this, it's a work in progress.)

This'll be much easier to maintain, and lets me explicitly load specific 
layouts on the fly, and I no longer need to deal with the current 
hard-to-control resource loading mechanism that auto-loads from alternates 
directories based on the current locale.

The main improvement is that I can then define keyboard templates (specifying 
sizes and number of keys) separately from the layout map (assigning glyphs to 
keys), this provides far more flexibility.

More later, hopefully I'll have a functioning prototype soon.

Original comment by Klaus.We...@gmail.com on 30 Sep 2011 at 7:22

  • Changed state: Started

@GoogleCodeExporter
Copy link
Author

Issue 73 has been merged into this issue.

Original comment by Klaus.We...@gmail.com on 4 Oct 2011 at 7:09

@GoogleCodeExporter
Copy link
Author

Issue 43 has been merged into this issue.

Original comment by Klaus.We...@gmail.com on 31 Oct 2011 at 1:36

@GoogleCodeExporter
Copy link
Author

Issue 105 has been merged into this issue.

Original comment by Klaus.We...@gmail.com on 4 Nov 2011 at 8:56

@GoogleCodeExporter
Copy link
Author

Issue 118 has been merged into this issue.

Original comment by Klaus.We...@gmail.com on 6 Dec 2011 at 9:10

@GoogleCodeExporter
Copy link
Author

Issue 130 has been merged into this issue.

Original comment by Klaus.We...@gmail.com on 19 Dec 2011 at 6:17

@GoogleCodeExporter
Copy link
Author

Issue 148 has been merged into this issue.

Original comment by Klaus.We...@gmail.com on 8 Jan 2012 at 9:17

@GoogleCodeExporter
Copy link
Author

Issue 172 has been merged into this issue.

Original comment by Klaus.We...@gmail.com on 21 Jan 2012 at 2:23

@GoogleCodeExporter
Copy link
Author

Any news on this ? I'd really be interested to start working on a Swiss-French 
(ou Luxembourgish) Layout ;-)

Original comment by yank555...@gmail.com on 23 Mar 2012 at 11:12

@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

Sorry, I haven't had time to work on it due to being too busy. It's still on my 
roadmap, but I'll need to find some continuous blocks of time to make progress 
- it isn't feasible to make such large changes in 5-minute blocks.

In the meantime, I can add language/country layouts based on the XML templates 
if I get the needed changes as contributions, see the 
http://code.google.com/p/hackerskeyboard/wiki/AddingNewLayouts page for 
details. If there's already a similar layout as a starting point, you can use 
the "Edit file" link in the project source section to make changes. This will 
prepare a patch for me to integrate. For example, here's the German QWERTZ 
5-row layout: 
http://code.google.com/p/hackerskeyboard/source/browse/java/res/values-de/donott
ranslate-keymap.xml

(FYI, I already have automated conversion code mostly working, my goal is that 
all current layouts will continue to be available after the migration to the 
new layout definition format.)

Original comment by Klaus.We...@gmail.com on 24 Mar 2012 at 1:32

@GoogleCodeExporter
Copy link
Author

I'd like this feature too, for example on the French keyboard, we have some 
keys which are directly accessibles (; !), but not very useful on a phone. And 
some are missing in direct access, such as @ or . (dot).

Original comment by eforg...@gmail.com on 17 Apr 2012 at 12:05

@GoogleCodeExporter
Copy link
Author

Please add the Swiss-German Layout, please, please

Original comment by hansi...@gmail.com on 14 Aug 2012 at 9:28

@GoogleCodeExporter
Copy link
Author

[deleted comment]

1 similar comment
@GoogleCodeExporter
Copy link
Author

[deleted comment]

@GoogleCodeExporter
Copy link
Author

I'd like to see user cusomization enabled too - though more specificallly 
having tab / colon / cursors / full stop all accesible from the 'aplha' 
keyboard in portrait mode - these are the keys I really use loads in connectbot 
- but without changing to a full 5 row layout. I guess toggling from the alpha 
keyboard to a cusomizable one is what I'm after.

As it stands it's still a great keyboard and on a Nexus 7 the five row layout 
in portrat is great with connectbot - really couldn't do without it!!

Original comment by jones...@gmail.com on 25 Jan 2013 at 8:47

@GoogleCodeExporter
Copy link
Author

I'd like to see some progress here... my first Android, a transformer, is on 
order, so I was looking for Dvorak remapping. Sounds like you have it, hope it 
works with the dock keyboard too.  But I'd like to add some deadkey support to 
the standard Dvorak layout (unlikely to already be there...) so this issue 
seems to be relevant. I'll likely be able to survive the first while with plain 
Dvorak, but am curious about progress on this issue.

Original comment by v...@g.nevcal.com on 27 May 2013 at 2:42

@GoogleCodeExporter
Copy link
Author

I am in the process of creating a keyboard layout that, while still English/US, 
has some slight changes to have a more grid-like layout, similar to physical 
thumbpads on mobile devices, e.g., "A" directly underneath "Q" instead of 
offset between "Q" and "W."

How would I name this layout so that it does not interfere with existing 
layouts? I am hesitant to allow anything to replace a stock EN-US QWERTY.

Original comment by QueenCan...@gmail.com on 15 Oct 2013 at 6:45

@GoogleCodeExporter
Copy link
Author

It is my understanding that the issue here refers to the keyboard layout in the 
sense of assignment of keys to chars, not really about shape and placement of 
keys themselves. Would it be possible to make 'grid-like' layout a global 
preference, that would work transparently with all language layouts?

Original comment by fkru...@gmail.com on 16 Oct 2013 at 8:23

@GoogleCodeExporter
Copy link
Author

unsubscribe me

Original comment by kasatkin...@mail.ru on 16 Oct 2013 at 2:51

@GoogleCodeExporter
Copy link
Author

Has there been any progress on this?

What I would really like to see is a way to specify which keys are displayed. 
I'm primarily interested in the main qwerty keys and the arrow keys, and am 
willing to forgo the use of the [, ], /, etc. to gain the larger display of the 
rest of the keys. The forgone keys could be displayed via long press.

I've been using swiftkey, with a row of keys on the bottom and the main qwerty 
keys, with the rest of the symbols accessed via long press. However the arrow 
keys consume too much screen space, and the keyboard takes over 50mb of RAM, 
which on my old phone with very little ram, means a lot.

Original comment by neodimiu...@gmail.com on 19 Oct 2013 at 2:18

@GoogleCodeExporter
Copy link
Author

I am working on the assumption that, for other languages to allow more keys 
than just A...L in the middle row, I'd just need to add in an extra key 
definition in the right places. (This is just my guess. I really have no idea 
what I am doing; I'm really just changing things in files and hoping for the 
best.)

Original comment by QueenCan...@gmail.com on 19 Oct 2013 at 5:41

@erikcgwilson
Copy link

G'day, Klaus. Just started using your keyboard: bloody beauty!
Any progress on the idea expressed January before last yet? I would love to be able to use some of these.
title English (Australian)

key_tlde ~ ~
key_ae01 1 ! 1 ! ¡ ¹ ½ ⅓ ¼ ⅛ x y z
key_ae02 2 @ 2 @ ² ⅔ # . \ }
key_ae03 3 # 3 # ³ ¾ ⅜ ♥ ♠ ♦ ♣
key_ae04 4 $ 4 $ ⁴ ¢ £ € ¥
key_ae05 5 % 5 % ⅝ ‰
key_ae06 6 ^ 6 ^ ↑ ↓ ← →
(or something!)

@airdrik
Copy link

airdrik commented Mar 20, 2017

Looks like they imported the project over from Google Code last January, so any work from before then will be dated January 22, 2016. You have to look at the date mentioned in the "Original Comment" line at the bottom of the comment.

In any case, I would love to see more android keyboards supporting "DIY" or Custom layouts. This is one of my favorite features of Multiling O Keyboard. My current custom layout, optimized for right-handed swyping, features numbers on the left side, letters on the middle and right, organized for optimal swype performance (more common letters in the middle, common letter combinations close together).

Looks like Hackers keyboard has the support in the form of an xml layout definition, but there are/were plans to implement an easier to use plain-text layout definition. That would certainly make it a lot easier to design your own layouts (without a little scripting assistance to translate whatever into xml)

@shshamdani
Copy link

Hello Klaus,

what is the current state of affairs regarding the transition to a different keymap definition format?

I would like to improve upon the Farsi keymap as it is missing some critical aspects for typing typographically correct Persian. Also it could easily be extended (in the sense that an English keyboard layout is extended with letters with diacritics) to cover Pashto as well. That would make it an attractive layout for "us Afghan users" who are bilingual.

If the old XML format is still the way to go, please let me know because then I'll work on that for the time being.

@memetg
Copy link

memetg commented Jun 14, 2017

Eagerly waiting for this feature to be implemented. It looks like what you call custom layouts are technically translations of english strings to other languages. So I changed the values for my language and made include non-english characters from several languages (like ñ, ø, ß, and many more; I used apk-editor to do that) The only problem is that the app is now built with a different signature and I won't be able to update it (or I'll have to remove it, install the updated original, change the strings, remove it again and re-install the modified again and configure the settings again, which is not the shortest way to update an app).
Maybe you can simply add more alternatives to "key_****_alt" (i.e., alternative keys) by default before the implementation of custom keyboards are completed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants