Why Does Autoswitch Not Include An In Game Gui For Editing Configs%3F

It's so simple, yet provides a large amount of benefit for those that like this type of thing. It is a mod that I love, and I wish it was comparable to the original. If I were to take a break from modding and come back a couple of years later, I would want such a mod to exist, hence why this is the first mod I made because I missed having it on recent Minecraft versions. I want this mod to last forever, and there are very few things that can break it. Every time AutoSwitch leaves the land of Fabric API to touch Minecraft is another point of failure, and should be avoided where possible. If I were to no longer be around to update the mod, I still wish for it to continue functioning. This leads to the first and foremost design requirement: any breakage between Minecraft versions - barring actual Minecraft changes - is inexcusable. Hence why I chose to use the config library I have - it's a basic Java library, the only way for it to break would be for Java to break it, and that is unlikely to occur. For all intents and purposes, the config system will never need to be touched again. This clearly aligns with the the mod I want to make.

A GUI adds many points of failure, and is not a critical feature - why would it be? It is not expected that frequent edits to the config will be done once any user tweaks are made, if there are any since it tries to provide sensible defaults. That's not to say I am against users configuring it (the config files exist for a reason), I simply don't believe it would be done so frequently that special GUI attention is needed; however, I have since changed my mind and will be adding one, though it still will not be considered a critical feature. A GUI is extremely user-facing, which means that if it is to be added it must meet two requirements: 1) it must not break AutoSwitch or ModMenu if the config screen breaks, and 2) it must be done properly. AutoSwitch's config system is more than a series of true/false statements, so it is difficult to compress it down to a series of buttons and sliders that Minecraft's GUI usually relies on. That means a long list of text boxes. I find editing text boxes in Minecraft's GUI to be unpleasant, and a lesser experience to a normal text editor where you even have spell check to help assist you. AutoSwitch is also smart and will reload the config file once you save it. There is no restarting Minecraft to edit the config and test the changes made. You may disagree with how I feel about such a GUI, but I have yet to work with one that I preferred over a normal text file. If even the person who made the system doesn't want to use it, then it is a bad system.

My ideal for what the GUI would be a series of text boxes (since there's very little way around that), but with suggestions/tab-complete similar to what you find with Minecraft's commands, allowing for easy input validation and immediate feedback to the user. Along with a search for what material a block/entity falls under so users have an easier time knowing what values to change, it would be what I consider the proper way to do a config GUI for AutoSwitch. Some rendering of the item/block/entity that is being targeted would be an added bonus. There's also the issue of the narrator for the input fields. Now that Minecraft has accessibility features, they should be used. For most things this will be fine, but for the input it might get messy. These are things that must be done for a proper AutoSwitch config GUI, yet I lack the technical skill to do this. So I'm not going to half-ass it and provide a lesser experience. Some may find the naive implementation to be better than not having a GUI at all as they won't have to leave the Minecraft window to do make changes, but to be frank: not leaving the game window is not good enough, I have a standard for this that I will not lower; it shall be done properly or not at all.

I do not use ModMenu as I find no utility in such a mod, though I recognize why some would. This means I would not be aware of any issues that arose from integrating a config GUI with it unless a user reported it. It's yet another library I have to find and make sure is up to date. This increases the maintenance burden as I have to track not only ModMenu changes but Minecraft's GUI changes. That is not something I find desirable unless I can make a system I am happy with.

Using any Minecraft-specific config library that by chance has a config GUI inbuilt is not an option, due to the fragility it introduces, nor will I make users download a separate mod just so they have configs. Packaging the mod into mine is also not an option, again for the fragility it would introduce. The longevity of AutoSwitch is my top priority, any dependency I cannot rely on is a potential failure point. I'm not saying they aren't good, or that the people behind them aren't dedicated to them, they simply don't comply with the design requirements I have for AutoSwitch. A third party library would also end up just being that series of text boxes I do not want. A config library called Fiber is being worked on to be merged into Fabric API, and the creator of ModMenu has stated he wishes to add config screen support for it. Regardless of what config library will make it into Fabric API, I am willing to try it out. Even though it won't have any of the benefits I outlined earlier, I am willing to ignore them if it's a Fabric API config library since I won't be making the screen, nor maintaining it, some system will. When such a library is closer to being ready to use, I will evaluate it and possibly switch; however, there are a few requirements I have for it: 1) allow reload from file, which my current config library does, 2) be easy to use on my end - I'm not redesigning my config system from the ground up just for it, 3) have config screen GUI support in some manner, and 4) its config file format must be easily human editable with the common default text editors on systems - be that a console, Notepad, or TextPad. This last one some might take issue with. I simply don't want to force users to install something else in order to easily edit their config. Does it rule out several config formats? Yes, but if the benefits outweigh the loss, I can compromise on the fourth requirement. I do care about user experience, and the naive config GUI is a downgrade as far as I have experienced. Are there other config APIs that have GUI support? Yes, but none of them are valid candidates for AutoSwitch at this time.

Will I continue poking at the proper solution? Yes, but it is not a priority. I do not understand rendering, and even this compromise solution was a pain to make, so the chances of me making anything passable are slim. PRs are welcome. Once such a system is introduced, it would become critical, and thus be maintained to the best of my ability: I'm not going to remove functionality from AutoSwitch once it has been introduced without a valid replacement. It would still be a secondary feature, meaning if I cannot fix it it gets nuked or preferably replaced.