Requesting some comments and review on my changes

[dragon788]

I don't think this needs merged as is, but I would love to get some feedback and this is probably the easiest way to do so.

First off, I modified the default layout quite a bit because having any of the tap keys on keys that I type was horribly impacting my speed and accuracy due to the slight lag it caused in inputting to the screen or getting unintended characters when a macro/tap triggered wrong. I've moved them all off of letters and relegated them to the outside areas that I only intentionally press a single time or hold.

I also added in a Plover layer to the default keymap as layer 3 (the 4th layer). Ideally this would go in its own file, but I haven't figured out if it is possible to mix and match layers from multiple files and squash them all together, as I would love to dynamically say "layer 0 = colemak layer file", "layer 1 = symbols layer file", "layer 2 = mouse layer file", etc.

I also went crazy on the mouse layer, I'm always switching which hand I want to use for the mouse layer, so I put an activation on both sides and controls and clicks on both sides. I also made it so you can operate it one handed on either side (hoping to add a one handed typing layout soon as well).

I've added a Vagrantfile to allow users to easily compile the firmware without negatively affecting their primary system. They'll need Virtualbox and Vagrant, but both are free and fairly small, and the default Arch box I created is less than 700Mb, and I could probably get it smaller if it needed to be. The benefits of using Vagrant are myriad, but the primary goal is having the same environment for building/troubleshooing on ANYONE's system.

In addition to the Vagrantfile I added a "avr_setup.sh" script. This can be run (or sourced) on Linux systems to automatically attempt to install all the proper packages to compile a new firmware. I haven't tested anything except the Arch one extensively, but I did verify the package names for Debian/Ubuntu and Arch. I'm going to add in the CentOS and openSuse names using the boxes I added into the Vagrantfile as alternate environments.

[ezuk]

Hi @dragon788! :)

So, this is great stuff! The only thing I would ask is not to change the default keymap, but give the file a new, descriptive name. You can see the others in the keymaps directory -- lots of contributions, so this system seems to work well.

I would suggest maybe calling it keymap_plover, and adding a keymap_plover_readme.md file which explains a little bit what Plover is (links to the site), as well as how to flip on NKRO after flashing it. What do you think?

[agriffis]

@dragon788 great stuff. I would be using this Vagrantfile if it were already in the repo.

[J3RN]

@dragon788 We've got some overlap between our two custom firmware implementations, and I think that's pretty awesome! Also, your mouse movement layout gave me an idea: Put the toggle/momentary L2 key somewhere else (like you did), then use hjkl to move the mouse, like navigating in Vim. What's better, you could set another layer (or use L1?) to set hjkl to send the keyboard left, up, down, and right, respectively. You could move around in your browser or other applications in the same way you navigate Vim!

I hope this idea appeals to you like it did to me. I might give it a go a little later.

[dragon788]

Jonathan, that is something I've been thinking about as well. I'm hoping to
get my branch cleaned up and split things out for better
organization/separation of responsibilities this weekend.

I'll include the current dress of my keyboard just for kicks.
On Jan 15, 2016 11:21 AM, "Jonathan Arnett" notifications@github.com
wrote:

@dragon788 https://github.com/dragon788 We've got some overlap between
our two custom firmware implementations, and I think that's pretty awesome!
Also, your mouse movement layout gave me an idea: Put the toggle/momentary
L2 key somewhere else (like you did), then use hjkl to move the mouse, like
navigating in Vim. What's better, you could set another layer (or use L1?)
to set hjkl to send the keyboard left, up, down, and right, respectively.
You could move around in your browser or other applications in the same way
you navigate Vim!

I hope this idea appeals to you like it did to me. I might give it a go a
little later.

—
Reply to this email directly or view it on GitHub
#73 (comment)
.

[dragon788]

@ezuk @jackhumbert Hopefully with the cleanup this looks good enough to merge. I pulled all my changes out into a separate layout for those who don't like double identity keys in the common typing zones, I also made a Plover layer keymap with the default EZ layers and a layer toggle.

I also cleaned up the avr_setup.sh which can be run on almost any Linux distro to get a working environment without needing to set up vagrant + virtualbox or vmware. This file gets run every time somebody does a 'vagrant up' so they always have the latest versions of libraries etc.

[ezuk]

@dragon788 - maybe consider adding another point here about the Vagrant file and avr_setup.sh? Just so people know to look for them?

In fact (cc @jackhumbert) I'm thinking these changes might be important enough to be mentioned in the main readme. What do you guys think?

[jackhumbert]

Sure! Sounds good to me.

[ezuk]

So only one question from me, re docs (so people know these tools are available). Other than that it looks great! Since it affects things outside the scope of the ErgoDox EZ, I'd like @jackhumbert to weigh in. Jack, what do you think?

[dragon788]

@ezuk @jackhumbert I added a section to the README pointing to QUICK_START.md that contains the instructions on adding Vagrant+Virtualbox in a straightforward manner. Let me know if you want anything reworded, or you can fork my fork and make changes before it gets merged.

[dragon788]

I usually use the VMware version of the Arch box in the Vagrant and it has been working fine, but it appears the Virtualbox version is having some issues with the shared folder path. This will prevent users from being able to compile as the source code won't be visible inside their VM and they have no way to get the hex back out if they would clone the repo inside and compile.

I've actually submitted a pull request to the repo where I got the Arch Packer configuration from, so once I get the issues fixed and merged into their repository we'll probably want to point the Vagrantfile at their "official" Arch box.

@ezuk @jackhumbert
I'd say this is currently a blocker for the merge, but I'm going to test the other box configurations as an Ubuntu based one wouldn't be a bad alternative instead of the Arch one and I do have that in the Vagrantfile as an option.

[ezuk]

Thanks @dragon788 - standing by, then. I think using the Ubuntu one would be a good solution, and yeah, there should probably be something that works with VirtualBox because VMWare isn't free (right?).

[dragon788]

Ok, after some research it appears it is an issue with certain versions of Virtualbox 5. I downgraded to 4.3 and it works fine. I'm going to try the very latest version of 5 and see whether that works. Its interesting that the extensions inside the box are 5.0.12 (at least for Arch).

[dragon788]

@ezuk It looks like the latest version of Virtualbox 5.0.12 works fine as well. I think it may have been a bug in certain versions of Virtualbox, so I'll add that to the QUICK_START. If anyone has any issues with the vagrant folder not mapping then they should upgrade their Virtualbox version.

[dragon788]

@ezuk I'd say we are good to merge now that the note about specific versions is in place. If anybody runs into anything else they can report it as an issue and I'll look into it.

[dragon788]

I also added some notes about command line programming from the VM since at least the Arch VM and probably the others don't have any desktop display manager packages installed to keep the overall size down.

[ezuk]

Awesome work! Thank you @dragon788! Merging this in now.