[WIP] Add specialized MCP color support #459
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Remove obsolete hardcoded configuration
stephan-gh
reviewed
Oct 1, 2018
| import com.siyeh.ig.InspectionGadgetsFix | ||
| import org.jetbrains.annotations.Nls | ||
|
|
||
| class ColorComponentOutOfRangeInspection : BaseInspection() { |
There was a problem hiding this comment.
Can we avoid introducing new inspections built on BaseInspection? In my opinion that class is pretty much obsolete and most things can be implemented with one of IntelliJ's base classes (here: AbstractBaseJavaLocalInspectionTool) in a nicer way.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds support for various methods/functions in MCP code bases that take colors as parameters. Currently supported are hex color codes (encoded as integers) as well as [0,1] and [0,255] RGB vectors, all of them with and without alpha values.
Furthermore, this adds a basic system for loading configurations based on a project's underlying MC version. Currently, it's hardcoded to the color support, but I'll make it more useful as a general purpose feature. It's also a little "dumb" in that there's no concept of inheritance. Instead, configs for all versions upto the requested one are considered. This will also be addressed.
Part of the motivation behind the configuration is easier customization for the user. By exposing these configs (possibly through some auto-generated GUI), users may add support for their own methods (or those we missed).