Coder Legion - Recent posts tagged visual-programming

Flow of Autonomous Brain and its Engine

Thu, 28 May 2026 07:23:50 +0000

On the last post, I mentioned usuage of multiple github models, but made some more modifications, and now 2 new providers are also added to the boardroom.

STAGE 1 ARCHITECT CONFERENCE

     Architect A (Mixtral/Groq) + Architect B (Llama/Groq) propose plans in parallel
     Judge (GPT-4o) synthesises or proposes a more unpredictable plan

STAGE 2 IMPLEMENT

     Engineer (GPT-4o) writes each file with full sibling context

STAGE 3 QUALITY LOOP (up to 8 rounds)

     Reviewer A (Mixtral/Groq) + Reviewer B (Gemini) in parallel
     Fixer applies merged feedback + Playwright interaction test

STAGE 4 QA REVIEW

     Playwright clicks every button, tests every slider
     QA Tester (GPT-4o) issues verdict: shippable / partially_usable / non_functional

STAGE 5 PUBLISH

     New public GitHub repo created via API
     GitHub Pages enabled -> live URL in under 60 minutes from cold start

STAGE 6 SELF-IMPROVE

     CTO (Gemini) reads last 30 failure logs, proposes a surgical source patch
     Validates Python syntax, commits - next build runs improved code

DevLog 20260225: Divooka Visual Programming - Direct Value Setting of Compound Inputs

Wed, 25 Feb 2026 17:55:52 +0000

Finally, it arrived! Well, not exactly here yet, but getting closer.

Overview

Divooka intends to make visual programming simple and accessible - the accessible part is achieved both through wide availability and the general-purpose nature of the programming system, but the simple part is what we spend lots of effort thinking hard trying to improve.

In the past, dealing with complex configuration takes the form of either "explosion" of arguments or dedicated Make XXX construction functions:

The problem arises due to direct exposure of all input arguments in visual programming. Both approach makes the canvas look busy, with the former a common approach in existing systems - using a struct sounds good on paper but still requires a complex looking construction node. This is a common problem in visual programming systems, below shows how it's done in Blender and ComfyUI.

You do get used to it after a while, but a busy looking canvas remains a busy-looking canvas. In Blender, you can sort of "collapse" a node:

As Blender is constantly improving, we can also now collapse property groups as shown in the earlier screenshot.

As a syntax purist and (unfortunately) very conscious about my working space, my eyes can't tolerate messiness. I kind of like how Houdini approaches this.

Essentially they offload all the complexity to the properties panel - this has the huge benefit of making everything look very clean. But the downside is Houdini rely heavily on scripting expressions (like Excel).

TerraGen and World Machine mixes the approach:

In both cases, connections represent flow of terrain data only and additional configurations are offloaded to property panels. In TerraGen especially, this allows those properties to be animated. The downside, once again, is whatever is offloaded to property panels are no longer programmable using nodes.

Our Approach

Our proposed solution for Divooka looks like this: fundamentally all properties remain as node inputs, but compound values (especially value types) should just allow "editing in place" through a property panel. If more complex programming is needed, one can easily fall back to Make XXX nodes again.

Future Work

There is still remaining work on type check, hierarchical compound types, arrays, and serialization, and also node rendering.

Conclusion

As usual with all the exciting language features of Divooka we intend to introduce, there are lots of details to take care of here.

DevLog 20260224 Divooka - Node-Level Automatic Dispatch (Runtime Execution Behavior)

Tue, 24 Feb 2026 22:22:17 +0000

Overview

Anything useful done with a program eventually involves file I/O and some form of repetition.

In Divooka, the dataflow context already makes it very easy to "just get a single thing done." That part feels good. But handling loops? That's where things start to get awkward.

One challenge lies on the GUI side — especially around lambdas and subgraphs. We do have foundational support (as shown here and here), but let's be honest: it's not smooth yet.

So the question becomes: how do we make repetition feel natural without introducing heavy conceptual overhead?

The Plan

There are several well-established ways to achieve looping behavior in a functional or visual programming context:

Subgraph context - Used in tools like Blender, vvvv, and Houdini. A specialized node group or frame defines loop entry and exit boundaries.
Lambda callbacks - Evaluation is handled via callback-style execution.
Expressive recursion - As seen in text-based functional languages, requiring explicit termination conditions to avoid stack overflow.

All of these approaches are powerful and necessary in certain contexts. But they also introduce additional constructs into the language model. For advanced workflows, that's fine. For simple operations, it can feel unnecessarily complex.

I wanted something lighter.

Array Coercion

Divooka already supports Array Coercion — a scalar value can be passed into an input expecting a collection.

This avoids the need to manually "wrap" a scalar into an array just to satisfy a function signature - I still remember the pain of handling arrays in Unreal Blueprint.

Scalar-to-array coercion keeps graphs clean and avoids clustering.

To take this to the next level, I've been giving it much thought on how the reverse might work: if we can coerce scalars into arrays — what if we also let nodes automatically dispatch when arrays are passed in?

Automatic Dispatch (Node-Level)

The core design question was:

Should an array input implicitly turn the entire downstream chain into a loop?
Or should the dispatch behavior stay localized to the node itself?

Eventually it seemed localizing things to the node made far more sense.

For example:

string String.Replace(string, string, string)

If any input is provided as an array instead of a scalar, the node automatically promotes itself to:

string[] String.Replace(string[], string[], string[])

The node executes element-wise.

Now, I can rename a folder of files with roughly three nodes:

Enumerate files
Regex replace
Rename file

No explicit loop node. No subgraph. No lambdas.

In this example, Duplicate as Array returns a strongly typed string[], enabled by generics support.

One important rule: All array inputs must align in size with the source array. The dispatch is index-based and deterministic.

Full Example

What used to require explicit iteration logic now becomes implicit behavior at the node boundary. The graph remains readable. The mental model stays simple.

Conclusion

This is still early work. Integration with the rest of Divooka's features is ongoing, and edge cases are being worked through.

So far so good.

DevLog 20250507 Bringing Smart Suggestions and Smarter Search to Divooka’s Visual Coding

Sun, 07 Sep 2025 23:39:02 +0000

Learning from Unreal Engine Blueprints

I’ve always admired Unreal Engine’s Blueprints - particularly its subtle yet powerful connection suggestion feature. When you drag a wire out from a pin, the system intuitively suggests compatible nodes based on the pin’s data type.

This kind of context-awareness accelerates creation and keeps workflow fluid by making things just work - no guesswork needed.

The Challenge: Missing Type Labels in C# Instance Methods

Divooka, built atop C#, posed a snag: instance methods don’t include the object’s type in their signature. So if a method like Rotate() belongs to a Transform object, the type isn’t explicitly declared in the method signature - making automatic suggestion tricky.

To match Unreal’s intuitiveness, I needed a way to tell Divooka - not just "Rotate()", but Rotate() on Transform.

Explicit Type Filter in Search Syntax

The first step is to allow users to filter the toolbox explicitly in their search query.

For example: [Pixel Image] Save would filter for methods in the Pixel Image toolbox (category). The symmetry of this syntax remains intuitive even in localized languages like Chinese - because only the type would be translated, not the syntax design itself.

Building the Pipeline: Filtering and Highlighting

Next, I leveled up the search experience by crafting a multi-stage pipeline:

Category names (like [AI Service], [Pixel Image]) now at the front, so users can scope their search by purpose.
Then we optionally parse <TypeName> syntax, which is used to filter input parameters.
Finally, full-text search for other keywords.

So a query might look like:

[Pixel Image] <String> Save

In which case we will search only for functions containing the word "Save" and expects a String parameter. Visually, I emphasized that first category tag with syntax highlighting to help the eye quickly scan.

The Result: It Just Works (Mostly)

Here’s how it currently looks:

Type [Pixel Image] Save.
The search autocomplete suggests all instance methods named Save...() defined in Pixel Image toolbox (mostly operating on the PixelImage object type) (e.g., PixelImage.Save, PixelImage.Load, etc.).
Everything lights up in palette instantly - users can find what they need fast.

What’s Missing: Auto-Connecting Suggestions

This solves the searching half of the problem beautifully - but it doesn’t yet auto-connect. In Unreal, dragging from a Vector pin might instantly suggest Normalize() - and connect it for you if you click that suggestion.

Right now, Divooka still requires a manual drag-and-click - our intention was only searching and filtering, not full drag-and-drop automation.

Next Steps: Toward Full Contextual Suggestions

I’m plotting the future:

Pin-aware suggestion: When dragging a wire from a pin, immediately filter down to matching methods—and optionally even pre-wire the node when hitting “Enter” or double-clicking.
Type inference: Avoid requiring <Type> if the context is obvious - since the system already knows the pin’s type.
Better localization: Make sure category tags and type filters localize cleanly, without mangling grammar in languages like Chinese, Japanese, etc.
Enhanced UX hints: Perhaps grey-out non-matching nodes live, or provide quick tooltips (e.g. “only shows methods on Transform”, like Unreal Blueprint's node search interface).

Summary

Previously, instance-based methods don’t expose their object type; this hampers auto-suggestion. We solved this by introducing explicit <Type> filters and category tags in our search syntax. The result is now the users can quickly locate relevant methods with filtered search - instant clarity. Up next, we want to add full context-aware, auto-connecting suggestion - move from “search” to “smart connection.”

Conclusion

Unreal Blueprints’ delightful node suggestions inspired us to refine Divooka’s search. By introducing syntax like [Category] <Type> Keywords..., Divooka now lets you filter instance-based methods explicitly - greatly improving discoverability. Coming up: auto-connection and smarter, context-aware wiring.

Let me know if you are interesting in learning more specific implementation details - like the regex matching, indexing logic, or localization strategy!

Happy visual coding!

DevLog 20250816: Divooka Language Specification (Preliminary Look)

Sat, 16 Aug 2025 19:41:04 +0000

Overview

Divooka is a cutting-edge visual programming platform developed by Methodox Technologies, Inc. It enables users to build and deploy complex applications through a drag-and-drop, node-based interface that integrates seamlessly with C# and Python libraries.

Key Features

General-Purpose & Flexible: Suitable for a wide range of use cases - from business tools to innovative software products - supporting both automation and application development.
Node-Based Visual Interface: Workflows are constructed visually by connecting nodes that represent data operations, logic, APIs, and more.
Multiple Editions:
- Divooka Explore: A beginner-friendly, Windows-only edition designed for learning, data analytics, dashboards, programming, and everyday utilities.
- Divooka Compute: A professional package built on the same engine, aimed at power users. Currently available as a Windows preview build, with Linux and macOS support planned for the full release.
Cross-Platform Vision: While early versions support Windows, full Linux and macOS support is planned.
Strong Architectural Foundations: Based on Data-Driven Design principles, Divooka emphasizes modular, external control of behavior through data files - streamlining workflows without modifying code.
Developer-Centric Philosophy: Divooka is not a new programming language per se. Instead, it focuses on decoupling functionality from specific environments to maximize flexibility and usability.
Active Development & Community: Ongoing updates, documentation (wiki), tutorials, a Discord community, and blog posts ensure an active ecosystem.

Divooka is built around node graphs as executable documents. Instead of writing sequential code, developers construct graphs of nodes, where each node represents a unit of computation or data. This graph-based approach supports both dataflow-oriented and procedural-oriented paradigms. A Divooka script file (a "Divooka Document") acts as a container for node graphs.

At its simplest:

A Divooka document contains multiple graphs.
Each graph contains multiple nodes.
Nodes have a type, an optional ID, and attributes.
Node attributes can connect to other nodes’ attributes.

In a Dataflow Context, node connections are acyclic; in a Procedural Context, connections may be cyclic and more flexible.

Interpretation

To illustrate the simplicity of the language, we can write a minimal interpreter in Python.

This interpreter handles an acyclic graph of nodes with Type, ID, attributes (all strings), and connections between attributes. Connections are represented directly as attribute values: if an attribute value starts with @, it refers to another node’s attribute (e.g., @Node1.Value).

For example:

DefineNumber outputs a number in its Value attribute.
AddNumbers takes two numbers as inputs and produces a Result.
Print consumes the Result and prints it.

The interpreter maps node types to operators, executes them, and produces results.

# minimal_graph_interpreter.py
# A tiny, in-memory, non-cyclic node graph + interpreter.
# Nodes have: Type, ID, attrs (all strings). Connections are '@NodeID.Attr'.

from typing import Dict, Any, List, Callable, Optional, Tuple

Node = Dict[str, Any]  # {"ID": str, "Type": str, "attrs": {str:str}, "state": {str:Any}}

def is_ref(value: Any) -> bool:
    return isinstance(value, str) and value.startswith("@") and "." in value[1:]

def parse_ref(ref: str) -> Tuple[str, str]:
    # "@NodeID.Attr" -> ("NodeID", "Attr")
    target = ref[1:]
    node_id, attr = target.split(".", 1)
    return node_id, attr

def to_number(s: Any) -> Optional[float]:
    if isinstance(s, (int, float)):
        return float(s)
    if not isinstance(s, str):
        return None
    try:
        return float(int(s))
    except ValueError:
        try:
            return float(s)
        except ValueError:
            return None

class Interpreter:
    def __init__(self, nodes: List[Node]):
        # normalize nodes and build index
        self.nodes: List[Node] = []
        self.by_id: Dict[str, Node] = {}
        for n in nodes:
            node = {"ID": n["ID"], "Type": n["Type"], "attrs": dict(n.get("attrs", {})), "state": {}}
            self.nodes.append(node)
            self.by_id[node["ID"]] = node

        # map Type -> evaluator
        self.ops: Dict[str, Callable[[Node], bool]] = {
            "DefineNumber": self.op_define_number,
            "AddNumbers": self.op_add_numbers,
            "Print": self.op_print,
        }

    # ---- helpers ----
    def get_attr_value(self, node_id: str, attr: str) -> Any:
        """Return the most 'evaluated' value for an attribute (state overrides attrs)."""
        node = self.by_id.get(node_id)
        if not node:
            return None
        if attr in node["state"]:
            return node["state"][attr]
        return node["attrs"].get(attr)

    def resolve(self, raw: Any) -> Any:
        """Dereference '@Node.Attr' chains once (graph is acyclic so one hop is enough)."""
        if is_ref(raw):
            nid, a = parse_ref(raw)
            return self.get_attr_value(nid, a)
        return raw

    def all_resolved(self, values: List[Any]) -> bool:
        return all(not is_ref(v) and v is not None for v in values)

    # ---- operators ----
    def op_define_number(self, node: Node) -> bool:
        # Input: attrs["Value"] (string number). Output: state["Value"] (numeric)
        if "Value" in node["state"]:
            return False  # already done
        raw = node["attrs"].get("Value")
        val = self.resolve(raw)
        num = to_number(val)
        if num is None:
            return False  # can't parse yet
        node["state"]["Value"] = num
        return True

    def op_add_numbers(self, node: Node) -> bool:
        # Inputs: attrs["Value1"], attrs["Value2"] (can be @ refs). Output: state["Result"]
        if "Result" in node["state"]:
            return False
        v1 = to_number(self.resolve(node["attrs"].get("Value1")))
        v2 = to_number(self.resolve(node["attrs"].get("Value2")))
        if v1 is None or v2 is None:
            return False
        node["state"]["Result"] = v1 + v2
        return True

    def op_print(self, node: Node) -> bool:
        # Input: attrs["Result"] (@ ref). Side effect: print once. Also store state["Printed"]=True
        if node["state"].get("Printed"):
            return False
        r = self.resolve(node["attrs"].get("Result"))
        # Allow printing numbers or strings once the reference resolves
        if r is None or is_ref(r):
            return False
        print(r)
        node["state"]["Printed"] = True
        return True

    # ---- execution ----
    def step(self) -> bool:
        """Try to make progress by evaluating any node whose inputs are ready."""
        progressed = False
        for node in self.nodes:
            op = self.ops.get(node["Type"])
            if not op:
                # Unknown node type: ignore
                continue
            progressed = op(node) or progressed
        return progressed

    def run(self, max_iters: int = 100):
        """Iteratively evaluate until no changes (DAG assumed, so this stabilizes quickly)."""
        for _ in range(max_iters):
            if not self.step():
                return
        raise RuntimeError("Exceeded max iterations (graph might be cyclic or ill-formed).")


if __name__ == "__main__":
    # --- Example in-memory graph ---
    graph = [
        {"ID": "Node1", "Type": "DefineNumber", "attrs": {"Value": "3"}},
        {"ID": "Node2", "Type": "DefineNumber", "attrs": {"Value": "5"}},
        {
            "ID": "Adder",
            "Type": "AddNumbers",
            "attrs": {"Value1": "@Node1.Value", "Value2": "@Node2.Value"},
        },
        {"ID": "Printer", "Type": "Print", "attrs": {"Result": "@Adder.Result"}},
    ]

    interp = Interpreter(graph)
    interp.run()   # Should print: 8.0

Running the example graph prints:

8.0

Summary

The Divooka language demonstrates how a minimalist graph-based specification can serve as a foundation for both computation and orchestration.

Key takeaways:

Node-Centric Abstraction: Everything is reduced to nodes with types, IDs, and attributes - uniform, extensible, and easy to interpret.
Simple Reference Mechanism: The @NodeID.Attr convention provides a straightforward but powerful way to connect attributes.
Separation of Concerns: Distinguishing between dataflow (acyclic, deterministic) and procedural (control flow, cyclic) contexts allows Divooka to cover both declarative and imperative styles.
Composable Operators: Even with just three operators (DefineNumber, AddNumbers, Print), meaningful behaviors emerge.
Compact Interpreter Footprint: The entire interpreter is under 200 lines of Python, demonstrating the specification’s simplicity and rapid prototyping potential.

One might ask why not use traditional graph connections. The answer is simplicity: defining connections as local attribute references reduces structure while keeping graphs clean. In dataflow, inputs typically come from a single source, while in procedural contexts, outputs are unique but inputs may be shared, so we can just reverse the syntax - making this lightweight approach intuitive and efficient.

Reference

Wiki (WIP): Divooka Language Specification

DevLog 20250728: Multi-graph Navigation GUI

Tue, 29 Jul 2025 17:19:46 +0000

Overview

From the beginning, we've expected Divooka documents to support multiple graphs for efficient daily use. I consider this essential for scripting purposes, as dealing with file system entry references should be the last thing on our minds when trying to get something done quickly.

However, implementing this isn't straightforward. Several interesting and foundational features are required first: serialization, file format support, editor refactoring - and graph referencing, which we may discuss in a future entry.

In traditional programming languages, especially object-oriented ones, similar functionality is often achieved by allowing multiple classes per file. In C#, for example, it's even possible to define partial classes across separate files, which can become confusing if not managed carefully.

Objective

When working with multiple graphs in a single document, the experience should feel similar to working with separate documents that each contain a single graph. At the most basic level, the editor should allow quick and seamless switching between graphs. More advanced features will come later. For example, storing multiple graphs within a single document should eventually enable referencing those graphs or documents from other documents.

Implementation Progress

Today's goal was to support navigation and switching between different graphs in Neo.

Preliminary work on refactoring the graph editor into a reusable component was already completed earlier. This refactor is also crucial for enabling the subgraph editing window.

To maintain context when switching graphs, the current viewport remains unchanged. We've also implemented a mini-map to help users quickly identify their location within the graph.

Minimap Behavior

The math behind the minimap is a bit tricky, so it's worth documenting:

When switching between graphs, the editor should either preserve the current viewport (location and zoom) or reset the view to the center of the new graph.
A "world boundary" must be calculated that encompasses all nodes in the graph.
A "viewport boundary" should also be calculated to represent the currently visible area of the canvas.
The minimap scale (typically less than 1 to represent downscaling) should be the minimum of:
- minimap size / world size, or
- minimap size / viewport size, if the viewport is larger than the world (e.g., when zoomed out).

Other Matters

The Neo graph editor is taking noticeably longer to load lately. We may need to investigate and address performance issues soon.

DevLog 20250711: Flappy Bird in Divooka! (Sneak Peak)

Fri, 11 Jul 2025 19:38:55 +0000

Sneak Peek

I'm very excited to share some updates, along with this early demo video of making and playing Flappy Bird in Divooka! Please take a look at our YouTube for the HD video!

There's a lot of technology packed into and behind this little demo.
Sure, there are hacks here and there - like all video games - and there's still tons to be done to make it production-ready and robust. But I think this is a good, solid proof-of-concept! We are at least at parity with what Unreal Engine Blueprint can achieve for interactive 2D games!

Overview

Divooka by Methodox is our flagship visual programming language and programming platform.

In the YouTube video, I shared a quick demo of the program setup, graph layout, and runtime behavior of Flappy Bird made in Divooka.

This setup is entirely done in the Divooka procedural context as a proof of concept for competitive runtime performance, suitability for practical program development, general applicability of the Divooka language, and the availability of Glaze! - our real-time graphical application API.

A detailed tutorial, along with all resource files, will be shared under the Methodox Wiki when the time comes.

Dev Process

The latest update on the procedural context visual debugger has been really helpful!

For the purpose of this particular demo, I started in Divooka, then realized lots of missing pieces. So I drafted the API for Glaze! first, then did a benchmark in C# - so actually, there is a pure C# implementation before the Divooka implementation.

The urgent need for generics becomes evident when we don't have structs and other OOP constructs in Divooka - we need a way to contain tuples of values in collections.

Commentary

Unreal Engine can already do it - and we're just catching up. On the other hand, Unreal Engine actually packs a similar size - but with way more features! Reducing distribution size is something that will require tremendous effort from us.

References

Learn more about procedural context: Methodox Wiki
YouTube: Divooka Visual Programming
Tutorial on making Flappy Bird in Divooka(WIP): Methodox Wiki

The Divooka Way - Part 1: Philosophically, How Exactly is Divooka Different and Useful

Wed, 09 Jul 2025 20:28:58 +0000

Full title: The Divooka Way — Part 1: Philosophically, How Exactly is Divooka Different and Useful Compared to Plain Good Code API
Tags: Visual Programming, Developer Tools, API Design, Software Architecture, Programming Paradigms, NVI, No-Code / Low-Code, Programming Philosophy, Tool Economy
Target Audience: Software Architects, Engine and Tool Developers, Programming Educators and Curriculum Designers, Low-Code/No-Code Platform Researchers, Senior Developers interested in alternative programming models, Developers interested in visual alternatives to traditional code*

Abstract

Traditional programming uses text to represent program logic. Existing visual design platforms offer varying levels of programmability but generally focus on building specific kinds of applications. From a production-use perspective, Divooka represents a significant step forward in how users build and interact with software - by combining tool-building, data handling, and program logic under a single, coherent interface. This unified approach aims to deliver a substantial productivity boost.

Overview

If we already have a really good library - just as we have high-quality commercial software - does it still matter what language or environment we use?

In theory, it shouldn't. In practice, it absolutely does.

Pretty much everything imaginable already exists for C++, often under GNU licenses. But that doesn't mean a Python, C#, or Java developer can easily access or use those resources. Even when libraries are available for a target language, usage may not be straightforward. Licensing, API design, and documentation all come into play.

Still, let's imagine we have a well-written, freely accessible, multi-language-bound, well-documented, and easy-to-use library. Does it then matter how we use it?

That leads us to the core question:

If we already have a really good API, why not just use it in C#, Python, C++, Lua, or Pure?

The Proof of Concept

To explore this, we can approach the question from three distinct perspectives:

The end user
The program designer
Everyday tool development and sharing

From the end user's perspective, assuming the final deliverable is a polished CLI or GUI tool, it typically doesn't matter what language was used - as long as the interface is well-designed. Case closed.

From the program designer's perspective, building anything sophisticated involves significant "dry" work - debugging, iteration, architectural decisions. Productivity depends largely on the quality of the debugger and IDE, and again, it's not strictly tied to the programming language.

But from the perspective of everyday tool use, the question becomes more subtle. What do we mean by "everyday tools"? Broadly speaking, we mean:

Tools built quickly to solve practical problems within days
Tools that are easy to share and use by others
Tools that are easy to iterate, improve, refactor, and eventually package as full software
Tools that are maintainable - so that months later, we can return and still understand what we were doing, without extensive documentation effort

To solve (1), you need extensive libraries.
To solve (2), you need solid dependency and packaging mechanisms.
To solve (3), you need simple syntax and easy refactoring.
To solve (4), you need expressive, self-documenting code - or better yet, self-explanatory program design.

It's in this third category - everyday tools - that Divooka stands out. The features baked into Divooka's graph editor enable rapid development without sacrificing performance or scalability. The editor itself proves how smoothly things can run with minimal setup: just open a graph document, and it works.

The NVI

In Divooka, the primary mode of interaction is the Node Visual Interface (NVI) - distinct from both CLI and GUI paradigms.

Each node represents a functional unit, and the connections represent program or data flow. Unlike CLI, NVI offers "autocomplete" visually - everything is made explicit through connection and layout. Unlike a GUI, an NVI is composed entirely of nodes and avoids complex syntax structures.

At the base is a node canvas, and programs are built using what we call node-driven design - a pattern that breaks software into node blocks, each representing a compositional or procedural component.

The main disadvantage of NVI compared to text-based programming is space inefficiency: nodes occupy screen real estate, reducing information density. But this is offset by improved readability: the visual layout shows the exact dependencies between functional units - something much harder to grasp in linear text code.

NVI becomes more powerful when it supports:

Subgraphs – Logical groups of nodes encapsulated into single blocks. This is more compact than plain functions or classes and more intuitive than managing multiple files.
Extensible node visuals – Nodes can be customized for specific data. For example, a Table node can offer compact entry for 2D data, reducing friction.

The Scripting Interface

At its core, the NVI exposes functionality in two ways:

Nodes represent standalone functional units in a Divooka document.
A framework parses the interconnected nodes and derives behavior from the graph structure.

The key is interface availability - file operations, media I/O, math routines, etc.

The first use case is covered well by scripting languages like Python, Lua, or Jupyter.
The second - interpreting a structured node graph into dynamic program behavior - is where traditional languages fall short, often requiring large, specialized frameworks (e.g., Streamlit for Python).

With Divooka, the same graphical program often needs no changes at all. A simple toggle in the host environment can completely redefine how the program behaves.

Frameworks like Glaze, Novella, Ol'ista, Slide Present, and App Builder (all part of Divooka Explore except App Builder) rely heavily on metadata - information not defined on the graph, but embedded in the document and interpreted by the host system.

This separation - code in the graph, behavior defined by metadata - creates a powerful, data-driven model that enables reuse, variation, and flexibility.

On the Matter of Libraries

Not all useful features are readily available via libraries. And even when they are, compatibility issues, licenses, platform differences, and interoperability challenges often make reuse hard or impossible.

At Methodox, we actively author and maintain a curated library set - toolboxes optimized for Divooka. This represents a major investment, ensuring that as Divooka grows, users have an expanding, well-integrated set of native components tailored for node-driven environments.

Summary

From a scripting standpoint, Divooka may appear unremarkable: libraries are still authored in native code, and Divooka simply provides an interface layer.

But methodologically, Divooka offers a profound shift in how we build and interact with programs. It's as different as using a natural-language model to co-write your software.

Divooka is a high-level, GUI-native, NVI-first programming system. Our belief is that this new format can significantly enhance productivity, readability, and maintainability by making programs smaller, clearer, less error-prone, and more intuitive.

A General Service Configuration Scheme in Graphical Context

Sun, 25 May 2025 06:16:54 +0000

Overview

In this article, we take a look at one emerging pattern that provides a straightforward and compact way to configure services. Generally speaking, when a function expects many inputs, the most straightforward way is to directly expose those on the node. However, this quickly makes the node gigantic in size.

(Node with many parameters)

(Example in ComfyUI)

When a node has too many parameters, it becomes bulky.

(Example in Blender)

This quickly becomes infeasible when even more complex parameters are required for the functioning of nodes—for instance, if it's an online service with many potential configuration settings. A typical approach is thus to utilize a GUI element, which we shall call a "node properties panel." Below is a sophisticated example from Houdini. PowerBI and Zapier do similar things.

(Houdini node configuration panel)

This method falls short for two reasons:

It's not explicit, and configuration parameters are not visible on the graph. Which makes it not possible to see dataflow nor to programmatically drive those values.
It requires a dedicated GUI and can only be configured within that GUI.

The Design Approach

Usually, some kind of scripting or expression language is used to address the first problem. For instance, in Houdini, users often write VEX snippets or Python expressions inside parameter fields to control behavior dynamically. In Zapier, configuration can include custom JavaScript code or formulas in input fields to manipulate data between steps. These workarounds bring back some level of flexibility, but at the cost of breaking the visual flow and requiring users to write code inside otherwise "no-code" or "low-code" environments.

One design goal of Divooka is to be frontend-agnostic. The currently released frontend is officially known as "Neo", which is a WPF-based technology. However, Divooka graphs are designed to be generic enough to be visualized on different frontends—ideally in a way that's very easy to implement. That’s why we prefer to expose everything explicitly, so no specialized logic is required on the frontend (e.g., to be aware of the nodes they are dealing with).

Configuration in Divooka

Visually, we have a ConfigureX node and some nodes that take a configuration parameter as input. This dominant pattern is used in many places, including plotting configuration, OpenAI service configuration, and some other APIs like the image composition API.

(Example of plot configuration)

(Example of OpenAI service configuration)

(Example of image composition API)

We could provide a few different overrides for creating a configuration—so depending on how many details are needed, one can use a more lightweight or more heavy-duty configure node.

(PostgreSQL with two different configurations)

That concludes our introduction to the current setup, but the versatility of Divooka doesn't end here. Indeed, we could also introduce some kind of GUI panels for advanced configurations, and in fact, that’s desirable for certain things - at the price of losing the capability to programmatically drive the parameter values. This will be an expected standard feature in the full release of Divooka.

References

This article reference the following software:

Houdini – A professional 3D animation and visual effects software used in film, TV, and games, known for its node-based procedural workflow.
Blender – A free and open-source 3D creation suite that supports modeling, animation, simulation, rendering, and more.
ComfyUI – A graphical node-based interface for building image generation workflows using AI models like Stable Diffusion.
PowerBI – A business analytics tool by Microsoft that lets users visualize data and share insights across an organization.
PostgreSQL – A powerful, open-source relational database system with a strong emphasis on extensibility and standards compliance.
Divooka – A general purpose programming language for building procedural programs and data flows through node graphs.
Zapier – An online automation platform that connects different apps and services to automate workflows without coding.