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

Adding another physical keyboard arrangement. #23

Open
HughP opened this issue Oct 4, 2018 · 2 comments
Open

Adding another physical keyboard arrangement. #23

HughP opened this issue Oct 4, 2018 · 2 comments

Comments

@HughP
Copy link
Contributor

HughP commented Oct 4, 2018

@michaeldickens

I'm trying to add another Physical keyboard "model" to Typing. I am trying to add an ISO keyboard. Following up on #16

Directions for this are provided in README.md. Never-the-less, I still have some questions.

  1. I have been looking at the iPhone layout as a sort of model for adding another keyboard layout. The iphone layout is in the code base but seems to be undocumented in the application documentation as an option. No doubt with intent. to that end I make the following comments and observations:

tools.c @ line 61-64 seem to not list iPhone. This makes me confused in the case of step number 4 in the README.md file, where it says to add:

strcpy(keysToInclude, DEFAULT_KEYBOARD_BINARY);

but I think what I would want to add would be something more like the following, am I correct on this?

else if (fullKeyboard == K_IPHONE) strcpy(keysToInclude, DEFAULT_KEYBOARD_IPHONE);
else if (fullKeyboard == K_ISO) strcpy(keysToInclude, DEFAULT_KEYBOARD_ISO);

I am also confused because it seems that the directions in step 4 suggest to add the content in the function initKeyboardData(); , but if I add my above suggested lines at about line 63 then two lines later is where initKeyboardData(); is called. Are the instructions meant to say initData() instead of initKeyboardData(); ?

  1. is it the nature of the arrays for fingerCopy, rowCopy, homeRow, handCopy, isCenterCopy, isOutsideCopy, printItCopy, indicesCopy, that they need to be of equal lengths? that is the ISO keyboard layout would ordinarily just add a key to the row above the thumb row (row A in ISO9995 parlance) and move key D13 to the C12 position. Do I need to add values to each row in the array to keep them "happy" (all the same length), or can I just add one value in each array on the row which corresponds to the row above row 3?

  2. Tools.h @ line 66-68 does not have an iPhone layout defined Why? Does this mean I do not add an ISO layout mention at this position?

  3. In Tools.c, near the end, kbdFilename is NULL for K_IPHONE:
    case K_IPHONE:
    ksize = 30;
    trueksize = 26;
    kbdFilename = NULL;
    break;

The instructions in the README.md don't exactly suggest what needs to be done with regards to the value of kbdFilename, or trueksize. Should I follow the pattern set forth by K_NO and K_Standard?

@michaeldickens
Copy link
Owner

Note that I haven't touched this program in about 5 years so I've forgotten a lot of stuff.

  1. You do want to update tools.c in the way you described, I think the reason it's not there for iPhone is because I started adding support for the iPhone keyboard but then stopped partway through. I think you need to update both initData() and initKeyboardData().
  2. Yes the arrays need to be the same length. Notice that the size is set by KSIZE_MAX. The way this is written is not super extensible. If you want to add a new keyboard that's bigger than the biggest keyboard, you need to increase KSIZE_MAX and then update all the existing keyboards accordingly, which could be tricky.
  3. iPhone keyboard is not defined here because it's only partway done. You need to define a default keyboard that gets populated when the layout optimizer initializes a new layout.
  4. Same as before, I didn't finish the implementation so iPhone is missing some stuff.

The instructions in the README.md don't exactly suggest what needs to be done with regards to the value of kbdFilename, or trueksize. Should I follow the pattern set forth by K_NO and K_Standard?

Yeah, your best bet is to look at what the existing keyboards do and try to replicate that. Ideally it would be easier to add new keyboards, but that would require refactoring a lot of stuff.

@HughP
Copy link
Contributor Author

HughP commented Oct 14, 2018 via email

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

No branches or pull requests

2 participants