New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DM-39294: Refresh directed graph colors #238
Conversation
de05a8d
to
86e6e6c
Compare
Can you please add some motivation for this change to the commit message? |
86e6e6c
to
04f4f6e
Compare
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #238 +/- ##
==========================================
- Coverage 85.71% 85.43% -0.29%
==========================================
Files 47 47
Lines 4200 4215 +15
Branches 722 724 +2
==========================================
+ Hits 3600 3601 +1
- Misses 448 461 +13
- Partials 152 153 +1
☔ View full report in Codecov by Sentry. |
04f4f6e
to
31d67f5
Compare
Added this commit message text:
|
31d67f5
to
5eb8abd
Compare
af388e7
to
b70df01
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, a couple of comments.
python/lsst/ctrl/mpexec/dotTools.py
Outdated
@@ -91,9 +108,10 @@ def _renderQuantumNode( | |||
|
|||
def _renderDSTypeNode(name: str, dimensions: list[str], file: io.TextIOBase) -> None: | |||
"""Render GV node for a dataset type""" | |||
labels = [name] | |||
pointSize = int(_ATTRIBS["defaultNode"].get("fontsize", 12)) + 4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hard-coded values are usually not welcome, could you add "fontsize" attribute to _ATTRIBS["task"]
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There already is a fontsize
attribute being set in defaultNode
, which will be applied to all nodes (including task nodes). The line you've highlighted here is a safety net that will try to get fontsize
from defaultNode
, but, if someone were to remove fontsize
down the line for some reason, it will fall back to a default value of 12.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you're not happy with setting this default here, I can remove the 12
and simply allow the code to fail at some future date if/when someone were to remove the fontsize
attribute from defaultNode
. Perhaps failing then is safer in any case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was mostly thinking about + 4
, but now I see that fontsize
to task attributes also changes size of all labels, while intent here is to change the size of task name only. Maybe a separate "task-name" key can be added to _ATTRIBS to hold that value? Default 12
does not do much here, indeed, may be worth dropping it or defining a separate module-level constant for it instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about I replace this logic entirely with an externally-set _NODELABELPOINTSIZE
attribute, set to 18? It's not just tasks that are impacted, it also impacts dataset type label names too. The intent behind the +4
was that, if the user did change fontsize
, the labels would still be somewhat larger. However, I'm happy to forego that convenience if hardcoding it makes it easier to read/maintain?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 to _NODELABELPOINTSIZE
.
label = r"\n".join(labels) | ||
attrib_dict = dict(_STYLES[style], label=label) | ||
attrib = ", ".join([f'{key}="{val}"' for key, val in attrib_dict.items()]) | ||
label = r"</TD></TR><TR><TD>".join(labels) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not very familiar with how graphviz handles HTML, do you need to escape special HTML characters here (imagine someone adds an ampersand to task name)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the GraphViz docs (https://graphviz.org/doc/info/shapes.html#html), yes, HTML strings will be processed like HTML input. Do we think this will be a problem for us?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm using HTML styling to achieve two things here: custom line-spacing and setting the label font size to be somewhat larger than the remaining body text. I could live without the font resizing, but the line-spacing is an issue (using \n
only allows me integer line spacing, which is limiting).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm OK with HTML, but I think we need to do proper escaping of strings, just in case people start using fancy names. There is a html.escape()
method that should take care of that (but you need some care not to escape actual tags, e.g. <I>
that you pass to _renderNode
.
59a9075
to
a76e6e1
Compare
The current pipeline directed graph nodes use dark gray as their background color. It has been reported that it is difficult to read the black text on the dark gray background. This ticket updates the directed graph color scheme with an aim towards making node text easier to read. In the process of exploring what color schemes would be optimal to satisfy the aim of this ticket, it emerged that making use of the Rubin visual identity colors may be desirable. This will help to make LSST pipeline graphs more instantly recognizable as Rubin-associated products. Colors: https://rubin.canto.com/g/RubinVisualIdentity
a76e6e1
to
610f934
Compare
Thanks @andy-slac. I've added a global |
Checklist
doc/changes