I wasn't able to get it to work with the freeware version of Eagle, as the board size is too large for the freeware restriction.
But it looked like it was going to work, after downloading the Kalerator script files!
I ran into the same problem, even when making a 2 switch keyboard that should fit in the build area that I can use the script tries to build it outside of that area.
I forgot that's how the freeware restrictions work. With the paid version you can place components anywhere, but the free version you can only place them in the rectangle starting at 0,0 and ending at 100,{80,150}. I'll have to add an option that translates Y by the right amount to move everything up into the freeware area. Sorry about the oversight!
One thing I'm not fond of is that your generator seems to cache the layouts. When I updated a layout and saved it with the same gist name, it still had the old version in the output from your site. I'm not sure how to force KLE to save it with a new gist name, beyond starting fresh.
Yeah, the cache was initially not a problem at all, as each save got a new hash. I need to revisit that now that that assumption has changed.
So this outputs a PCB with holes for the switches, and a wire matrix. Any chance of adding a controller section by default? An ATmega32U4 and its associated components would be a great choice. Routing that on the PCB might pose a bit of a problem, though, huh?
Putting those components and the right nets on the schematic is easy, but routing them on the PCB not so much. Options for doing this include leaving them in the default position on the board (so the user places and routes them), having a special 2U height key to represent the controller and having a pre-made layout (that would unfortunately also preclude placing any switches in that space,) and just leaving the footprint for a teensy on the board for the user to route to by hand. I don't know yet which way I want to go.
Already done, actually. It assumes that a blank key is named SPACE, and if it encounters a duplicate key is appends _DUPE to the name. If you have 3 or more copies of the same key you could end up with _DUPE_DUPE, _DUPE_DUPE_DUPE, ad infinitum, but I figure that makes it easy to spot and gives the user a chance to fix it.
Can I suggest a different system? Or at least an option for a different system?
First, it would be great if there was a way to designate a key as the space.
Second, it would be nice if you allowed other non-labeled keys to be auto-numbered instead of adding DUPE to each one. Maybe something like A0, A1,A2...A9, B0, etc...
That might make it easier to navigate, and allow coding of keys that don't have set labels.
You can designate space however you want, it's just a text label.
If you leave a key blank it assumes that key is SPACE, but if you wanted something else (like SPC, or SPAAAAACE) you can just put it in yourself.
Before I talk about how we designate duplicates, I want to clarify something. The duplication logic applies to any key, not just unlabeled keys. If you have two Shift keys, for example, one will be called SHIFT and the other SHIFT_DUPE.
I definitely get where you're coming from on identifying duplicates, and how adding numbers might be nicer in some cases. I'll think about whether it's something I can support. The way I'm thinking about it right now is that KLE is the source of truth, and so the user should make that reflect their intentions as much as possible. Using _DUPE as my identifier makes it obvious that this key is different (since the line will be significantly longer than surrounding keys) and also makes it easy to Ctrl-F to find dupes.
If most people look at that differently I can change how that works.