ijprest / keyboard-layout-editor Goto Github PK

If we're trying to see what the keys will look like on a particular keyboard, the light-gray of the editor-area can be distracting (especially if you're using dark-colored caps).

Add the ability to change the background color of the keyboard area.

A prototype would be a set of properties that would be applied to a key by using the name of the prototype, e.g.,

{proto:"modifier"}, "Shift"

• There would be a "default" keycap prototype, used by default. This would allow very quick changes to the entire layout.
• Prototype would only allow properties that 'cascade' to the next key (e.g., color, etc.), and not single-use properties (e.g., label, position, size).
• The selected prototype will also cascade to the next key.
• Prototypes would be editable in the editor, somehow.
• Prototypes would be rendered as caps in the editor.
• Selecting a prototype would apply it to the selected key(s).

Even though the fonts contain the appropriate glyphs, it's sometimes difficult to find many symbol characters in the Unicode ranges, e.g,. the arrow symbols, etc.

It would be nice to have a character picker to make finding and using these glyphs easier.

e.g., the thumb-cluster on an ErgoDox.

e.g., caps-lock, ctrl, ISO-enter, etc.

Some caps (caps-lock, et al, especially) will have little windowed areas that allow an LED to shine through. It would be nice to be able to specify this window.

Note that the windows are often centered on the bottom of the key-cap, but not always!, e.g., for some caps-lock keys. Will need a comprehensive way to specify the window size & position.

Some language-specific keys (e.g., German/Nordic) have a third text label, typically at the bottom-right.

See for examples: http://geekhack.org/index.php?topic=48798.0

You can't achieve stepping by setting a keycap to its desired width, then reducing w to be less than w2. This does not even work when Stepped is checked.

See many of the symbols on this German keyboard: http://en.wikipedia.org/wiki/File:German-T2-Keyboard-Prototype-May-2012.jpg

I think the little hollow marker is meant to indicate that the key will be composed with another glyph to give an accented character.

Some layouts may want to use custom icons on key caps. e.g., the DSA-retro set used the Commodore logo on the Windows-key, and may sets include a "GEEK HACK" custom key.

Since we can't possibly anticipate everything that everybody may want, add the ability to reference an externally hosted image/icon/SVG file.

Probably the most common example would be hitting 'back' in the browser.

If presenting a keycap set for purchase in a group-buy, it is common to hide the keys not present in a particular set. Often, the keys that are not included are just faint outlines, to indicate the correct positions of the caps.

This would allow the user to specify, e.g., ISO, ANSI, JIS-flavored keyboard by encoding only the differences between those keyboards.

Could switch between the layers by clicking on a tab above the editor, perhaps?

See the numpad here: http://en.wikipedia.org/wiki/File:German-T2-Keyboard-Prototype-May-2012.jpg

At a minimum, we'll want a "primary" size for the first bit of text, and a "secondary" size for others. Is there a more generic way to do it without having a million size controls?

Currently we lose any gaps between keys... e.g., select the ESC and F1 keys on a standard layout, then copy and paste them. The pasted keys will be right beside each other without any gap.

As reported in the forums: "on a Mac Ctrl+Click is impossible (redirects to right click)".

I think it's a bug in the "lenient" JSON parser.

See the print-screen key here: http://en.wikipedia.org/wiki/File:German-T2-Keyboard-Prototype-May-2012.jpg

It would be nice to be able to select an entire range of keys by selecting the first key, then holding SHIFT and selecting the last key in the range.

Perhaps Shift+J, Shift+K should also extend the existing selection.

Due to the way keys are laid-out in memory, I suspect this would have to be a right-to-left, then top-to-bottom operation.

Some vintage doubleshot keyboards used very large fonts on their keycaps... (need photo). Suggest increasing font-size limit to 7 or 9.

e.g., Creator, Date, Notes, Links to GeekHack posts, etc.

Some layouts will use different fonts, font-sizes, and/or align the text differently. e.g., the DSA retro set uses a larger, centered font for most keys, and a smaller ALL-CAPS font for modifiers.

The current editor requires a lot of horizontal space for a 104-key layout. It looks OK on my 1600x1200 monitor, but would probably be cut off on a 720p monitor (1280x720).

It would be nice to be able to resize a key using the mouse.

See http://geekhack.org/index.php?topic=19113.0

It's not clear what stepping does — only after careful examination of the raw data did it become clear that I've got to set different primary and secondary widths to get a stepped keycap.

It would be nice to be able to move the selected keys with the mouse.

For example, the Windows logo, menu/application-key, etc. Maybe the 'tab' logo, etc.

From the forums: possibly some of the European symbolic, Mac legends, German "handbag" caps lock, etc.

It looks like German has three rows of text... top, middle, bottom. See: http://en.wikipedia.org/wiki/File:German-T2-Keyboard-Prototype-May-2012.jpg

Must be hard to learn to type in German.

The F & J keys often have a tactile indicator to make it easy to place your fingers on the home row. Add the ability to specify these indicators, and render them appropriately in the editor.

Adding a new keycap obeys the inner (lower) width of the last key, not the outer (larger) width, causing overlap.

Steps to repeat:

1. select ISO 105 preset
2. select the enter key
3. set profile to DCS

Expected:

Concave shading to be based on the outer virtual rect

Actual:

"Leg" of the keycap is drawn as flat grey

Ideally, the extra fields required to edit oddly-shaped keys would be hidden unless they were necessary.

See also #31.

Some "stealth" keyboards will print the text label on the front of the keycap. Similarly, some keyboards will print "media keys" or the like on the front of the keycap.

Keycap shading is presently only horizontal concave. There needs to be a vertical convex option for space bar and for (e.g.) the convex numeric keypad 0 on Realforce keyboards.

A help dialog describing the format would be useful.

When moving or otherwise making changes that are disruptive to the layout, you often wind up with overlapping keys, and these can be annoying to fix manually.

Add a button to the toolbar to automatically resolve these overlapping keys, but pushing keys rightward/downward as necessary.

Method:

1. Select multiple keys in a grid using marquee-select
2. Using the arrows, move the keys all the way to the top or left.
3. Keep moving the keys in the same direction.

Result:

• The selected keys end up overlapping.

The keys should stop moving when the first one hits the edge.

The current permalink URLs are really long, despite efforts to use a 'lenient' JSON format.

• Consider further simplifying the JSON format, or using a non-JSON format altogether.
• Consider a less-strict URL-encoding of the JSON data.
• Consider using a database-backed hash of the JSON data for permalinks.

e.g., Decals (for logos, etc.), labels, LEDs, etc.

As per the title; we need to describe this option somewhere. Tooltip, maybe? Help-screen?

It would be nice if we could specify the profile of a key, e.g.:

• Signature-plastics profiles (DSA, DCS, etc.), Cherry vs. OEM, other manufacturers.
• The row-number (for those profiles that require it).

Ideally, we'd render the keys differently to simulate the profile:

• Cylindrical caps could be rendered with a linear gradient; spherical caps could be rendered with a radial gradient.
• Different rows could maybe alter the margins.

This would be useful for embedding keyboard renders in wikis, etc.