Implement some quality-of-life features #102
Conversation
|
I'm generally fine with the PR, though I'm not sure if it's really worth it to replace JBColor? Why can't we simply wrap it in the future situations that you describe? |
The initial implementation wanted to do just that, but one problem is that you can only obtain the separate dark/light color through the api internal methods. There is another way, but the whole thing is not trivial, especially because the returned color changes depending on the active theme. Sure, we could use the internal api, but this can lead to things breaking unnecessarily in the future or maybe not, depends on the intellij developers. Another concern was, like mentioned, that I am planning to extend this type with more data in the future, like for example:
The biggest reason for making a dedicated type was that migrating the contig is a pain, and I don't want to have tons of legacy code for old settings options. Deleting the config is not trivial either without our current structure. By having a dedicated class, future config changes won't necessarily result in a class change. To be honest the arguments are all kinda weak, especially with me not having the old code anymore. The lines of code aren't much different between the two implementations and not using the internal apis seemed like a nice plus. So I would much rather keep that class in, it makes future changes a bit less annoying. |
|
Ok, I'm fine with it if you think it's better this way |
|
Color changes
The old code did not handle the light and dark theme properly, and the default highlighter color was unreadable in the light theme:
This has been changed to a much more pleasant color:
Similarly for the dark theme, the color has been adjusted to be more pleasant.
This is the before:
and this is what it was changed to
Internally an extra class called
ThemeColorhas been introduced. Currently it does the same things thatJBColordoes, but in the future, it will be changed to accommodate new features (like a nested annotation having a different highlighter color or buttons having different highlighter colors). This would not be so easy with aJBColor.The old code did not support changing the transparency of the highlighter color, this is now supported.
Regarding migrations
With the types changed, loading an old config, would have crashed the plugin. The code has been extended to migrate old values to the new format. Additionally, it will migrate the old default highlighter color to the new one. The other colors are not migrated, because they haven't been changed.
Automatically selects the right exercise, based on the selected config
This PR will close #92.
When intelligrade was started, it loaded the config that had been selected previously and defaulted to the first exercise in the list.
Now one can select the config, and it will automatically select the first exercise that can be used with the config.
Save will cleanup the assessment
The code will now remove the local files and close the assessment after the save was pressed in this menu:
This removes the need to press the save button and then the close button.
Automatically open a file when there is no main method present
This PR will close #88.
The code does nothing fancy; it will select the first class that it encounters.
When a line is selected via double-click it highlights the following line too.
This PR will close #93. Turns out this was a misinterpretation of the offset. The end offset is exclusive in the text range. That resulted in the wrong selection when double-clicking a line.
In addition to that, I fixed some potential threading problems (according to the javadoc, some methods must be called in a read action).
Automatically set inspection profile
With this PR an inspection profile is automatically set in the cloned submission. This PR closes #91.
Add support for buttons without visible highlighting
It will now look like this for certain annotations:
Note that there is a pen on the left side, but the line is not highlighted. This is intentional.