Lotus58 glow

[TweetyDaBird]

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: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• 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).

[zvecr]

Keymap folder per revision seems a bit unnecessary given its the same PCB in all cases.

keyboards/tweetydabird/lotus58/keymaps/default/keymap.c
keyboards/tweetydabird/lotus58/atmeldfu/rules.mk
keyboards/tweetydabird/lotus58/caterina/rules.mk
keyboards/tweetydabird/lotus58/nanoboot/rules.mk

Using some existing terminology could also help with consistency;

• caterina -> promicro
• atmeldfu -> elite_c

As a decent proportion of user will have no idea when to use caterina vs atmeldfu.

[TweetyDaBird]

Keymap folder per revision seems a bit unnecessary given its the same PCB in all cases.

keyboards/tweetydabird/lotus58/keymaps/default/keymap.c
keyboards/tweetydabird/lotus58/atmeldfu/rules.mk
keyboards/tweetydabird/lotus58/caterina/rules.mk
keyboards/tweetydabird/lotus58/nanoboot/rules.mk

Using some existing terminology could also help with consistency;

• caterina -> promicro
• atmeldfu -> elite_c

As a decent proportion of user will have no idea when to use caterina vs atmeldfu.

Well, since it is in fact categorized by boot loader, and the list of controllers it applies to was included in the readme. But sure I can rename them.

Edit: to clarify, since Atmega32u4 are routinely running out of memory for advanced features on split keyboards especially, I try to steer builders to use nanoBoot as the bootloader, and for whatever reason, making commented out lines in a single firmware ended up causing confusion. Separate folders/versions seems to solve/reduce that.

[TweetyDaBird]

I believe all requested changes (manual edits) should be fixed and tested now. Let me know if there is more that needs fixing.

Again, in all respect, no rush, just confirming that I have tested things.

[zvecr]

Keymap folder per revision seems a bit unnecessary given its the same PCB in all cases.

keyboards/tweetydabird/lotus58/keymaps/default/keymap.c
keyboards/tweetydabird/lotus58/atmeldfu/rules.mk
keyboards/tweetydabird/lotus58/caterina/rules.mk
keyboards/tweetydabird/lotus58/nanoboot/rules.mk

This suggestion has not been completed.

[TweetyDaBird]

Ah, right. Then I misunderstood and/or didn't read carefully enough. Now, I'll have to think on that. This sort of creates an issue going to Vial.

Again trying to have a discussion, not arguing/being a PITA more than necessary. I agree that this isn't your issue to solve, I'm just trying to find the middle ground where it's acceptable here, and doesn't totally shoot me in the foot there, creating more work as a whole. Feel free to just ignore me if you don't want to have the discussion.

Moving the key-maps to a central folder doesn't work in Vial as the key-maps there have to be dependent on the boot-loader (lack of space) and the standard for the Vial key-map is a single folder with the name Vial.

Do you have any good suggestions for a workaround?

Can the boot-loader assignment move to key-map level? It actually can can't it? (Although I'm not sure if that the correct thing to do).

[zvecr]

where it's acceptable here, and doesn't totally shoot me in the foot there

The only thing that is of concern here if its acceptable to QMK. Optimising, even if its only in part, for Vial is zero on the scale.

However it should be noted that having a common folder for keymaps does not stop at a later date the introduction of

keyboards/tweetydabird/lotus58/atmeldfu/keymaps/something/keymap.c
keyboards/tweetydabird/lotus58/caterina/keymaps/something/keymap.c

As long as "something" doesnt also exist within keyboards/tweetydabird/lotus58/keymaps.

You can also use have conditional blocks within the compilation units, with #ifdef BOOTLOADER_CATERINA and things like post_rules.mk to disable features completely.

[TweetyDaBird]

The only thing that is of concern here if its acceptable to QMK. Optimising, even if its only in part, for Vial is zero on the scale.

I fully understand the position. However, had I just swallowed the first suggestion and not questioned, it would probably resulted in another PR with an update fairly soon, and then another, and another... Making us both batty...

The reason I asked however is this:

You can also use have conditional blocks within the compilation units, with #ifdef BOOTLOADER_CATERINA and things like post_rules.mk to disable features completely.

That should have been obvious to me, having used the '#ifdef OLED' etc... It wasn't for some reason. So, from the bottom of my heart, thank you for making me feel damned stupid... That was going beyond...

It might perhaps take me a while to iron it out to my satisfaction (and yours), but I think you just gave me the key...

[drashna]

This is the fifth PR for this board: #20281, #18554, #15867, #12594.

[TweetyDaBird]

This is the fifth PR for this board: #20281, #18554, #15867, #12594.

Yeah. I don't do good with GitHub time limits and such. ADHD. Either things happen fast, and I say focused, or I loose focus and hyper focus on something else, and end up procrastinating. Was sort of why I managed to annoy Joel before(justified from his side Btw). I was more trying to keep myself on task than anything else.

And git isn't my strong suit to start with. Is there a way to re-open a PR from my side? I would have preferred that.

[TweetyDaBird]

Well, a work days worth of testing. It work as is, and armed with the above tip, I feel I can take this and make Vial work without shooting myself in the foot once it's in the main repo. I'm happy with it. Let me know if there is anything else that needs fixed.

[zvecr]

Ive fixed up things after the bad info you were given, as well as a few minor tidy ups. All good to go from my front now.

[TweetyDaBird]

Ive fixed up things after the bad info you were given, as well as a few minor tidy ups. All good to go from my front now.

Thanks! And a lot of thanks for the pointers!