[Keyboard] Add Flatbread60, Vaneela, and VaneelaEx by nckiibs

[noclew]

Description

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[noclew]

Thank you very much for your help! I fixed the issues pointed out.

[noclew]

I also added two more keyboards. Do I have to close and make another pull request?

[noclew]

All done!

[noroadsleft]

In addition to the specific suggestions, I'm not keen on the fact that the default and via keymaps for each board don't use the same mappings. This can be disorienting to users who switch between VIA and non-VIA firmware, and IMO these keymaps should be as similar as possible. I may return with more suggestions along these lines later.

GitHub tip: Multiple suggestions can be applied to a single commit through the Files Changed tab.

[noclew]

In addition to the specific suggestions, I'm not keen on the fact that the default and via keymaps for each board don't use the same mappings. This can be disorienting to users who switch between VIA and non-VIA firmware, and IMO these keymaps should be as similar as possible. I may return with more suggestions along these lines later.

GitHub tip: Multiple suggestions can be applied to a single commit through the Files Changed tab.

Thank you! I fixed what were requested. By the way, what is the proper response to the change requests? Do I have to click every 'resolve conversation' button after fixing them?

[noroadsleft]

Thank you! I fixed what were requested. By the way, what is the proper response to the change requests? Do I have to click every 'resolve conversation' button after fixing them?

Depends how you apply the suggestions. If you apply them through GitHub's web interface, they should resolve automatically. If you make the changes locally and then push them to your fork, you do need to resolve them manually.

With a lot of suggestions, I'd suggest using the Files Changed tab to make them, then when you have them committed on GitHub, use git pull origin nckiibs to pull those changes to the source branch on your local repo (the files on your computer). That will automatically resolve the suggestions, but keep your fork and your local repository synchronized. Note that you'll need to have your local nckiibs branch checked out and clean (no modifications) for this to work without any hiccups/issues.

[noclew]

Thank you! I fixed what were requested. By the way, what is the proper response to the change requests? Do I have to click every 'resolve conversation' button after fixing them?

Depends how you apply the suggestions. If you apply them through GitHub's web interface, they should resolve automatically. If you make the changes locally and then push them to your fork, you do need to resolve them manually.

With a lot of suggestions, I'd suggest using the Files Changed tab to make them, then when you have them committed on GitHub, use git pull origin nckiibs to pull those changes to the source branch on your local repo (the files on your computer). That will automatically resolve the suggestions, but keep your fork and your local repository synchronized. Note that you'll need to have your local nckiibs branch checked out and clean (no modifications) for this to work without any hiccups/issues.

@noroadsleft @drashna
Thank you for the information. I am learning this review process, so it will be appreciated if you can answer these noob questions!

1. Upon the change requests by reviewers, is there a way to filter the files that were quested to change in the Files Changed tab? Last time, I went there, added changes to the batch, ran batch commits, and marked all files as viewed. After the new changes were requested, I checked the Files Changed tab again, and because all the files were still marked as 'viewed', there was no way to filter out the files that the new changes have been requested with. In this process, is there a way to quickly filter out the files with new change requests? Or, do I have to go through every file again and check the red box to find the new change requests?

2. Once I changed the files requested and batch committed them on Github, I more than often have failures in the automated checks because of the files of other keyboards. This time, it is PR Lint keyboards check, and it looks like there are some errors with the files of other keyboards, specifically, Run qmk info test with Kudox keyboard. If this happens, what I usually do is 1) pull the lastest Github batch commit to my local repo 2) rebase the local repo with the latest QMK build 3) commit and push the local repo to Github and 4) wait to see if it passes the two automated checks. Is this procedure correct to deal with the automated check failures? Sometimes this does not work when the official QMK repo is not updated and is still with errors, so I feel like this is not the correct way to deal with the failures in automated checks from others' files. Can you let me know what is the proper procedure?

3. I am a bit confused by VIA keymaps. @drashna told me that functions for switching layers are not necessary because VIA has its own. I looked at others' file, and it seems like they do not define custom functions to switch layers and only have the keymaps. However, in the latest change request, it was asked to put the functions back to the keymap files, so I wonder what is the right way to write the VIA kemaps.

I am sorry for the long questions, and I really appreciate all the efforts to help newbies in the community!

[noroadsleft]

1. Upon the change requests by reviewers, is there a way to filter the files that were quested to change in the Files Changed tab? Last time, I went there, added changes to the batch, ran batch commits, and marked all files as viewed. After the new changes were requested, I checked the Files Changed tab again, and because all the files were still marked as 'viewed', there was no way to filter out the files that the new changes have been requested with. In this process, is there a way to quickly filter out the files with new change requests? Or, do I have to go through every file again and check the red box to find the new change requests?

I don't have an answer for this one; I'll probably have to look into it. I know what things are likely to be requested due to being a collaborator, so I typically jump ahead on these things before opening a PR.

2. Once I changed the files requested and batch committed them on Github, I more than often have failures in the automated checks because of the files of other keyboards. This time, it is PR Lint keyboards check, and it looks like there are some errors with the files of other keyboards, specifically, Run qmk info test with Kudox keyboard. If this happens, what I usually do is 1) pull the lastest Github batch commit to my local repo 2) rebase the local repo with the latest QMK build 3) commit and push the local repo to Github and 4) wait to see if it passes the two automated checks. Is this procedure correct to deal with the automated check failures? Sometimes this does not work when the official QMK repo is not updated and is still with errors, so I feel like this is not the correct way to deal with the failures in automated checks from others' files. Can you let me know what is the proper procedure?

The PR Lint check is literally a "first-effort" – if it's not flagging boards you've changed, ignore it.

3. I am a bit confused by VIA keymaps. @drashna told me that functions for switching layers are not necessary because VIA has its own. I looked at others' file, and it seems like they do not define custom functions to switch layers and only have the keymaps. However, in the latest change request, it was asked to put the functions back to the keymap files, so I wonder what is the right way to write the VIA kemaps.

VIA's functions for this only work if you use the keycodes VIA provides for doing this, and they also only work if you have exactly four layers.

[noroadsleft]

Thanks!

[noclew]

Thank you!

…

On Sun, Aug 9, 2020 at 10:51 AM James Young ***@***.***> wrote: Thanks! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9817 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOXY4HHIFWLUMZCVDJ3WBDR72ZVTANCNFSM4PHG2QUQ> .

[noclew]

Oh, by the way, I just checked qmk configurator, and it seems like the default keymap was no registered. How can I make it so that the there shows a default keymap in QMK configurator?

…

On Sun, Aug 9, 2020 at 10:51 AM James Young ***@***.***> wrote: Thanks! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9817 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOXY4HHIFWLUMZCVDJ3WBDR72ZVTANCNFSM4PHG2QUQ> .

[noroadsleft]

Oh, by the way, I just checked qmk configurator, and it seems like the default keymap was no registered. How can I make it so that the there shows a default keymap in QMK configurator?

@noclew,

QMK Configurator keymaps live here: https://github.com/qmk/qmk_configurator/tree/master/public/keymaps

Instructions: https://github.com/qmk/qmk_firmware/blob/633d0fe5f7eef8400cfdc843f1a043d0eac8a836/docs/configurator_default_keymaps.md (hopefully this will hit the QMK docs soon)