UI colors
Description
This will create a new file color-theme.txt that allows users to specify their own color scheme, and also allows LEGUP to provide a color blind scheme. This should also be used by developers going forward to use one color theme without requiring color blind checks in every puzzle.
To use the colors in a puzzle and/or UI elements, use ColorPreferences.UIColor.<YOUR_COLOR>.
You can add as many colors as you want for your puzzle, or use colors that are already defined such as UIColor.CORRECT.
When adding the color to the UIColor enum, make sure to add it in the color theme txt files under the resources folder. It should have the same name as the enum entry, except make it lowercase and replace _ with -. The format is key: value, where value is a hex color, an RGB color in the form of an int, or a color defined in java.awt.Color or in edu.rpi.legup.ui.lookandfeel.materialdesign.MaterialColors. This value is case sensitive if it is not a hex color or RGB int.
This allows the correct color to be defined in a txt file and be used everywhere, so if someone is colorblind they can use a colorblind color theme and the same correct color will be used everywhere. To actually use the colors in your code, you can use the UIColor.get() method which returns a java.awt.Color which can be used as a normal color.
The color theme file can also be changed in the preferences when running the LEGUP app.
Closes #426
Type of change
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [X] Enhancement (improvement to an already existing feature)
- [X] Breaking change (fix or feature that would cause existing functionality to not work as expected)
How Has This Been Tested?
Checklist:
- [ ] I have performed a self-review of my code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation (if applicable)
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] New and existing unit tests pass locally with my changes
I did some work on the LegupPreferences class because I noticed it was kind of annoying to work with. Before you had to do something like LegupPreferences.getUserPref(LegupPreferences.<SOMETHING>).equals(Boolean.asString("false));
Now, you can either do LegupPreferences.<preference>(), or LegupPreferences.LegupPreference.<SOMETHING>.asBoolean().
I also made preferences use an enum instead of strings for the keys, which makes other methods more convenient.
I also noticed in some places that instead of getting the preference value, the string of the preference was being used instead for example WORK_DIRECTORY instead of getUserPref(WORK_DIRECTORY). This commit should prevent that from happening in the future because the preference keys are now enums, so that code won't compile.
I'm working on the suggested changes so I marked this PR as a draft.
I added a checkbox for using a custom theme, now I just have to figure out how to make the button sizes and shapes the same as FlatLaf.
Now the shapes of the buttons don't change because I removed the LegupLookAndFeel class which wasn't being used, so now if the option to use custom colors is checked, it will use the colors in the specified color file and replace them in the FlatLaf theme.
I still am getting issues with dark mode. I have dark mode toggled to be on when I open LEGUP and it's opening it in light mode. Additionally, when I try to toggle back to dark mode, it shows up like below:
However, dark mode does work now in the preferences menu after I re-toggle it to be on:
Also, after working with this, I think it would be best to put dark mode, the color-blindness options, and the custom color file under its own section in preferences. Perhaps it would also be best to only show the custom color file if you select a checkbox in order to not confuse users. That way, if someone wants to put a custom color file, they have to check off "Custom Color File", which will untoggle any color-blind mode that is on and then read in colors from the file.
Is the image with the latest commit? It doesn't show the checkbox for the custom color. I agree with hiding the color theme file option when the checkbox isn't checked, so I will implement that.
I still am getting issues with dark mode. I have dark mode toggled to be on when I open LEGUP and it's opening it in light mode. Additionally, when I try to toggle back to dark mode, it shows up like below:
However, dark mode does work now in the preferences menu after I re-toggle it to be on:
Also, after working with this, I think it would be best to put dark mode, the color-blindness options, and the custom color file under its own section in preferences. Perhaps it would also be best to only show the custom color file if you select a checkbox in order to not confuse users. That way, if someone wants to put a custom color file, they have to check off "Custom Color File", which will untoggle any color-blind mode that is on and then read in colors from the file.
Is the image with the latest commit? It doesn't show the checkbox for the custom color. I agree with hiding the color theme file option when the checkbox isn't checked, so I will implement that.
I see now I didn't have the latest commits pulled. The dark mode checkbox works properly now.
I think I found another problem. It seems that having dark mode checked off versus not having it checked off messes with the custom color theme. See the images below:
Notice how when dark mode is checked off that the background of some of the boxes is dark. I assume that this isn't the intentional behavior? Perhaps when a custom file is given, we should uncheck dark mode?
I can do that, it might be okay to leave that though so that a color theme file can just override the colors it wants to, so if the user still wants dark mode for everything else they can keep it. Right now the custom color theme file is just light mode colors.
There seems to be a bug with saving within the Puzzle Creator, which appears to be caused by the merge conflicts on ProofEditorPanel.java and PuzzleEditorPanel.java. When attempting to save a newly created puzzle, the process will fail silently and fail to save. Unable to merge until fixed
There seems to be a bug with saving within the Puzzle Creator, which appears to be caused by the merge conflicts on
ProofEditorPanel.javaandPuzzleEditorPanel.java. When attempting to save a newly created puzzle, the process will fail silently and fail to save. Unable to merge until fixed
This should be fixed now.

