Hello. I have been getting some messages from my open issues reading:
Due to the plugin being merged into the Kaleidoscope monorepo, issues are being migrated over there. This issue is going to be tracked further as keyboardio/Kaleidoscope#373.
Please explain. This plugin based firmware is becoming more monolithic?
Or is it only for the Mouse and Macros plugins whose behaviour is too low-level to be reliably kept in sync in a separate repo?
Also please advise whether it is OK to delete our local copies of the Macros and Mouse plugins then? Thanks!
For all intents and purposes - no. The only thing that changes is where plugins under the keyboardio umbrella are. The architecture remains unchanged, we have no intention of moving away from plugins.
It’s going to remain plugin based, but the plugins that used to be in Kaleidoiscope-Bundle-Keyboardio (and formerly Arduino-Boards) are getting merged into Kaleidoscope itself. They’re still functionally separate, they still use the same plugin APIs as external plugins, those are not going anywhere, because it’s a core part of what makes Kaleidoscope awesome. We’re merely rearranging the sources, moving them into Kaleidoscope, to make it easier to contribute.
Plenty of people expressed frustration that working with the many small plugins was a barrier of entry, and it would’ve been much easier if it were just one repo. They liked the plugin architecture, just not the split into multiple repos. So we started merging the plugins, to remove that barrier, while still keeping the same architecture. This has a bunch of other benefits too, like plugin documentation being in one place, being able to do cross-plugin changes more easily, reducing the amount of submodules used (submodules are a bit awkward to work with, in my opinion).
An interesting note: while merging the plugins, we merged histories too.
No, all plugins under the keyboardio/ umbrella are going to move into Kaleidoscope. I’ll emphasize again: this is not a move towards a monolithic architecture, just a monolithic repository, with the plugin architecture kept as-is. We’re even building new things on the plugin architecture (like the recent onFocusEvent event, and there’s more coming!).
Yep, it’s ok to delete your local copies! They were also removed from the Kaleidoscope-Bundle-Keyboardio repo too, and are getting archived on GitHub as well.
These are what are under my /hardware/keyboardio/avr/libraries:
AtmegaScanner
FingerprintUSBHost
HID
Kaleidoscope
Kaleidoscope-Colormap
Kaleidoscope-Cycle
Kaleidoscope-CycleTimeReport
Kaleidoscope-DualUse
Kaleidoscope-EEPROM-Keymap
Kaleidoscope-EEPROM-Keymap-Programmer
Kaleidoscope-EEPROM-Settings
Kaleidoscope-Escape-OneShot
Kaleidoscope-FingerPainter
Kaleidoscope-Focus
Kaleidoscope-GhostInTheFirmware
Kaleidoscope-Hardware
Kaleidoscope-Hardware-EZ-ErgoDox
Kaleidoscope-Hardware-Model01
Kaleidoscope-Heatmap
Kaleidoscope-HIDAdaptor-KeyboardioHID
Kaleidoscope-HostOS
Kaleidoscope-HostPowerManagement
Kaleidoscope-Leader
Kaleidoscope-LED-ActiveModColor
Kaleidoscope-LED-AlphaSquare
Kaleidoscope-LEDControl
Kaleidoscope-LEDEffect-BootGreeting
Kaleidoscope-LEDEffect-Breathe
Kaleidoscope-LEDEffect-Chase
Kaleidoscope-LEDEffect-Rainbow
Kaleidoscope-LEDEffects
Kaleidoscope-LEDEffect-SolidColor
Kaleidoscope-LED-Palette-Theme
Kaleidoscope-LED-Stalker
Kaleidoscope-Macros
Kaleidoscope-MagicCombo
Kaleidoscope-Model01-TestMode
Kaleidoscope-MouseKeys
Kaleidoscope-Numlock
Kaleidoscope-NumPad
Kaleidoscope-OneShot
Kaleidoscope-Qukeys
Kaleidoscope-Ranges
Kaleidoscope-Redial
Kaleidoscope-ShapeShifter
Kaleidoscope-SpaceCadet
Kaleidoscope-Steno
Kaleidoscope-Syster
Kaleidoscope-TapDance
Kaleidoscope-TopsyTurvy
Kaleidoscope-TypingBreaks
Kaleidoscope-Unicode
Kaleidoscope-USB-Quirks
KeyboardioHID
KeyboardioScanner
Model01-Firmware
So, which to retain or which to delete, or better still, what instructions to get a clean local fork?
I’d move the directory (hardware/keyboardio) away (but keep it for backup, just in case), and start afresh with Kaleidoscope-Bundle-Keyboardio:
git clone https://github.com/keyboardio/Kaleidoscope-Bundle-Keyboardio.git \
hardware/keyboardio
For reference, the merged libraries so far are: EEPROM-Keymap, EEPROM-Settings, FocusSerial, Hardware-Model01, HostPowerManagement, LED-AlphaSquare, LEDControl, LEDEffect-*, LED-Stalker, Macros, MagicCombo, Model01-TestMode, MouseKeys, NumPad, USB-Quirks. The rest will move in over the next few days too.
The ones remaining separate are KeyboardioHID, KeyboardioScanner, Model01-Firmware, HID, FingerPrintUSBHost, and AtmegaScanner (the latter two will be dropped from the bundle without replacement).
So if I clone this repo now and later pull again the further repos will automatically come in?
Do sketches compile during this migration process or should I wait for it to be completed?
Would be good if you could do an announcement once the migration is complete.
A few will disappear from the bundle, and turn up in Kaleidoscope automatically, yep. I think git will not remove old subdirs, but they’ll be shadowed by the in-Kaleidoscope version anyway. You might want to clean up / re-clone in a few days though, just to be on the clear.
Sketches should continue compiling throughout the process. I’ve done my best to ensure that.
Yep, we’ll do that!
It may take a little time until I write up a proper announcement, but for now, the migration is complete. There are still a few submodules outside of Kaleidoscope, but those aren’t moving in for a while, for various reasons.
OK thanks for this notification. Another query for help. I have a few mainstream plugins I forked but haven’t yet taken up to PR and merging. Now I have to rebase them on Kaleidoscope itself. Do I have to redo all the commits manually or there is some way to just pull them from my forked local repos and reapply on top of Kaleidoscope? I think cherry-picking might have something to help here but I don’t have enough git experience for that…
Adding the forked plugins as remotes to Kaleidoscope and cherry-picking should work, because we imported the histories of the plugins too. I’ve done that with a number of plugins I migrated PRs for. Alternatively, if you don’t want to deal with rebasing/cherry picking, if you point me to the plugin forks and the branches you were working on, I can do the work for you.