Custom Entry Types

Simple Config provides a few ways to create custom entry types.

• Composite Entry Types
• Custom Serializable Entry
• Subclass AbstractConfigEntry

Composite Entry Types

With Simple Config you can combine entry types within lists/sets/maps/pairs/triples and structured groups of entries mapping to Java Beans/Kotlin Data Classes. These Entry Types are described in the Advanced Entry Types section.

Custom Serializable Entry

The entry factory method supports specifying a custom ConfigEntrySerializer implementation. If you provide a way to deserialize (and serialize, if toString is not suitable), you'll be able to use any type in config entries.

In addition, you can implement your own TextFormatter, if you wish to provide some degree of syntax highlighting/writing assistance within your entry's text fields.

You may take inspiration from or use some of Simple Config's built-in TextFormatter implementations:

• NumberTextFormatter
• ColorTextFormatter
• ResourceLocationTextFormatter

You may also create a CharacterBasedTextFormatter, either with a character map of styles, or implementing CharacterFormatter.

---

For more complex highlighting, Simple Config uses ANTLR4 grammars, wrapped with the LanguageHighlighter interface. These formatters provide user-configurable theming in JSON format. If you really want to implement your own, you may probably prefer to do it as a pull request to this project, as setting up ANTLR4 to behave with Gradle is a highly painstaking process.

The places where Simple Config defines these syntax highlighters are:

• The grammar source dir, which contains ANTLR4 lexer and parser definitions
• The simpleconfig-highlight resource directory, which contains default highlighting themes for the languages
• The mod constructor for Simple Config, where these two are pieced together and registered to the LanguageManager

All Gradle configuration for ANTLR4 used by Simple Config is contained and documented in its simple-config.antlr-conventions.gradle.kts script, which may be useful if you want to setup a similar pipeline in your own project.

Subclass AbstractConfigEntry

If none of the previous options satisfy you, you could of course subclass AbstractConfigEntry directly. This is a complex task, as you may probably want to also subclass TooltipListEntry to provide your own GUI widget.

Warning This $\color{red}{\textsf{requires compiling against the mod}}$, rather than the API, which is $\color{red}{\textsf{highly likely to break ABI}}$ whenever Simple Config releases any fixes to the UI.

If you're still willing to go through that, it's recommended you instead submit a pull request with your suggested entry type, so it becomes a part of the Simple Config API. This option is of course, limited to general data types, that do not require your mod classes. Consider if you can generalize your entry type idea to general types, which you could use for your specific problem, if that's the case.

If you're really still willing to do this, you may use some inspiration from the source for the built-in entry types:

• The endorh.simpleconfig.core.entry package, which contains the implementation for most built-in entries, and their builders
• The endorh.simpleconfig.api.entry package, which contains the parallel builder interface hierarchy to the implementations
• The endorh.simpleconfig.ui.gui.entries package, which contains the implementation of the parallel GUI entry classes hierarchy
• The endorh.simpleconfig.ui.impl.builders package, which contains the (yes, yet again) parallel builder hierarchy for the GUI classes
• The endorh.simpleconfig.core package, which contains a few entries' implementations (like EntryListEntry or EntryMapEntry), not within the entry subpackage, as well as the core classes of the Simple Config mod (yes, it's a mess, I know).