Ryven

* PyQt6/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](https://github.com/leon-thomm/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](https://github.com/leon-thomm/Ryven/blob/master/README.md) 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](https://github.com/leon-thomm/Ryven/tree/master/ryven-editor/ryven/example_nodes) directory.

- 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

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](https://github.com/leon-thomm/ryvencore)
- 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](https://github.com/leon-thomm/Ryven/discussions/68#discussioncomment-877010)), 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

**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](https://ryven.org) now has a complete guide.

The underlying frameworks are `ryvencore` (backend) and `ryvencore-qt` (frontend), the repository is [here](https://github.com/leon-thomm/ryvencore-qt). `ryvencore` and `ryvencore-qt` are completely separated, which brings a whole lot of improvements, see [ryvencore-qt](https://github.com/leon-thomm/ryvencore-qt) and the [website](https://ryven.org) 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.