FYI (and a bit of a spoiler alert) I have already spent a few hours on my idea/openHAB-related project of late, that is providing the means for users to extend the Blockly toolbox themselves with YAML definitions, similarly to the UI widgets (these definitions follow and same structure are stored in the JSON DB as “UI Components” in the same manner as the widgets).
Here’s an example:
This would make Blockly infinitely extensible, which regarding its appeal could be a game changer.
You could define or import blocks to tackle with domain-specific interests, import utility functions, and wouldn’t solely rely on what’s on offer in the built-in toolbox.
Because in fact the situation is pretty similar to the UI Widgets actually: no matter how many built-in widgets and options you add, you will never be “exhaustive”. There will always be another need that you didn’t anticipate and now if there’s no extensibility, the pressure is on you to deliver a solution.
So instead there is a way to define custom blocks that get added at runtime to the Blockly editor toolbox, so the users themselves are in control; they can reuse self-contained YAML definitions from others that include everything, share their own… including in the new Marketplace! Since these definitions just follow the UI Components structure, like widgets, they can be easily be offered on the marketplace as well.
The best part of it is that users could choose what to install to their toolbox based on their needs - you just browse the add-on store, see what’s available and install what you need and only that! A set of blocks to deal with GPS positions, another set to deal with date & time, or a block set to deal with specific hardware or services, you name it.
Note that not only new block types could be shared (that involves defining a way to derive JS code from declarative properties with placeholders, that part is not yet done), but also pre-assembled blocks of already-existing types - for instance check the Library > Randomize category on Blockly Demo: Toolbox
In this example you can drag and drop a whole routine block, but contrary to the individual block types that you can define and generate the code of, it’s not a single block: the user in this case can import the block assembly as an example and inspiration, but alter the logic entirely.
So to be completely honest, while these screenshots are real, there is much to do (the code generation part will be the trickiest), and I’ve been figuring out things as a go to make the final spec in my head - but don’t worry it’s coming along nicely.
As a conclusion, @stefan.hoehn don’t take all this all wrong, because I support your work and believe a comprehensive built-in “system library” of blocks is very much needed and there is no conflict, neither in my intent nor in my code; my current work doesn’t really overlaps with yours, and I believe I will merge your PR before I can submit this new code; but in the end I believe Blockly in OH can have a two-tier approach - a comprenhensive, well-tested built-in set of blocks (in the openHAB category and children); and the user/runtime-defined Library.