Open luzpaz opened 2 years ago
Yes, we agree, we had created our project based on the original PyFlow because the Microelly Node Editor has bugs. This seems to be a good idea, especially since we could add packages like modules to PyFlow.
It should also be noted that PyFlow is not finished and some features do not work so the software can sometimes bug without reason.
Indeed.
It would be good to research if there are active forks of PyFlow as well. Did y'all check for that?
Yes, unfortunately there are none
I know, it is a pain to switch frameworks, but I wonder if you have had a look at Ryven, which is actively maintained and has a very responsive developer?
We agree with you. But we haven't tested your module yet and we couldn't see how to create buttons and packages under your module. If these two options are fulfilled then we can do it.
First I would like to point out, that Ryven is not my module. You have to kudos to the original author.
You certainly can produce packages: https://ryven.org/guide#/?id=programming-nodes
It is also possible to add any Qt widget to the graphical representation of a node: https://ryven.org/guide#/?id=custom-widgets
There is a node with a button included:
And there is a clock node included, which has a start/stop button:
Does that suffice or would you need anything else?
Please notice the integrated PyFlow is now FreeCAD-tuned with PySide2 dependency instead of Qt.py.
Good point. I am neither the developer of Ryven, nor a Qt developer. I only know, that I had to install PySide2 to get it working …
This weekend we are going to test Ryven and see if it could be suitable for FreeCAD.
@SHaiZen25, I do not know, how you embed the flow editor into AnimatinFreeCAD, but you might want to use PR https://github.com/leon-thomm/Ryven/pull/96 (that's my involvement with Ryven), because it makes this process configurable. You can also always contact Ryven's author with any question – or me regarding the PR mentioned above.
Good luck!
We have tested your module and for the moment we find it difficult to project ourselves in it, so we prefer to stay with PyFlow
No problem. As I already said, it is not my module. I just thought, it might help.
Out of curiosity, may I ask, what the difficulties were you encountered?
As we said, we would like to have this package window containing all the blocks in categories, subcategories, etc. The arrangement of the blocks in the lower left window does not satisfy us. Also there are no buttons available. We also did not understand how to type (e.g. int, string, etc.) a variable. We find that the buttons of the nodes are not very pretty. But your strong point is that the pin values are visible directly and not on a property block. It is much more visible. Concerning getvar, setvar it's a pity not to have a dropdown list with all the variables on the right instead of having to write it. Finally we are less fan of the aesthetics of your module. You should mix PyFlow and Ryven.
Thanks for taking the time to reply.
Again I want to point out, that I am not the author of this library/module, so it cannot be called my module. I became only involved, because I desperately wanted command line arguments …
I find your insight very interesting:
As we said, we would like to have this package window containing all the blocks in categories, subcategories, etc. The arrangement of the blocks in the lower left window does not satisfy us.
That is exactly how I see it. It would be great, if it would be able to have at least categories. On the other hand, the tag system is really handy to just display a certain category.
Also there are no buttons available.
What do you mean, that there are no buttons available? I was always of the impression, that you could include a button in a node.
Or do you mean toolbar buttons? – That is also something, I am missing.
We also did not understand how to type (e.g. int, string, etc.) a variable.
You can use dtypes
…
We find that the buttons of the nodes are not very pretty.
You are absolutely right. But how I understand it, you can write your own stylesheet and make everything in the flow window looking like you want it.
I also always use the plain
windows style, which is not yet in the main branch, because I do not like the styled windows at all.
Concerning getvar, setvar it's a pity not to have a dropdown list with all the variables on the right instead of having to write it.
Can you please explain that in a bit more detail?
Finally we are less fan of the aesthetics of your module.
You are absolutely right here!! PyFlow looks really pretty. As said previously, I always use the plain
window style (coming hopefully in the next release) and one of the nicer flow themes. I believe both can be changed to your liking with stylesheets, which you can adapt yourself.
You should mix PyFlow and Ryven.
Absolutely!
Myself, I was looking for a flow based ‘programming’ interface and first found VisTrail. When that stopped to be supported, I found PyFlow. Unfortunately this was also not maintained anymore, so I switched to Ryven. It would be really great, if those two packages could be merged!
Hello, excuse me for responding so long after the fact. I meant a toolbar for buttons.
Regarding types, I don't know if we are talking about the same thing but basically allowing the user to use types. For example in freecad, there is the object type. This will reduce the error cases to be made in the code. In addition, it would help the user to understand what he can assign to this variable
When using a setVar or getVar block we must provide it with a variable name to be written in string. If we offer the user only the variables he has created he cannot make mistakes in the get or set var
Translated with www.DeepL.com/Translator (free version)
Thanks for taking your time!
Regarding types, I don't know if we are talking about the same thing but basically allowing the user to use types. For example in freecad, there is the object type. This will reduce the error cases to be made in the code. In addition, it would help the user to understand what he can assign to this variable
If I understand your correctly, you want to restrict the connection to the input of a node to a certain type, e.g. the user cannot connect a float
output to a FreeCAD object
type input?
Well, I can see the point here. On the other hand this is controversy to Python's ducktyping philosophy. Honestly, I do not know, which approach is better! (Which makes it a classical candidate for a configuration option.)
When using a setVar or getVar block we must provide it with a variable name to be written in string. If we offer the user only the variables he has created he cannot make mistakes in the get or set var
I think, that is a valid point and an issue should be opened!
looks like PyFlow is active again?
@j8sr0230 are you planning on consolidating your changes to AnimationWB and PyFlow?
@luzpaz I would be happy to contribute. So far, I have only fixed a few bugs that I noticed while using PyFlow. In parallel, I am working on FreeCAD nodes for modeling (cf. Grasshopper or Sverchok). I'm not sure if it makes sense to revive the PyFlow repository (my pull request apparently fizzled out), or if it's time for a higher-level community-driven FreeCAD node repository with a FreeCAD version of PyFlow. What are your thoughts on this? By the way, many thanks to the excellent preliminary work from the developers of the AnimationFreeCAD-WB and microelly2!
May I jump in here again: As you know, I had big hopes for Ryven, mainly because it looked to be actively maintained. So I made some pull requests, but in the end the original author went quiet for a long time and unfortunately some copyright issues are still not resolved. So I had a fresh look at PyFlow despite being unmaintained. Nevertheless I implemented some changes, such as:
I am currently working on the ability to enter a pin's value directly in the node instead of opening the Properties
toolbox and editing the value there. (I plan to include @luzpaz PR after I have finished this.)
These changes are not published yet, because I am not yet sure how to proceed:
If AnimationFreeCAD relies on the PyFlow framework, it might be a good idea to set up a common repository (I would suggest codeberg.org, which I use for some other projects – I could do the administrative work). What do you think?
This is great..looks like things are coalescing around PyFlow for FreeCAD. Thank you to all the devs that have contributed their time.
If AnimationFreeCAD relies on the PyFlow framework, it might be a good idea to set up a common repository (I would suggest codeberg.org, which I use for some other projects – I could do the administrative work). What do you think?
@sphh can we have a mirror on github as well that accepts PRs ? Issues + PRs can also be managed on codeberg simultaneously?
I believe it's possible to mirror repositories between github/gitlab/codeberg/… I myself prefer codeberg, because of privacy issues with the other servers.
Do we want to start with the original PyFlow or with the AnimationFreeCADWB?
Good point! Both have quite a lot of commits, so I would expect quite some manual merging :confounded:
What are the main changes/addition of the AnimationFreeCADWB compared to the original PyFlow?
As far as I can see, the AnimationFreeCAD WB uses the original PyFlow, at least I find the same errors e.g. regarding the Drop On Wire functionality. All additional nodes and functions belong to the animation package. In my opinion we could use the original PyFlow as a starting point.
In my opinion we could use the original PyFlow as a starting point.
This makes sense to me
Ah, if the only commits are related to the animation package, then it should be easy: Starting with the original PyFlow both of us could commit our changes without interfering! That would be easy.
So I continued my work in my fork of the original PyFlow, so I can shoot everything upstream when we have a collaborative repo?
Yes, that is the idea!
It is also always possible to mirror it to this repository.
I have the feeling, that we should rename this fork we were talking about. Any ideas? After we have agreed on a name, I can set up the repository on codeberg.org under that name.
I for codeberg AND mirroring to github
We want to optimize PyFlow as a node editor for FreeCAD and then develop FreeCAD nodes, right? So when naming the project, we could focus less on the node editor itself and more on the final result. How about FreeCADNodes (similar to Geometry Nodes for Blender). Within the project we could place AnimationNodes, SolidNodes, CurveNodes, etc. as PyFlow packages.
I guess i'm trying to get the best of all worlds:
But this maybe too romantic/optimistic
This speaks for a pure PyFlow repository and another one with PyFlow packages like FreeCADNodes? I like that! Then we could start with a pure fork of the original PyFlow rep.
On a different note, I've been thinking a bit about the conceptual integration of nodes into parametric CAD systems. Currently, my nodes operate on shapes that I get from FreeCAD TreeObjects and bake new shapes based on them, just like microelly2. This brings the danger that FreeCAD Tree and PyFlow Node Tree develop independently from each other. FreeCAD has a great parametric concept with which scripted objects with properties can be programmed parametrically. Currently I am thinking about programming basic scripted objects like Line, Splin, Faces but also mathematical operations as native scripted FreeCAD objects and linking them with PyFlow. Basically you can think of scripted objects as nodes and the properties as in/out sockets. The main necessary PyFlow nodes for this concept would be the GetPropertyNode and the SetProbertyNode, which operates on the original Tree object properties. What do you think about this?
As you have certainly noticed, I asked the original authors, if s/he would mind to hand over the development as decency demands. There was no reaction up to now (as there was no comments on any other recent issue), so I guess, s/he has written off this piece of software.
So I am very much inclined to start a repository on codeberg.org on its own.
This leaves us to decide on a name:
PyFlow
is not ‘authorized’ by the original owner, I believe we have to find another name.pyflow
on PyPi: https://pypi.org/project/pyflow/It looks like PyFlow
is older than pyflow
, but pyflow
registered first on PyPi. Since we should change the name because of 1., in my opinion, there is no need to negotiate a solution with the author of pyflow
.
Does anyone has a suggestion for the new name, which is still available?
Amazingly trails
is not taken yet: https://pypi.org/project/trails/ …
FreeFlow
NodeFlow
PyFlowic
PyNodes
PyGeoNode
Trails is awesome but it it clashes with a preexisting workbench name in the FreeCAD ecosystem called Trails Workbench
Thanks for the great suggestions! Some are unfortunately taken:
FreeFlow
https://pypi.org/project/freeflow/
NodeFlow
Nothing on PyPi.
PyFlowic
Nothing on PyPi. Also nothing for Flowic
.
PyNodes
https://pypi.org/project/pynodes/ :disappointed:
PyGeoNode
Isn't that too much FreeCAD orientated?
From those I like Flowic
(without Py
best), but …
Trails is awesome but it it clashes with a preexisting workbench name in the FreeCAD ecosystem called Trails Workbench
Ouch! Would that be a problem? Trails
is a standalone program and imported into AnimationFreeCAD (will it ever show up with this name in FreeCAD?) and the Trails Workbench
is, well, a workbench and not a standalone program.
Are there any potential clashes? PyTrail
would also be available, but in my opinion not as good as Trails
(pytrails
is taken).
Thanks for all the sleuthing!
Well Trails is a fork of PyFlow, so there is a possibility of future clashes but you know...if you're really sweet on 'Trails', I say go for it then. :stuck_out_tongue_winking_eye:
I am just amazed, that Trails
is still ‘free’. I now checked the Debian repository for files with that name and – amazingly again – there is no file with that name! (I do not know for Windows or MacOS) If there are no objection, I guess we should go for it then. (Future clashes can never be avoided …) – otherwise I would vote for Flowic
.
Trails sounds great, I'm in!
Good news! The main part of the transfer to Trails is done. I just have to package it and upload it to PyPi and push it to Codeberg.
Maybe now it is a good time to talk about licenses. PyFlow is licensed under Apache 2.0. Personally I would prefer GPL or LGPL, which would be in line with FreeCAD. I believe the Apache license allows it to relicense it.
What do you think? Is this a good or a bad idea?
Since it's an addon that can be installed via the addon manager (and not bundled at install time) GPLv3 is no problem. Here's the FreeCAD take on why they chose LGPLv2 (https://wiki.freecad.org/Licence#Statement_of_the_main_developer).
@sphh oh yea..forgot to mention, excellent news!
Here's the FreeCAD take on why they chose LGPLv2 (https://wiki.freecad.org/Licence#Statement_of_the_main_developer).
That sounds very sensible and would be appropriate to Trails as well: Trails is a standalone application and a library …
oh yea..forgot to mention, excellent news!
oh thanks :blush: It was a bit more work than anticipated, because the code is not the cleanest one I've seen. Anyway, it is now done (but would benefit from some more code clean-up).
I still have a problem packaging it. This was already there in the original code. Maybe someone could help here (I describe it based on the original PyFlow code):
flit
for packaging, so I had to rename pyflow.py
to run.py
.python3 run.py
, where run.py
is located in the project's root directory (at the same level as e.g. README.md
). That works well.pyproject.toml
I can specify the entry point in [project.scripts]
, but since run.py
is in the project's root directory, it is not included in the wheel. So there is no entry point available.run.py
down one level into the PyFlow
directory and change the import statements accordingly, I get the following error, when I call python3 PyFlow/run.py
:
Traceback (most recent call last):
File "./PyFlow/run.py", line 30, in <module>
from app import PyFlow
File "/usr/local/lib/python3.8/dist-packages/shiboken2/files.dir/shibokensupport/__feature__.py", line 142, in _import
return original_import(name, *args, **kwargs)
File "/home/sphh/Software/github/PyFlow/PyFlow/app.py", line 37, in <module>
from PyFlow import GET_PACKAGES, INITIALIZE
File "/usr/local/lib/python3.8/dist-packages/shiboken2/files.dir/shibokensupport/__feature__.py", line 142, in _import
return original_import(name, *args, **kwargs)
ModuleNotFoundError: No module named 'PyFlow'
Any ideas what I can do?
@looooo can you weigh in on this python packaging issue? TIA!
I just pushed all my changes to https://codeberg.org/Trails/Trails.
Please have a look at the CHANGELOG and open issues with your opinion.
I also tried to upload the package to PyPi, but it was rejected (see https://github.com/pypa/pypi-support/issues/2136). Let's keep :crossed_fingers:
@luzpaz, @j8sr0230: I would be glad to make you maintainers of that repository, so that we can share the burden of maintaining it! Maybe packages can be stored there as well? If someone else is interested, please drop me a note (or open an issue)!
@sphh will be happy to help as best as I can (i do wear a lot of different hats :smile:
Here's my codeberg account: https://codeberg.org/luzpaz
@sphh Well, that's great news. I'm happy to help. Here is my brand new Codeberg account: https://codeberg.org/j8sr0230
Maybe it's worth thinking about a fork for PyFlow since it has been abandoned by the original devs https://github.com/wonderworks-software/PyFlow/issues/106 ?