Online Keyboard Layout Editor

[ne0phyte]

I think working with a canvas isn't too different from other languages, but so far I only used JS for small experiments which never had enough code to get me thinking about structuring it (like this http://ne0.cc/google/ for example ).

Are you sure that a multiline key in a rowbased data structure won't cause more problems/efforts? You can easily implement the behaviour of rows on a grid (filling gaps and moving keys together on move/remove).

The code could even stay row based for simple layouts, but I planned to change the way to store and handle the layout internally to a grid based one.

[gotbadger]

Are you sure that a multiline key in a rowbased data structure won't cause more problems/efforts? You can easily implement the behaviour of rows on a grid (filling gaps and moving keys together on move/remove).

Not sure yet we shall see!

Project is still rough as hell and has some issues but using the code:

Code: Select all

Num::1  /::1  *::1  -::1$$  7::1  8::1  9::1  +::1,2$$  4::1  5::1  6::1$$ 1::1  2::1  3::1  ent::1,2$$ 0::2  .::1

we can make a keypad


Will put the code up once i get the layout/parser working properly

[webwit]

I think working with a canvas isn't too different from other languages, but so far I only used JS for small experiments which never had enough code to get me thinking about structuring it (like this http://ne0.cc/google/ for example ).

I clicked the link in my Firefox, then opened Chrome expecting Firefox to be humbled, but Chrome shows lower fps. Damn ad sellers.

[gotbadger]

Made some progress and you can now do ISO/L shape Key layouts no problem. I also changed the encoding to match the later version used by ne0phyte. Unfortunately currently my layout algorithm is terrible so it takes 1-3sec to render a full size kb



There are still some text rendering bugs but since i said i would share code once the parser was working:
https://github.com/gotbadger/DTKB

Next step is to add some gui elements to allow you to make your own keyboards. Then go back and sort out the layout algorithm.

router.js contains some other sample layouts.

[ne0phyte]

Nice, I will have a look at it later today.
My two texst rendering methods are rather hacky (I wrote them at school and didn't test them much).
I think they don't work too well when you change the font size. I would love to help you with that (well, if you want me to) but I am busy with my final project which is due in about a month + studying for my final exam

[BrytaPlanka]

Spoiler:

Example Layout (click!)

The syntax is really simple:

• " " two spaces are used as separator between keys
• LABEL::WIDTH is used to describe keys *
• $$ begins a new row
• __::WIDTH creates a gap (not drawn)

* if you need a ':' as label just add a space before the '::' (e.g ": ::1")

Ideas to implement:

• Link-shortening
• Highlight syntax errors
• Multiline labels
• Export as image (and serving images to embed them here)
• Multiple layers (either on the legends or by toggling through the layers)
• Easier input (not text based or at least better readability)

Do you think this is something that would be used? If yes, leave your ideas!
Keep in mind that I just started working on it like 2 hours ago

I just tried it. That's awesome!

actually I was working on something similar...

Wow, that looks even more awesome to work with in my opinion.

I have a suggestion if anyone of you are still working on any of these projects. When moving around keys and trying to figure out a good layout, it's easy to forget some key. It would be useful to have a "keys not added yet" or something like that visible somewhere on the side when creating a new layout. So that no letter key is forgotten.

[daybreak365]

Looks great! One thing I noticed is that the key you have labeled as Meta is actually the Super key, and the Alt key should be labeled as Meta.

[ne0phyte]

This isn't dead yet

I didn't work on the newer one that I started from scratch, but the good old ne0.cc/laygen got a minor upgrade!
From now on the old links are being redirected to the new script: http://ne0.cc/laygenV2

Code: Select all

Changes
 + key at the caret is highlighted in the rendering
 + BUILT IN LINK SHORTENER
 + calculation and displaying of center/center, switch hole/switch hole distance
    - mm and inch
    - enter custom values for switch/switch hole width

I implemented the distance calculation for me but maybe someone else finds a use for it, too.

Example: http://ne0.cc/laygenV2/#XOocS

Spoiler:

[ijprest]

This looked like a fun project, and I had been meaning to do a little more web-stuff, so I whipped this up quick:
http://www.keyboard-layout-editor.com/

Not tested too much (and only on Chrome). No drag & drop... you've got to use the edit-boxes to move stuff around. But it's otherwise mostly functional.

Some highlights:
-- Entirely self contained in the ~13k HTML file (except for JQuery & AngularJS).
-- Keys rendered with HTML <div>'s.
-- My "serialized" format (which is JSON) is transformed to an in-memory format (also JSON). The primary difference being that the serialized version is optimized for size, and the in-memory format for rendering.
-- The non-rectangular keys were an interesting problem. I'm not sure my solution is very good... they're definitely cumbersome to edit.

Future work:
-- Some bug fixes / simple usability improvements.
-- Drag & drop to move keys around / resize keys.

[ne0phyte]

Nice to see another one, but most people I talked to on irc found drag and drop to be too slow to use. We're keyboard lovers after all

Also yours seem to have absolute positioned keys with no kind of layouting so it takes even more time to create weird layouts where you move lots of keys around and change it's sizes.

Did you plan to add a layouting algorithm to align the keys automatically? That'd greatly improve the usability but it's not as trivial as I thought it was (I implemented one for any size of key in my new script one that I'm working on).

EDIT:
- when you select multiple keys and change their position they all stack. might be the right behaviour but it's a bit weird when your keys suddenly disappear
- when adding a key it should be inserted next to the selected one

[ijprest]

Also yours seem to have absolute positioned keys with no kind of layouting so it takes even more time to create weird layouts where you move lots of keys around and change it's sizes.

Did you plan to add a layouting algorithm to align the keys automatically? That'd greatly improve the usability but it's not as trivial as I thought it was (I implemented one for any size of key in my new script one that I'm working on).

The in-memory data uses absolutely positioned keys (for ease of rendering the <div>'s); the serialized data is an array of rows (with encoded gaps). I have code to go back and forth, so adding auto-reflow/auto-align functions would be relatively straightforward.

I could also easily expose the serialized JSON format (it's encoded in the URL, at the moment) for easier hand-editing.

when you select multiple keys and change their position they all stack. might be the right behaviour but it's a bit weird when your keys suddenly disappear

Yeah, that's one of the bugs/usability fixes I want to make. I'm hoping to get some more free time on the weekend.

[ijprest]

OK, here's v0.2: http://www.keyboard-layout-editor.com/kb2.html

Mostly stuff to make usability better. (I don't think there are any keyboards you can represent now that you couldn't represent before... it's just a lot easier to create them.)

Changes:
1. Exposed the raw JSON data for easier hand-editing.
-- This is probably the fastest way to add the key labels.
-- Updates after a short delay (i.e., not on every keystroke)
2. Major performance improvements.
-- I was bumping into limits with the number of AngularJS "watches" I had; refactored to bring this down dramatically.
-- I'm learning a lot about JavaScript/AngularJS/JQuery as I go.
3. Can now do a "marquee select" by holding down 'alt' and dragging a marquee rectangle.
-- Alt+Ctrl+drag will "add" the new rectangle to the existing selection
-- Can still Ctrl+click a single key to toggle its selection state
4. When the "keyboard" has focus, the following hotkeys are available:
-- Arrow keys: move the selected keys (and does what you expect when multiple keys are selected)
-- J/K: select the previous/next key
-- Insert/Delete: add new keys, or delete selected keys.
5. No longer sticking the data in the URL address
-- I found this would really bog down the browser when you were updating frequently.
-- There's a "permalink" link at the bottom of the page that can still be used to save/bookmark a layout.
6. Inserting new keys is a little smarter...
-- doesn't just dump them all down the left
-- new key is auto-selected
7. Deleting keys will now automatically select the next key.

[Daniel Beardsmore]

Thoughts:

Is the "kb2.html" required in the URL? I seem to get the same site if I omit that.

Shift-click doesn't select from the previous key clicked, to the one shift-clicked :) If you're going to implement ctrl+click, then shift+click should also work.

You might want to add pellcheck="false" to the <textarea> attributes, to stop your browser showing you a bloodbath of "spelling mistakes"

Increasing a key width doesn't shuffle along all the remaining keys. The controls UI and the JSON have totally different ideas about spacing, with JSON operating relative and the controls UI operating absolute. There's no controls UI way to shift a block of keys across. Also, there is no UI way to set a bigass enter or J enter as you can only load keyboard presets, instead of keycap presets.

Setting the + field of X to 1 instead of 0 is WEIRD. For shift (a wide key) the keys gets wider instead of moving horizontally. For a 1-unit key it leaves a dead key behind, forming a permanent key group. The dead key cannot have a caption. The Y field then only applies to the "real" key, not the dead one. This has got to be broken, as it makes no sense whatsoever. Either way, some tooltips would be useful to remind people what these fields are for, as the controls, the keyboard, and the JSON code all work completely differently and it's not remotely obvious what you're supposed to do with any of it.

There are two colour fields, and changing either one forces the other one to the same value, so that makes no sense. If they can't have separate values, then one of them needs to go.

In terms of colours, ideally you'd have a small palette of entries, where clicking any key then a palette entry would set the key to that palette index. Then maybe:

Code: Select all

{
   meta: { version: 0.3, default_bg: 0, legend: 2 },
   palette: [ #EEEEEE, #CCCCCC, #000000 ],
   rows: [
      [ { l1: "Esc", bg: 1 } ]
   ]
}

Probably the palette would have: Add colour, Edit colour, Remove colour. For example, the two-tone would start out with [ #EEEEEE, #CCCCCC ]. To have a Red esc, just hit Add colour, dial in red, click Esc and then click the new palette entry. This way, you can alter the colours centrally, like with matt3o's colour chooser. The need to set explicit colours on single keys is not a great enough need to have so much fiddly complexity associated with setting primary and secondary colours. (Though perhaps altering a keycap's colour directly would add a palette entry automatically)

Or, if you want to keep the colours on the keys for readability at a cost of duplicated data and more difficult manual entry:

Code: Select all

{
   meta: { version: 0.3, default_bg: #EEEEEE, default_fg: #000000 },
   rows: [
      [ { l1: "Esc", bg: #CCCCCC } ]
   ]
}

bg is background of course; fg is foreground, i.e. legend colour. You may need fg1, fg2 etc if you ever want to allow each legend line to have its own colour.

Clearing the background colour field would draw the default colour instead of black. At the moment, there's no way to have the default background be any colour besides pale grey (not without rooting through all the JSON code and finding all the colour resets and changing them), and the format has no way to indicate to the parser what it should be expecting. If this software is successful, people are going to be plugging in older code with potentially a different data format and causing it to render garbage or crash unless the editor can pick up on the older format and convert it to the latest version and emit newer JSON code into the text box. (You might have to warn the user that the data needs to be rewritten in the newer format.)

It's rather hard to create a succinct data structure and I'm not wholly sure that you want to. For example, it's come at a cost of some keys (those with any parameters) taking up TWO list indices, one for the parameter block and another for the caption, which is just weird. On the other hand, ISO and J enter have no JSON shortcuts, e.g. shape: "ISO Enter". (J enter is a pain as there are so many shapes.)

Finally, I would add 1 px of spacing between keycaps for improved aesthetics. Maybe one day you can add support for simulating cylindrical keycaps ;-)

[Muirium]

Now that's a bug report!

I just gave up right after I couldn't figure how to remove the function row without manual effort.

[ne0phyte]

That's what I meant with "most people I talked to on irc found drag and drop to be too slow to use". Except that this isn't even D&D yet

[ijprest]

Thanks for the feedback!

Is the "kb2.html" required in the URL? I seem to get the same site if I omit that.

I'm currently redirecting to kb2.html.

Shift-click doesn't select from the previous key clicked, to the one shift-clicked If you're going to implement ctrl+click, then shift+click should also work.

Agreed. It's on my list. It's harder to implement, though.

Increasing a key width doesn't shuffle along all the remaining keys. The controls UI and the JSON have totally different ideas about spacing, with JSON operating relative and the controls UI operating absolute.

I'm a bit hesitant to do any sort of *automatic* reflowing, since it would muck up gaps between keys and stuff. A manually-invoked reflow operation is planned, though.

There's no controls UI way to shift a block of keys across. Also, there is no UI way to set a bigass enter or J enter as you can only load keyboard presets, instead of keycap presets.

Setting the + field of X to 1 instead of 0 is WEIRD. For shift (a wide key) the keys gets wider instead of moving horizontally. For a 1-unit key it leaves a dead key behind, forming a permanent key group. The dead key cannot have a caption. The Y field then only applies to the "real" key, not the dead one. This has got to be broken, as it makes no sense whatsoever.

I agree that the secondary width/height/x/y fields are confusing as hell. They're solely used/needed to create the big-ass ENTER keys. (Which *I* created using the UI... though it admittedly took some fiddling.)
-- Each big-ass ENTER key is basically two rectangles.
-- The first "column" of values defines the first rectangle
-- The 2nd "column" defines the second rectangle (with X & Y being offsets from the first one)

I'm open to suggestions for a better representation. I'm not overly fond of this one, myself.

There are two colour fields, and changing either one forces the other one to the same value, so that makes no sense. If they can't have separate values, then one of them needs to go.

Why? It's two different representations of the same data. The text field for people who want to copy/paste color values, and the color-picker for people who want to choose a color visually. (It just occurred to me that you might be using a browser other than Chrome, which might not render the 2nd one as a color picker. So YMMV.)

In terms of colours, ideally you'd have a small palette of entries, where clicking any key then a palette entry would set the key to that palette index.

Interesting idea. I had planned to a picker for SP color swatches, but hadn't considered a palette in the JSON data itself. Makes sense for quick re-styling, and might even shrink the JSON size.

the format has no way to indicate to the parser what it should be expecting. If this software is successful, people are going to be plugging in older code with potentially a different data format and causing it to render garbage or crash unless the editor can pick up on the older format and convert it to the latest version and emit newer JSON code into the text box.

Definitely a consideration. The format isn't set in stone yet.

Maybe one day you can add support for simulating cylindrical keycaps

I've done a little bit of fiddling in this area, using gradients and changing margins/corner-roundness to simulate different cap profiles. Nothing to show off, just yet.

[ijprest]

I just gave up right after I couldn't figure how to remove the function row without manual effort.

A couple of options:
-- Click on 'F1'. Press 'Del' 12 times.
-- Click F1. Ctrl+Click each of the other F-keys. Press 'Del'.
-- Hold alt, click and drag a rectangle to select the entire row. Press 'Del'.

[Muirium]

Right. Never thought of the first, tried the second but on a Mac Ctrl+Click is impossible (redirects to right click) and assumed the third was a no go.

[Daniel Beardsmore]

Yeah Firefox doesn't give me a colour picker, it gives me two identical text boxes that force the same value into both, which is really confusing. Internet Explorer does the same. Can't find an obvious screenshot of what Chrome does, but I presume it in itself lacks an HTML colour field? (The reason why you feel that you need a visible HTML field next to a colour picker, which normally you would not have.)

In terms of multi-row keys, ideally you'd break this out into a separate UI, perhaps something like:

Multi-row key UI.png (131.96 KiB) Viewed 12462 times

(Except multi-line should be checked, but too late as I've already closed the browser I was using to edit the HTML :)

The new X offset field is for the relative offset that's missing from the UI, which in your example is either 0 (adjacent keys) or 0.5 (start of new key block). I think I meant to leave X in there as well but it disappeared.

[hasu]

Great work!

I think it is clever enough to represent the Bigass/ISO Enter key. I'm impressed 'casue it is exactly what I have thought over last a few weeks and couldn't come up with. If there is smarter way to build Enter button with HTML elements it is very intriguing to me also.

I'm working on keymap editor for customizing my firmware now. Ignore poor UI design and codes.
http://tmk.github.io/tmk_keyboard/editor/hhkb/

I'll look into, learn and steal the idea from your codes

Thanks.

There's no controls UI way to shift a block of keys across. Also, there is no UI way to set a bigass enter or J enter as you can only load keyboard presets, instead of keycap presets.

Setting the + field of X to 1 instead of 0 is WEIRD. For shift (a wide key) the keys gets wider instead of moving horizontally. For a 1-unit key it leaves a dead key behind, forming a permanent key group. The dead key cannot have a caption. The Y field then only applies to the "real" key, not the dead one. This has got to be broken, as it makes no sense whatsoever.

I agree that the secondary width/height/x/y fields are confusing as hell. They're solely used/needed to create the big-ass ENTER keys. (Which *I* created using the UI... though it admittedly took some fiddling.)
-- Each big-ass ENTER key is basically two rectangles.
-- The first "column" of values defines the first rectangle
-- The 2nd "column" defines the second rectangle (with X & Y being offsets from the first one)

I'm open to suggestions for a better representation. I'm not overly fond of this one, myself.

[ijprest]

Thanks! It's turning into a pretty fun project.

Here's a new version: http://www.keyboard-layout-editor.com/kb3.html

Changes:

• New capabilities:
  • can now change the text color of a keycap
  • can select a 'palette' of colors from the dropdown at the top (currently only showing Signature Plastics ABS colors, but others can be added easily); clicking a swatch sets the cap color, ctrl+click sets the text color.
• Better keyboard/mouse support:
  • Shift+Arrows to change width/height of the selected keycap.
  • F2 when the keyboard-layout has focus will send focus to the properties-editor
  • ESC when the properties-editor has focus will send focus to the keyboard-layout
  • No longer need to hold the 'Alt' key to marquee-select keys
  • Some common operations (add button, etc.) will automatically focus the keyboard-editor, for more seamless keyboard use.
• UI changes:
  • using Bootstrap for a cleaner and more-consistent look & feel
  • keyboard presets moved into a dropdown in the top nav-bar
  • 'permalink' moved to the right side of the nav-bar
  • "Add/Delete Key" buttons are moved above the keyboard-editor
  • "Add Key" button has a dropdown, with options to add more than one key at a time
  • I am now 'disabling' the UI fields instead of hiding them completely; stuff 'jumps around' less.
  • Raw data editor is now on a different 'tab', to get it out of the way of the rest of the UI
  • Raw data editor now reports if you type invalid data.
• Data changes:
  • The data format hasn't actually changed (permalinks from the last version will still work, if you update kb2.html --> kb3.html), but I've made a few changes to simplify it and present it better.
  • I'm using a "non-strict" JSON variant that doesn't require quotes around property names... so there's a lot less "noise" in the data, and it makes it easier for a human to read and understand.
  • The raw-data editor strips off the leading & trailing square brackets (they're still in the permalink, though).
  • The raw-data editor splits "rows" onto separate lines, further enhancing readability.

There's also the usual smattering of bug fixes, etc., and I'm probably forgetting some details. I've got some ideas for future work (most resulting from all your feedback!), but probably won't get to it before next week.

It's starting to look & feel pretty good, IMO, but I welcome any feedback.

[Daniel Beardsmore]

OK, now you have some very weird bugs.

Click Color Swatches → Signature Plastic ABS
Palette appears, but with all entries not showing a colour (i.e. some kind of disabled view)
In Firefox, the colours only appear in the palette after adding a key, and they disappear again after selecting another; in Internet Explorer, they come and go depending what key you click

Clicking keys selects the wrong key (e.g. one that is two rows up, in IE) or no key at all (Firefox), making some or all the keys impossible to select or edit.

Basically it looks great but is totally unusable as nothing works.

[ijprest]

Clicking keys selects the wrong key (e.g. one that is two rows up, in IE) or no key at all (Firefox), making some or all the keys impossible to select or edit.

Bah! Stupid browsers doing things differently. Looks like this is all related to the coordinates returned when mouse clicking. Works fine in Chrome...

I'll see if I can figure this out tonight.

[ijprest]

OK, the selection problem turned out to be pretty straightforward.

I've now tested basic functionality in IE 10 and FF 24. (I do all my development on Chrome 29.)

[Daniel Beardsmore]

That's better.

The lasso selection is nice, but it has a serious problem: no tracking outside of $("keyboard"). For example, if you try to select the numeric keypad, the cursor can exit the div without passing through intermediate pixels, leaving the lasso "jammed" short of its maximum size:

Lasso bugs.png (16.57 KiB) Viewed 12400 times

Also, you can't cancel the lasso by clicking on a blank part of the page, as no mouse tracking for the keyboard div occurs anywhere else on the page. Drag start should not be handled anywhere else, but drag end should be monitored by the whole page.

If you release the mouse outside of the div, the lasso is "stuck" and just sits there.

For the top row, it's too tempting to begin the lasso above the grey area, and all that does is just select the text on the page.

Also:

Width < 1 is rounded down to 0. Some keyboards have 'J' enter with the upper row < 1 unit! (Also you can have tab the same shape but mirrored.

Size handles on keycaps would be nice. CSS has size cursors for that.

Should arrows move or select adjacent keys?

For Add Key, consider a custom input menu item, à la RISC OS from the late 80s/early 90s:



(Anyone doing UI design should read that article — RISC OS had some truly incredible design ideas that have mostly been forgotten.)

Colour palette doesn't tell you how to assign legend colour (ctrl+click).

Still to do:

Intelligent colour handling.
Format version number.

Finally:

For an interesting TODO, for v2, when you click a key, its corresponding JSON code should highlight. That could easily be a real pain though.

"LED" setting for a keycap :) And nubs :)

[ijprest]

The lasso selection is nice, but it has a serious problem: no tracking outside of $("keyboard").

Yeah, this annoys the piss out of me, too. I haven't figured out how to solve it yet. In Win32 (my day job), I'd request mouse-capture... not sure how to do the same in HTML. (Actually, a quick google shows some mouse-capture stuff for HTML, so maybe it's done the same way.)

Width < 1 is rounded down to 0. Some keyboards have 'J' enter with the upper row < 1 unit!

Good to know... never seen such a beast. In Chrome, the "number" <input> fields prevent entering invalid numbers, so I hadn't put any further effort into validating the data.

For an interesting TODO, for v2, when you click a key, its corresponding JSON code should highlight. That could easily be a real pain though.

Neat idea... not sure I want to go down that road just yet, though...

"LED" setting for a keycap And nubs

You read my mind!

[HaaTa]

Once things are "stable'ish", I'll have a whole slew of odd/interesting requirements to keyboard layouts (that were available in the xorg keyboard layout language; did some heavy research into it in 2010 before I got interested in controllers).

[ne0phyte]

Another feature request: add an undo/redo stack
Especially since it is possible to, for example, remove lots of keys at once. If you do that accidentally it'd great if you could press Ctrl+Z or had a button for Undo/Redo

[ijprest]

I've updated the editor to v0.4. Mostly minor bugfixes and UI tweaks... here are the highlights:

-- Marquee select a bit easier to use, since it continues to track the mouse anywhere over the browser window.
-- I've added pre-baked "ISO Enter" and "J-Shaped Enter" keys to the "Add Keys" dropdown. (If there are other common-but-complicated shapes I should add, let me know.)
-- "Help" dialog to show available keyboard shortcuts.
-- Code now on GitHub for proper versioning and stuff.

[ijprest]

Another feature request: add an undo/redo stack

Near the top of my list!