Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add customisable message colors #24

Closed
wants to merge 1 commit into from

Conversation

lokka30
Copy link
Contributor

@lokka30 lokka30 commented Jun 4, 2022

This PR is only useful as a temporary aid to customising messages. This PR is likely to be rejected since it isn't a permanent solution, I am just submitting this in case you prefer it.

This PR allows the customisation of message colors, however, this PR does not allow customisation of the content of the messages.

This is likely incompatible with #9 and does not fully solve #20.

@mfnalex
Copy link
Owner

mfnalex commented Jun 4, 2022

This PR is likely to be rejected

Yeah, unfortunately you're right :P But I guess I'll just make it configurable now. My idea is the following:

The lib itself contains a file updatechecker-messages-default.yml that contains the messages. Plugin devs can simply include their own file called updatechecker-messages.yml and if that's present, it will use those messages instead.

The plugin name, version etc can then be simply controlled with placeholders like {plugin}, {version}, {downloadFree}, {downloadPaid}, etc etc

@lokka30
Copy link
Contributor Author

lokka30 commented Jun 5, 2022

This PR is likely to be rejected

Yeah, unfortunately you're right :P But I guess I'll just make it configurable now. My idea is the following:

The lib itself contains a file updatechecker-messages-default.yml that contains the messages. Plugin devs can simply include their own file called updatechecker-messages.yml and if that's present, it will use those messages instead.

The plugin name, version etc can then be simply controlled with placeholders like {plugin}, {version}, {downloadFree}, {downloadPaid}, etc etc

No worries 😁
Wouldn't this be better configured through an enum of some sorts, similar to the one I used in this PR? No YML syntax or parsing to deal with.

@mfnalex
Copy link
Owner

mfnalex commented Jun 6, 2022

An enum? I don't really understand what you mean, like - how would one be able to pass the translated message using an enum? 🐺

@lokka30
Copy link
Contributor Author

lokka30 commented Jun 6, 2022

An enum? I don't really understand what you mean, like - how would one be able to pass the translated message using an enum? 🐺

An enum containing a constant for each message sent by S-UC. The enum has a method getDefaultContent, setContent, getContent - similar to how I did this in the commit for custom message colors. :)

Haven't given this much thought so let me know if it's a terrible idea. 😁

@lokka30 lokka30 closed this Jun 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants