Currently it just uses the InternalName, both for the actual log output and the dropdown to the select the plugin.
My use case would be for plugins that have changed their name to something entirely different. It's confusing for users when you ask for (filtered) logs.
Not sure what the best approach for this should be though. Could have a DisplayName field in LocalPlugin and DalamudPluginInterface where the former reads from the latter, and if it doesn't exist, default to InternalName to keep existing behaviour. Then PluginLog/ConsoleWindow can just use the DisplayName property entirely and swap off of InternalName.
This would technically allow one to disguise as another plugin in the logs, which I assume is probably the first reaction to this idea. Display could be appended with #InternalName or something but then that just clogs the log (imo), particularly for plugins with long names or where ones aren't using DisplayName at all (which will probably be 99% of plugins)
Currently it just uses the InternalName, both for the actual log output and the dropdown to the select the plugin.
My use case would be for plugins that have changed their name to something entirely different. It's confusing for users when you ask for (filtered) logs.
Not sure what the best approach for this should be though. Could have a DisplayName field in
LocalPluginandDalamudPluginInterfacewhere the former reads from the latter, and if it doesn't exist, default to InternalName to keep existing behaviour. Then PluginLog/ConsoleWindow can just use the DisplayName property entirely and swap off of InternalName.This would technically allow one to disguise as another plugin in the logs, which I assume is probably the first reaction to this idea. Display could be appended with
#InternalNameor something but then that just clogs the log (imo), particularly for plugins with long names or where ones aren't using DisplayName at all (which will probably be 99% of plugins)