Open lucabtz opened 6 years ago
Yeah, it might also be worth reverting all my changes with the data model and everything to bring the simplicity back. The problem is that I shipped the product for which I invested so much time to improve this project and it's mostly EOLed now. I may or may not eventually revive it and add a QML version, but it seems unlikely. It works for my restricted use case but all the improvements I made have unhandled corner cases and bugs that may or may not limit the usefulness of the whole library for some other use cases.
Sure, having a proper QtModel backend and implement various Qt concepts along with easier to manage serialization is generally useful, but only when it works all the time, not 95% of the time like the current code. I don't think there is many "real world users" right now.
To use this in its current form, either you go back to the very old commits where the GUI worked fine but it was rather hard to build complex projects or you use the current API that's mostly undocumented and has a bunch of know bugs but can be used for very complex projects.
Note that the "doc" for the current version is the same as any Qt Model/View widgets. You write a model and then all the magic lets you link various QModelIndex
together. There is also an alternative API where you can use QObject
s directly and their USER
Q_PROPERTY will be converted into a model automagically for you.
I'm currently not sure if reverting all the changes that @Elv13 introduced is a good idea or not. Generally speaking, I really like the abstraction, i.e. making sure that the Node Editor generally follows Qt's model-view-controller approach. On the other hand, however, I can understand that people find it particularly difficult to get the NE running, especially given the current lack of documentation. I would highly appreciate if someone takes over the documentation part. With respect to the simplicity of the original NE before @Elv13's changes, maybe it's possible to introduce some helper functions that hide the complexity of the currently existing NE and provide a simple interface akin the original NE. However, this sounds a lot like too many wrappers...
A quick note about why the NE didn't see a lot of love lately: I originally developed it as I thought I could use it to quickly develop neural network models for some computational neuroscience and robotics purposes. During the development of the NE, the focus of my work shifted away from the robotics part and more towards theoretical and computational neuroscience, for which the NE didn't help much. Hence, I put it in second (or even third?) place. Personally, I would love to see someone to take the NE from its current state into a mature library. As my time is unfortunately quite limited, I won't be able to contribute too much, but will put more effort into it than before if there is an interest.
This library seems awesome to me, but getting into it require quite much time as you can just read the examples, rather than a detailed documentation or how tos, I suggest making some kind of basic wiki for this, I may help with if necessary