Something we've been throwing around a little recently is to add a layouts/ folder, which would contain a number of common/predefined layouts that could be compiled with keyboards that are compatible with them. Some examples would be:
Obviously naming them could be a bit of an issue, but as long as they're the common term and clear, I don't think we'll have too many problems. I think keeping them description rather than associative is important.
This would allow us to break up some of the current subprojects that don't make a whole lot of sense (namely ergodox), while allowing them to still share keymaps.
When compiling, the make system would search in keyboards/<keyboard>/keymaps first for a keymap, and if it's not found, the compatible layouts' folder (layouts/<layout>/) would be searched. It may make sense to add the layout as an argument (similar to subprojects now), but I would like to avoid that, or make the detection automatic, but overridable.
We'd need a list of layouts that a certain keyboard supports, which could be added in the rules.mk (I think it would need to be here rather than the config.h for compilation reasons), and the keyboard would need to implement a specific KEYMAP function for that could be as simple as:
#define LAYOUT_ORTHO_4x12 PLANCK_GRID
Where PLANCK_GRID defines the actual mapping for the matrix, and LAYOUT_ORTHO_4x12 is then used in the layouts/ortho_4x12/ keymaps.
This discussion also brought up some ideas about enabling/disabling features, the separation of hardware/software features, and having features "available," all of which need to be considered with this addition, but may not be required for the initial implementation.
Something we've been throwing around a little recently is to add a
layouts/
folder, which would contain a number of common/predefined layouts that could be compiled with keyboards that are compatible with them. Some examples would be:layouts/ergodox
- Ergodox EZ/Ergodox Infinity/Ergodone?layouts/60_ansi
- GH60/DK60/Infinity 60/KC60/ORG60/S60-X/XD60/etclayouts/60_iso
- GH60/DK60/Infinity 60/KC60/ORG60/S60-X/XD60/etc (I'm not 100% sure these keyboards are compatible with ansi/iso)layouts/ortho_4x12
- Planck/Let's Split/Mechmini 2Obviously naming them could be a bit of an issue, but as long as they're the common term and clear, I don't think we'll have too many problems. I think keeping them description rather than associative is important.
This would allow us to break up some of the current subprojects that don't make a whole lot of sense (namely
ergodox
), while allowing them to still share keymaps.When compiling, the make system would search in
keyboards/<keyboard>/keymaps
first for a keymap, and if it's not found, the compatible layouts' folder (layouts/<layout>/
) would be searched. It may make sense to add the layout as an argument (similar to subprojects now), but I would like to avoid that, or make the detection automatic, but overridable.We'd need a list of layouts that a certain keyboard supports, which could be added in the
rules.mk
(I think it would need to be here rather than theconfig.h
for compilation reasons), and the keyboard would need to implement a specificKEYMAP
function for that could be as simple as:Where
PLANCK_GRID
defines the actual mapping for the matrix, andLAYOUT_ORTHO_4x12
is then used in thelayouts/ortho_4x12/
keymaps.This discussion also brought up some ideas about enabling/disabling features, the separation of hardware/software features, and having features "available," all of which need to be considered with this addition, but may not be required for the initial implementation.