Make pgplot color indices static #808
Conversation
This has the following benefits: - Remove effectively duplicated code, since pgplot supports the same thing. - Support more locations for rgb.txt, as given by the pgplot library (e.g. loading from a system default folder, if pgplot has been installed system wide)
The color indices were written to every time a new device was opened. While these indices should be the same time set_device_colors is called, there is not really a reason to make these not static. The colors that were set by name also didn't have an associated variable, so the only way to refer to them was by specifying the actual values. Since this removes a bunch of variables from the star_pgstar, pgstar_support and pgbinary_support, this is a breaking change.
|
This is great! |
Naive question here. Does this mean the colors in pgstar (say in the abundance panel) will not change on the fly? |
|
The way pgplot works is that in order to draw something in a certain color, you have to
At the initialization of pgplot, MESA sets up a bunch of color indices. This happens whenever a pgplot device is opened, so also when a plot is saved as png for example. The values of those indices where computed dynamically, and written to bunch of global variables ( When one of the panels selects a color, it does so by taking one of these global variables/parameters and pass them to |
|
Looks good! @VincentVanlaer ready to merge? |
This is refactor of the pgstar colors that partially originates from the build system branch.
The first two commits (those effectively come from the build system branch) are just a cleanup of the color setting code. I replaced some custom code to map color names to rgb values using a file provided by pgplot with an equivalent function in pgplot itself. There was
The next two commits then get rid of the dynamic mapping of color indices, and just make the list static, since that is what ends up happening in practice anyway. I have also lifted the actual named colors from the pgplot provided rgb.txt.
I would consider the first set of changes more or less of a bug fix, so I would like to see those go in. The second set is a refactor I would do, but not something I would consider necessary.