QuadGMoto's Programmer Layout

Discussion in 'Firmware' started by QuadGMoto, Jul 3, 2014.

  1. davidaciko

    davidaciko New Member

    I was also a bit worried about the diamond shape... AcidFire, just throwing this out there as something to consider, but what if the left/right keys in the diamonds were extended downward by 1.5 so the keys form this configuration:

    __UU__
    LLUURR
    LLDDRR
    LLDDRR

    Because then it could be used as an inverted T or as a diamond just depending on where you rest your fingers. Again, it's just an idea rather than a request.

    Edit:
    I just got the idea to turn my current keyboard sideways to test a diamond-shaped cluster of J=up, K=down, I=right, and M=left, and it didn't feel unnatural at all. Never mind then about extending the keys [=


    QuadGMoto and jeep (and probably everyone else here), I'm totally going to steal parts from your layouts -- I hope you don't mind [=
    Last edited: Jul 5, 2014
  2. jeep

    jeep New Member

    My top secret layout that I posted on a public forum for an open source keyboard!?! How dare you! ;)

    I'm happy to share. ;) I'm not sure that my layout is even possible without completely custom firmware. The -/9 and _/0 keys require very special treatment, as will the braces and parens keys. Since they need to send different key codes based on the shift. I've been considering not using "shift" and instead having it take you to a new layer AND send a shift. Again, to do that, I'll probably need to customize the firmware, so...
  3. QuadGMoto

    QuadGMoto New Member

    I don't mind at all. It's not even like I could stop you. ;)

    Just be aware that I'm not yet confident that it's a good layout in all respects.
  4. myrddin

    myrddin New Member

    I found shift on thumb cluster to be a big improvement to my typing habits, otherwise I tend to sit my left hand on the shift|a|o|e keys, rather than a|o|e|u
    Last edited: Jul 6, 2014
  5. AcidFire

    AcidFire I Make Stuff Staff Member

    I don't think you'll need to customize the firmware jeep, this is something I've already been looking at. Speaking of layouts, I'm nearly done a tool that'll not only let you build a layout, you can share the layout in the editor and share an image on the forums (or anywhere else) of that layout :D
  6. davidaciko

    davidaciko New Member

    Thanks everyone [=

    AcidFire, that's great! I'm having trouble with Inkscape anyway -- I can't get it to show the "↹" (U+21B9) symbol in a text box no matter what I do.
  7. AcidFire

    AcidFire I Make Stuff Staff Member

    Unfortunately it will be a bit limited symbol wise to start, since it would be a bit time consuming to impliment images (I'm currently converting the SVG into a sharable PNG) so it's very similar to the current Ergodox layout builder, but once the campaign's up I'll add proper symbols.
  8. jeep

    jeep New Member

  9. davidaciko

    davidaciko New Member

    Will I be able to do something like have a "LOCK" key where I hold down one or more modifiers and hit "LOCK" and then all the modifiers I was holding are locked until I hit the "LOCK" key again (but with no modifiers held down) to unlock?

    Edit:
    jeep, that's a cool site! Here's a blank template I made for the Axios on the site jeep posted if anyone wants one: http://www.keyboard-layout-editor.com/#/layouts/d177f2e8377b68c98799a4340a77854a
    But there's a bug or something going on where the right thumb cluster will not save correctly -- just select the keys and press the up arrow 8 times to "fix", but when you try to save your layout it will probably push them back down by 2.00 key widths... whatever.
    Last edited: Jul 7, 2014
  10. Koren

    Koren New Member

    I'm maybe waiting even more eagerly for the firmware sources than for the keyboard itself (and I'm waiting for the keyboard A LOT). I'm really curious to see what kind of tricks you managed to pull with the firmware.

    I must say I've begun writing my own firmware* but I'm still working in the dark as long as I don't exactly know how I'll be able to read the actual keystrokes... or even which compiler toolchain I should use.

    Do you know when you'll release the firmware sources?

    * mostly because I'm pretty sure they'll be a couple of things you won't want to implement in the official firmware... and I'm really excited to be able to program the keyboard a bit, having already played much with leonardo. For example, I'd like to be able to add:
    - "intelligent closure" for (, {, [ and "
    - in-keyboard password generation
    - a dual translation scheme from keystroke to keycodes (to be able to choose, for the keyboard, both the layouts and a translation page to handle a computer for which the installed keyboard can be different)
    davidaciko likes this.
  11. AcidFire

    AcidFire I Make Stuff Staff Member

    That wasn't a default behavior but I like the idea. I've added it to the feature list for v1.1 of the firmware.

    The first sources will be made available when the beta testers get the first batch of boards to work with. I really like the intelligent closure idea, though I'm not sure how you'd implement it (unless a } would immediately follow a {, for example), and could be implemented as a predefined macro in the software that can be assigned.

    I'm not sure how useful in keyboard password generation would be, given that some sites still have particular requirements for what you're generating (mind you, those sites should be avoided like the plague). But I'll be interested to see your implementation.
    davidaciko likes this.
  12. Koren

    Koren New Member

    I agree that it would be a nice feature.

    That's pretty straightforward, actually. I would add a small stack (lifo) into the firmware.

    When you press any key that type any character among { ( [ and " (maybe a couple others, but those are the most useful for programming), the opposite character } ) ] or " is also pushed on the stack.

    When you press the "closure" key, if the stack is not empty (the pointers are different), you pop the character on the top of the stack and send the corresponding keycode. And beep or flash if the stack is empty.

    Of course, it's not perfect (it only work as long as you're typing normally, not when you're editing) but I type enough complex expressions where I'm lost about what I need to close to find even this simple solution useful.

    This one is a bit more tricky (and probably more a way for me to think about what can actually be done in a keyboard, but I would actually find it useful)

    In short, there's a small buffer in the keyboard "RAM" that can store a seed (typically a secret passphrase). You need a key to say "I'm beginning to enter the passphrase" and to say "I've finished" (and obviously, a double stroke will clear the passphrase in RAM, if someone can access the keyboard).

    One the passphrase is set, there's a layout in the keyboard where the keystrokes aren't send anymore to the computer directly, but used to create a password-like sequence of keystrokes.

    The basic idea is to use the stream of keystrokes and the passphrase to create a stream of keystrokes sent to the computer.

    For example, you can first enter a passphrase like "The weather is really nice today". Then when you enter the "password layout", typing "passformycomputer" will produce a sequence of keycodes like, e.g., "aH4ù*@!tF"

    This way, nothing is store in the keyboard itself, so it's secure as long as you clear the passphrase when you leave the keyboard alone. And you can use really strong password without having to remember anything more difficult that the name of the shop or the name of the computer. Or the name of your cat.

    I thought about this because I've been sysadmin for more than two dozen computers, and still am for a dozen, and that means that I usually have to remember more than a hundred strong, unique passwords. I don't want to write them, don't want to use weak passwords (I often use randomly generated ones for the most important ones) and password vaults are not the perfect solution. I already have this kind of "generator" on my calculator but having it directly in the keyboard would be FAR more simple and even safer.


    In short: you made me think A LOT about your keyboard (as I said earlier, except a couple of details, it's really close to what I've been dreaming to build for a couple of years...)
    davidaciko likes this.
  13. AcidFire

    AcidFire I Make Stuff Staff Member

    Interesting. I definitely can see how this could be useful on a "Programmer's Layer", and I can see using it myself. I would be interested to see how we could implement it to manage multiple openings (FIFO?), especially since writing stuff with jQuery I use a lot of {[ ]} and {( )} and have gotten lost a few times.

    Ok, I can definitely see how that would start to become useful (doing IT in the shop I'm in now I could use that sort of thing). I've added it to v1.1 firmware feature list and I'll work with you to get it implemented.
    davidaciko likes this.
  14. Koren

    Koren New Member

    LIFO, actually, to handle multiple openings.
    I don't have the piece of code available, but it's really straightforward. Something like this (should be compiled and checked for bugs, but just as an information):

    ________________________________________________________
    Code:
    # Useful consts (could be hard coded or defines)
    const short closure_buf_bytes = 4 // 2^4 = 16 characters
    const short closure_buf_size = 1 << buf_bytes // so buf_size = 16
    const short closure_mask = closure_buf_size - 1 // so mask = 0x01111
    const short closure_ptr = 0 // First available space
    const short closure_depth = 0 // Currently # of chars in stack
    
    short closure_buffer[closure_buf_size] // list of chars in stack
    
    # Push a (non-zero) value on stack
    void Closure_Push(short value) {
        if (!value)
            return;
    
        closure_buffer[closure_ptr] = value;
        closure_ptr += 1;
        closure_ptr &= closure_mask;
    
        if (closure_depth < closure_buf_size)
            closure_depth++;
    }
    
    # Get value on top of stack, or 0 if empty
    short Closure_Pop() {
        if (!closure_depth)
            return 0
    
        closure_ptr += closure_buf_size-1;
        closure_ptr &= closure_mask;
        closure_depth--;
    
        return closure_buffer[closure_ptr];
    }
    ________________________________________________________

    You can call Closure_push( the_caracter_to_push ) when there's a { ( [ " typed and Closure_pop when the closure key is pressed to know which character you have to push.

    There's a small trick in using a circular buffer so that if you enter more than 16 opening characters, the oldest ones are dropped so that the newest ones are kept. Other than that, it's pretty basic.
    davidaciko likes this.
  15. AcidFire

    AcidFire I Make Stuff Staff Member

    You're right, not sure why I had it in my head as FIFO. As for the rest, it looks like I should be able to just drop your code into the firmware for testing :D Sending you a PM as well.
  16. jeep

    jeep New Member

    The only thing needed is the trivial function to clear the buffer so you can start fresh and be sure to get everything closed. Would you want to be able to store the pairs on the fly, or is programming them into a layer enough? I can see wanting to turn on/off pairing < with >. I do this in my editor already, but it could be fun to do it in the hardware.
  17. Koren

    Koren New Member

    Actually, there is indeed a clear_buffer function, alongside others (such as a "register" that takes the last two characters and make that a pair, that also play the role of unregister function if the second one is a space.) The above code-snippet was just the fastest way for me to explain the idea.
    I have indeed issues with < and ' because both are used both as delimiter and as something else. Most of the time, I use < > as delimiters in XML-like languages, and the closure is close enough to the opening (and not part of multiple openings) so that I don't loose track as often.

    You can always define two keys for < (delimiter) and < (operator) or a dead-key to specify "don't use it as delimiter", but that's probably to complex to be really useful.

    There's other issues:
    - is it interesting to handle multiple-character delimiters, such as [| |] or LaTeX \left( \right) ? (far less trivial if you want to do it right, mostly because matches may not be unique anymore)
    - shoud the escape sequences such as \" be handled? (not really difficult, but not sure of the best solution)
    - should the ) on top of stack be poped if you type ) directly on the keyboard? (I'm leaning to yes, so you should call Push when you encounter an opening character, but check the top if you encounter a closing character for a possible Pop)
    - should the use of arrow keys, especially up and down, flush the stack?
    etc.

    The good thing is that it's a pretty minor tweak on the firmware, especially if the delimiters are set alongside the layouts, and it can still be useful for some.

Share This Page