Open ryankhart opened 2 years ago
Just musing on this, but we should extract all the relevant logic to a service when we implement this. Currently, the preset logic is simple enough that I have it alongside the config UI, but I think this feature would push it over the threshold of having too much business logic where it should be. I'm thinking some sort of ChatPresetManager that contains any relevant services, methods, etc.
Interesting. I'll probably need to tinker around and Google search around before I fully comprehend what you're getting at, but I'll reread your comment after I've had my chance to tinker and conduct in-game tests.
Now that I've come to think of it, that actually does make sense to me. In thinking about all the new logic involved in this, it would be helpful to have a separate class to manage this and not just a separate few methods.
That was some helpful feedback.
I want to be able to use Dalamud commands for each EnabledChatTypesPreset created by the user.
I have an idea for how this could be useful. I wouldn't type out these commands in the chat GUI, but I would use these commands in various macros to automate a few things before switching from social contexts to solo contexts. It would also help controller/gamepad users map a macro like this to their cross-hotbar to be able to switch between presets from the controller.
One key obstacle in implementing this would be coming up with unique names for the commands. As it is now, I don't think that the plugin checks for duplicate names for presets, so it would first be a good idea to enforce that every preset has a unique name.
Next, we'd want to determine what happens if someone had previously already named two presets the same (unlikely but possible). I'd argue that we should just have it create commands for the first instance of a duplicate name and ignore all other duplicates rather than feeding them all, duplicates included, into a loop to create commands for all of them. I don't know if that would cause a bug now or in the future for Dalamud creating duplicate commands, so it's best to filter for duplicates both on the user's end for new presets as well as for the command generation process.
Another alternative I just thought of is why don't we just put another field in the preset settings window for users to set their own unique command text. That way they can have longer, more descriptive preset names, while having a short, concise command to type. I'm not so keen on this idea though since it just makes the UI more complicated for the user and I don't anticipate users manually typing a command to change presets. But I'm open to feedback from anyone.