[patch] change color when failed

[samwaseda]

Closes #92

from pyiron_workflow import Workflow, function_node

def add(x, y):
    output = x + y
    return output

def mul(x, y=2):
    raise ValueError
    output = x * y
    return output

wf = Workflow("draw")
wf.Add = function_node(add, x=1, y=2)
wf.Mul = function_node(mul, x=wf.Add)

wf.run()

Btw. does it have a particular reason that node has a color?

[github-actions]

👈 Launch a binder notebook on branch pyiron/pyiron_workflow/change_color_for_failed

[codacy-production]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
✅ +0.00% (target: -1.00%)	✅ 92.86%

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (89ddd30)	3243	2960	91.27%
Head commit (a07ef28)	3256 (+13)	2972 (+12)	91.28% (+0.00%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#462)	14	13	92.86%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

See your quality gate settings    Change summary preferences

_{Codacy stopped sending the deprecated coverage status on June 5th, 2024. Learn more}

[coveralls]

Pull Request Test Coverage Report for Build 10954304912

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 13 unchanged lines in 1 file lost coverage.
• Overall coverage increased (+0.004%) to 91.278%

---

Files with Coverage Reduction	New Missed Lines	%
draw.py	13	92.56%

Totals
Change from base Build 10943294792:	0.004%
Covered Lines:	2972
Relevant Lines:	3256

---

💛 - Coveralls

[liamhuber]

I really liked how for the present/missing data you did just the outline -- could we port that to doing the outline in red here and leaving the fill the usual colour?

[liamhuber]

Btw. does it have a particular reason that node has a color?

The end result should be that nodes of different types should have different colours (macros, function nodes, etc.) to improve visual clarity.

From a purity perspective, this should absolutely not be a property of the node -- the draw method (or pyiron-xyflow) should handle it. But from a practical implementation perspective, that would mean that the drawer has its own colour map and is constantly doing isinstance checks to see which colour should be used -- grabbing node.color is much faster. I'm totally ok either route -- pure or practical, but practical is what there is right now.

[samwaseda]

From a purity perspective, this should absolutely not be a property of the node -- the draw method (or pyiron-xyflow) should handle it. But from a practical implementation perspective, that would mean that the drawer has its own colour map and is constantly doing isinstance checks to see which colour should be used -- grabbing node.color is much faster. I'm totally ok either route -- pure or practical, but practical is what there is right now.

ok it also sounds to me like we should have a possibility to export levels, and it sounds to me like it's something that pyiron_workflow should be able to do. I actually kinda have the feeling that the drawing module should also be better separated. I'll look into it at some point.

[samwaseda]

I really liked how for the present/missing data you did just the outline -- could we port that to doing the outline in red here and leaving the fill the usual colour?

I updated it and also added an example in the top comment.

[liamhuber]

we should have a possibility to export levels

Can you clarify this? IMO it's not as clear as "levels" of node -- that makes sense for function vs macro, but not so much for function vs transformer, or for loop vs macro.

[liamhuber]

I actually kinda have the feeling that the drawing module should also be better separated.

I see what you're saying, but I will disagree; I think it's nice to have some sort of built-in way of visualizing the nodes that comes with the library. It's a common enough operation that I'm disinclined to force people to separately install a second tool to get it done.