Hi Didier,
I use both FielDHub and desplot a lot, and I recently joined desplot as a co-maintainer, so I can now add functionality there directly. That puts me in a good spot to smooth out the boundary between the two packages, and I'd value your input. Let me start with one concrete example and then open up a broader question.
A concrete example: check highlighting in the augmented layout
When plotting an augmented RCBD, the checks are shown in bold red and the test lines in gray. This is currently done with a manual ggplot2::geom_text() overlay placed on top of a desplot plot whose own text has been switched off (text = "", cex = 0):
Interestingly, elsewhere in the same file the text color is set the "native" desplot way, via the col argument - e.g. the un-replicated diagonal layout (col = CHECKS, L19-L33).
Looking at the rendered augmented plot (below), the color alone already separates checks from test lines - the extra bold looks redundant. Meanwhile the overlay approach costs ~40 extra lines, duplicates the coordinate logic (as.numeric(COLUMN/ROW)), and leaves a slightly misleading col = BLOCK # bg by block in the call (L157) that actually has no effect, because the text is disabled there.
Question 1: Would it simplify things to drop the overlay here and reproduce the two text colors with desplot's existing col + col.text arguments, exactly like the diagonal layout already does?
Question 2: Or is the bold actually something you want to keep? If the bold matters, that's a nice excuse for a small desplot feature: I could add a bold = argument to desplot that takes a two-level factor (just like col does for color), so some cells render bold and others don't.
Broader: a desplot <-> FielDHub wishlist
This example makes me suspect there may be more of these. Since FielDHub uses desplot for its field-plot output, you've probably hit other desplot limitations or wishes along the way - places where you had to work around something, or where a small desplot feature would have let that part of FielDHub do more. I'd genuinely like to hear them: I'm happy to add functionality to desplot where it helps FielDHub.
One thing I've wished for myself:
- More control from
... |> plot() in FielDHub: I've often wished I could pass my own fill and/or text colors (and title, cex, ...) through plot() instead of the hard-coded defaults. Part of that is a FielDHub-side API question, but it ties directly into what desplot exposes.
No urgency on any of this - I just wanted to open the conversation while I have a foot in both packages, and I'm glad to do the implementation work.
Best,
Paul
Hi Didier,
I use both FielDHub and desplot a lot, and I recently joined desplot as a co-maintainer, so I can now add functionality there directly. That puts me in a good spot to smooth out the boundary between the two packages, and I'd value your input. Let me start with one concrete example and then open up a broader question.
A concrete example: check highlighting in the augmented layout
When plotting an augmented RCBD, the checks are shown in bold red and the test lines in gray. This is currently done with a manual
ggplot2::geom_text()overlay placed on top of a desplot plot whose own text has been switched off (text = "",cex = 0):utils_plot_diagonal_arrangement.R#L153-L193fontface = "bold"at L191Interestingly, elsewhere in the same file the text color is set the "native" desplot way, via the
colargument - e.g. the un-replicated diagonal layout (col = CHECKS, L19-L33).Looking at the rendered augmented plot (below), the color alone already separates checks from test lines - the extra bold looks redundant. Meanwhile the overlay approach costs ~40 extra lines, duplicates the coordinate logic (
as.numeric(COLUMN/ROW)), and leaves a slightly misleadingcol = BLOCK # bg by blockin the call (L157) that actually has no effect, because the text is disabled there.Question 1: Would it simplify things to drop the overlay here and reproduce the two text colors with desplot's existing
col+col.textarguments, exactly like the diagonal layout already does?Question 2: Or is the bold actually something you want to keep? If the bold matters, that's a nice excuse for a small desplot feature: I could add a
bold =argument to desplot that takes a two-level factor (just likecoldoes for color), so some cells render bold and others don't.Broader: a desplot <-> FielDHub wishlist
This example makes me suspect there may be more of these. Since FielDHub uses desplot for its field-plot output, you've probably hit other desplot limitations or wishes along the way - places where you had to work around something, or where a small desplot feature would have let that part of FielDHub do more. I'd genuinely like to hear them: I'm happy to add functionality to desplot where it helps FielDHub.
One thing I've wished for myself:
... |> plot()in FielDHub: I've often wished I could pass my own fill and/or text colors (and title, cex, ...) throughplot()instead of the hard-coded defaults. Part of that is a FielDHub-side API question, but it ties directly into what desplot exposes.No urgency on any of this - I just wanted to open the conversation while I have a foot in both packages, and I'm glad to do the implementation work.
Best,
Paul