• Qt6/Side6 support (#189, #178)
• improved nodes package system, now supports sub-packages and better UI separation
• improved package overview in the editor (#171)
• new per-node inspector UI (#176)
• widget docking in the editor (#171)
• project-persistent window geometry / layout
• improved component selection in the editor (#176)
• improved undo-redo, including interactive history (#176)
• bugfixes

closes #126, #128, #138, #147, #175

This release incorporates substantial changes made over the past 1.5 years, mainly concerning a remake of ryvencore fixing some substantial flaws and correctness issues in the original design, refined API methods, and a better user experience. This should be considered a new edition of Ryven, which includes many breaking changes to previous versions. Please take a look at the README for up-to-date instructions and examples.

I may add some more detailed instructions for porting old node packages if I find time and there’s significant demand. The guide on the website was removed, instead the README provides more detailed instructions, there is a new wiki page, and some example packages are provided in the example nodes directory.

This release brings mainly large architectural changes. Ryven is at this point more a platform than just an application. See also the new README for additional info about current state.

main changes

• Ryven is now a Python package on PyPI, the repository got restructured and cleaned accordingly (big thanks @mmorys)
• ryvencore is now a fully independent library and has its own repository here
• removed macros (see below)

removing native macro support for now

While the alpha release of Ryven 3 had native support for macros (/subgraphs/whatever you might call them), I decided to remove them, for the following reasons:

• Ryven should be thought of rather as a platform which you use to build frameworks of node packages on top. Natively supporting macros, however, significantly complicates the development of all nodes that perform slightly more involved (but not necessarily unreasonable) actions (like analysing the graph), while many node packages might not really require macro support at all.
• Furthermore, the concept or semantic specification of macros is not obvious, many different approaches might seem reasonable. For example: whenever a macro node instance received data on some input, should all data currently residing on inputs of that instance be propagated into the subgraph? In which order? How can this be done efficiently? How should data propagation work for macros with exec I/O? The answers to those questions strongly depend on the use case.
• Also, abstraction functionality like macros provided it can totally be implemented purely based on Ryven’s nodes system (meaning you can build node packages implementing this functionality). It often makes much more sense to apply this functionality only in an environment (nodes package/s) where a general abstraction system is already defined (for example, a system generating a source code from a graph, see also this example), which will answer all questions including the above for that environment. Then, nodes in that environment can be built with the implemented macro mechanics in mind.

So, I’m not really ’removing’ possibilities here, but I think it makes more sense to focus on the nodes for the particular use case and design the system on that level accordingly. I might publish macros with configuration options as nodes package at some point, but it doesn’t need to be part of Ryven itself.

translating your v3.0-alpha nodes and projects

To bring your v3.0-alpha node packages to v3.1

• change from NENV import .../from NWENV import ... to from ryven.NENV import .../from ryven.NWENV import ...

• change the signature of Node.set_state from def set_state(self, data: dict): to def set_state(self, data: dict, version):

  • add static version fields with values like ’v0.0.1’ to your nodes. the version parameter in set_state will reflect the node version under which the loaded node was saved (None if not set), so you can use it to provide backwards compatibility and translate older versions of nodes to new ones to ensure old projects can be loaded

To bring your v3.0-alpha projects to v3.1

• load the project in Ryven 3.1 (it should then run a function on it that turns macro scripts into normal scripts and removes all macro nodes from flows) and save it again

Complete Ryven remake Over the past 6 monts I’ve been abstracting away underlying frameworks reimplementing the core functionality of the software which led to a complete remake of Ryven itself. Ryven 3 is a completely new software (no backwards compatibility to Ryven 2).

Most important change regarding Ryven is the new packages system. The NodeManager has been removed completely, the new nodes system is very different, much simpler and more scalable. Ryven 3 includes small exmaple projects and some default nodes. The new website now has a complete guide.

The underlying frameworks are ryvencore (backend) and ryvencore-qt (frontend), the repository is here. ryvencore and ryvencore-qt are completely separated, which brings a whole lot of improvements, see ryvencore-qt and the website for more details.

Ryven Console is now "officially" supported. Once you created a flow in Ryven, if all nodes you used are compatible with Ryven Console (meaning they run without their GUI/widgets), you can then run the flow in Ryven Console, without any GUI. This way you can run intensive data processing tasks with much higher performance. Further changes:

• New inheritance system for widgets: Widget classes should derive from fixed base classes from now on (I updated existing nodes and the template files). This makes them safer and the source code files cleaner (as you don’t have to implement all possible methods, they are pre-defined in the base classes).
• requirements: I added a requirements.txt file for all libraries to run Ryven and the example projects, so it’s also convenient to set up a virtual environment now.

Ryven now includes a complete integrated python interpreter.

• It is a fully functional REPL so you can do anything you would do in the normal python console
• You can add references to individual nodes, by right-click operation, to access their full API in the console
• All print() calls, exceptions, and debugging messages are automatically redirected to this console

This is going to be one of the major features in the future, the possibilities are endless.

Some major additions and improvements, besides better examples/nodes. In particular:

• new linalg package containing nodes representing most basic matrix operations with nice interface
• two new designs
• heavy improvements in the appearance of source code files, which makes programming nodes much cleaner
• new variable update system: you can now create connections between script variables and methods, so that every time the variable changes, the connected method gets called - which enables much more responsive components that automatically adapt to change of data
• a matplotlib example node
• new internal design management system, it’s easier now to create new designs, so there might be a few incoming
• passive mode for set var node
• and a long list of small fixes and improvements

The release also includes a prototype for a new tool (currently referred to as Ryven Console) to run a Ryven flow on the console, completely without GUI dependencies, with much higher performance which might become important for larger performance-intensive data processing tasks.

One major internal change: the default imports in custom NodeInstances and their widgets aren’t done manually anymore. There are now two env files that automatically import all requirements when Ryven is running. This is much better as it ensures that the import list is always up to date. I updated all existing nodes’ imports.

They work for data as well as execution connections. In exec mode, they also serve as sequence nodes, so you can dynamically add exec outputs that get executed from top to bottom sequentially.

Using a new viewport update mode feature you can now make a flow update the views of nodes when they get updated, even if the flow isn’t fully finished with the current execution. That’s really useful for larger pure data flows doing data processing (like in the OpenCV example, try it there). Furthermore, Flows now have their own settings which get saved and loaded to and from project files to choose an algorithm mode and the new viewport update mode. Also, I added a small ’bubble sort’ example and some basic nodes (there are still quite a few missing, though).

• Ryven has now a Blender design!
• I updated a few internal signatures like the remove_event() method in NodeInstances and widgets
• I changed the way custom input widgets are specified (no widget_type argument anymore)
• I fixed some nodes and widgets and added standard line edits including self resizing ones
• I changed the widgets of a few nodes now using resizing and or borderless line edits which looks way nicer
• I moved the package_path for widgets outside of their class (useful for imports of custom classes etc.)
• there is a new Extract Property node which is really useful, an example is included in the examples project
• and I changed the file extensions to .rpo for projects and .rpc for packages

Ryven finally supports simple node activation animations. Every time a node updates, it starts an animation, making it easy to see what’s going on in the flow. They can be disabled. Furthermore, I updated some new designs and themes. In <code>pretty</code> mode nodes have now shadows.

Internal changes I furtherly distributed the NodeInstance related classes. I extracted the whole painting process and put it in a separate class NodeInstancePainter. Also, animations are handled by a separate class.

Besides a lot of fine grinding (like adding shortcuts and stuff like that), I slightly changed the method reference retaining mechanism, now using a callable class M instead of the m() function (I updated the template files and existing nodes). Furthermore, the existing packages experienced a code revision, I updated many of the notations.

Further changes

• I fixed some problems with special_actions
• I finally fixed the layout issues with NodeInstances when adding/removing/changing content. It still needs to rebuild the layout though, but update_shape() calls are not necessary anymore
• I fixed a copy-paste-move undo/redo bug
• I fixed a lot of nodes and updated notations in their source codes
• I fixed a source code update check issue in the NodeManager
• I changed the setup_ports() procedure. Now a port gets initialized after the NodeInstance itself.
• I added a target option to the Log node to access the default logs

And, there is a website in the making.

A lot of fine grinding and small fixes, and I did a big rework of the NodeManager.

NodeManager changes

• I reorganized some internal processing and made it much cleaner
• it also has source code dialogs now to directly edit the metacodes
• it detects changes in the original source file while editing inside, warns the user, and lets him choose whether to override those or not
• I updated the stylesheets, now using the same as Ryven
• a lot of small adjustments, enhancements, and improvements to significantly support the workflow

Ryven changes

• added a function for using method references in metacode files to enable successful method editing in Ryven
• changed the source code editing info dialog
• fixed a package bug in the val node
• added an API method for NodeInstance to provide direct access to the window’s stylesheet
• changed the structure of saved points in DrawingObjects (Ryven can still load projects using the old signature though)

Besides reviewing the source code of nodes (NodeInstances) and their widgets inside Ryven, it is now also possible to actually edit a specific object’s methods. More specifically:

• Existing methods can be customized (e.g. for debugging) and further methods can be added. (Note that changing a method actually means relinking the method call to a different method and references linked to the original method still point to the original one, not the customized one. I am looking for a way to change that but I am not entirely sure if that is possible.)
• All these changes apply to single instances instead of all objects of the same class.
• What can be written manually in Ryven is equal to what can be parsed in the metacode files (the same module environment is being simulated), so all in the object’s metacode file additionally added classes, for example, can still be accessed.
• All this is accessible through an intuitive GUI in the source code preview area.
• All changes are temporary, they do not get saved with the project, so nothing can sustainably be broken. There is also a reset option for every customized class.

This is kinda ridiculous, I didn’t think this was actually possible and so unlimited. And considering how unexpectedly useful the pure source code preview became, I am really excited about it.

edit: there is a crucial package bug in the new val node when saving/loading a project which will be fixed in the next release.

pyScript became Ryven I am very pleased to present the first Ryven release. Ryven is the result of a huge intern code revision (of what was referred to as pyScript before), reimplementing and reorganizing a lot of intern processing, making it much cleaner. Furthermore, Ryven includes many features that make learning and using it more efficient and fun. A new big example project shows the use of OpenCV nodes which represents a very interesting field of application.

A few of the main improvements for the user:

• handy source code preview
• performance mode for flow editing (important for use on weaker hardware like Raspberry Pi)
• algorithm data synchronization modes (for advanced flow optimization, I will add that to the doc in the future)

The main internal change is that the geometric organization of the contents of a NodeInstance now uses QGraphicsLayout - no ugly manual calculations anymore! And I reimplemented the whole selection process recently too, now using the built-in system by QGraphicsScene. Also, the undo/redo system was reimplemented recently, now using references and not relying on the complex index system anymore.

This version runs pretty well and I can’t wait to see what it is going to be used for in the future, I am really excited.

Added:

• source code preview! You can now see the source code of a placed node inside the editor. A basic syntax highlighting works too. I will add the option to also show any node’s widget classes in the future.
• NodeInstance and OutputPin highlighting on mouse hover
• direct data output value access on mouse hover (over the gate/pin)

Reimplemented:

• the whole selection procedure, now using the built-in system by QGraphicsScene and a std RubberBandSelection
• undo/redo system which now does not rely on indices anymore but instead holds references to the actual objects. A removed object does not get recreated when undoing the remove anymore but the actual object just gets placed in the scene again which is pretty nice. (same for all flow commands)
• Log enabling/disabling process, now working fine with the new undo/redo system

And many small internal adjustments. The only big change left is the reimplementation of the geometric organization of a NodeInstance’s contents via QGraphicsWidgets and QGraphicsLayouts. This will make the code much cleaner but isn’t of the essence for the user.

I removed tokens. This enables slightly easier and more open programming of nodes. Along with that, I changed the algorithm executing the script, so that now data connections are always forward updated on change and not backward updated on request. This makes execution flows slower but pure data flows faster and simpler. I would like to create some live video and audio processing nodes in this version to show what it is capable of. The biggest issue is currently performance when combining dataflows with execution nodes.

First pre-release of this software! This is the prototype that can be seen in a demo YouTube video. It includes basic functionality including a system for dynamically creating and importing nodes and a mostly working flow execution algorithm.

The next releases will be about improving the NodeManager and adding new content. The documentation will experience a lot of improvement too, I think.