It seems he is currently working on a grouping/categorization/modularization/git-submodulification of the existing parts of the firmware.
When I read his ideas about categories and the list of projects, it occurred to me that some of these projects, core and third party modules are not plugins in a strict sense.
Up to now everybody uses the term plugin typically when refering to a part of the firmware that is living in its own git repo. Mostly the names of such projects start with Kaleidoscope- .
The term plugin is commonly used for a piece of software that serves as a module for an existing software and inter-operates with it via a well defined API. Mostly this also requires the module to be run-time loadable (plug and unplug). The latter is not the case for the firmware as it is a monolith. So what we commonly call firmware plugins are, in my opinion, not plugins in a strict sense.
There are some projects - I use the term projects here for everything that lives in its own git repo - that do not provide firmware parts, or do not use the plugin-API or only provide headers (Kaleidoscope-Ranges) or do provide code that only interacts with the firmware (e.g. Kaleidoscope-Hardware-Virtual), but are not actually part of the (device-) firmware.
We should consider using more distinctive terms for those different types of projects, e.g.
plugin for everything that is linked into the firmware and uses the plugin-API.
module for everything that is linked into the firmware (including plugins).
project (or maybe a better suited term) for everything that is related to the firmware (including modules), but not necessarily compiled code.
I completely agree that terminology has been fuzzy, and I’d like to see us decide on clearer definitions for terms that we use. I also like the idea of increasing the vocabulary to provide clear distinctions between things. Your definitions of “module” and “plugin” are great, though “project” is not one that I like much (I think “project” is better for a description of the work that is done to make something, rather than the thing that is made). If I think of a better alternative, I’ll let you know.
I also think it would be nice to have a term (or maybe two) for modules that are not plugins, so I can say “Kaleidoscope-Foo isn’t a plugin, it’s a wug.” But I’m also drawing a blank coming up with an idea for that term…
And component for a non-plugin module? Or maybe component becomes the general term (also covering plugins) and module becomes the specific term for the non-plugin thingy.
For anyone unfamiliar, “wug” is a famous nonce word from developmental psychology & cognitive science, used in the “wug test” where a novel object is given to a very young test subject, who is told that the object is a “wug”, to see if they use the pluralization rule properly.
I agree that we should have a standard vocabulary. And I’ve let everyone down by not having a written glossary from the get-go. This should include not just the names of chunks of code, but also of objects inside the system. (key, keyswitch, layer, layout, keymap, etc)
In my head:
Library or Arduino Library
Some chunk of code packaged according to the Arduino Library definition. This includes every Kaleidoscope Plugin, as well as Kaleidoscope itself. Not every Library is a Plugin. This is a term already used in the Arduino ecosystem.
Plugin or Kaleidoscope Plugin
An Arduino library that is designed to use the Kaleidoscope Plugin API. Every Plugin is a Library, but not vice-versa. It may be the case that Plugins use or wrap Libraries.
Hardware Definition or Hardware Plugin or…I don’t have a good name for this
An implementation of the Kaleidoscope Hardware API that lets Kaleidoscope talk to a specific keyboard or other device. This is an Arduino Library, but not really a Kaleidoscope Plugin, since it doesn’t use the plugin hooks.
Sketch
This is the Arduino term for the main program someone runs on their keyboard. It’s not the term I’d pick if I were starting from scratch, but it’s widely used in the ecosystem, so I think we’re stuck with it.
Core
This is the low-level implementation of the Arduino APIs for a given microcontroller implementation. Every Hardware Plugin runs on top of a core, but some may share the same core.
I’m not a fan of ‘module’ or ‘project’ for things that have official definitions. As I understand it, ‘modules’ are a newish c++ core feature. And projects are things that people work on. Kaleidoscope is a project, each plugin is a project. Sometimes a personal firmware sketch is a project.
For naming things people build for Kaleidoscope that don’t use the Plugin API or the Hardware Plugin API…I’m not sure yet. Happy to entertain suggestions. While ‘wug’ is a cromulent word, it’s probably not the right one here
(A number of posts that are more related to Kaleidoscope-CMake were moved here. There is some overlap with terminology, but the bulk of it is off-topic in this thread.)
