Closed whelena closed 9 months ago
See temporary fix in the associated development branch
It's unclear from the documentation that the node.col parameter is meant to specify a single colour for all nodes and for each node to have a different colour,
Should we leave node.col
as another parameter (maybe renamed to default.node.col
?), or should we just move this to the input dataframe for consistency? Users could still easily set the colour for all nodes like $tree$node.col <- 'red';
so I don't think we gain much by including the parameter as well (especially with the lost clarity).
I think the way you did it in the pull request is ok. We'll make sure documentation is clear that everything in the dataframe is prioritized and default.node.col
only takes a character input (not list of colours).
Sounds good. We can document and also include a warning if a user passes in multiple values. Something like Multiple values passed to "default.node.col". To set multiple node colours, add a "node.col" column to "tree.df".
Then, just use the first colour passed in, ignoring the others.
Yes, exactly what I was thinking
It's unclear from the documentation that the
node.col
parameter is meant to specify a single colour for all nodes and for each node to have a different colour, it should be passed as a column in thetree
dataframe. Additionally, there is acolour.scheme
parameter that contains a default but might contribute to this issue.Passing the colours as a column in the
tree
dataframe gives the default grey nodes. This might be due to an inconsistency in column names 'colour' and 'color'. Theprep.tree
function (line 73) generates acolor
column containing the SRCgrobcolour.scheme
parameter. Then inmake.clone.tree.grobs
line 64, it checks for acolour
column, which defaults to thenode.col
parameter.Passing the colours using
node.col
results in a coloured tree, but with the wrong colours (shown below). Colours should match the heatmap.