Germany
Hi all,
I would like to share some thoughts on plugins and the necessary skin support. I have seen a situation quite often when a plugin that I want to use is not supported by my favourite skin, and I have to switch back to some other skin to be able to execute that plugin.
Sometimes, I notice that plugin developers deliver some xml files to support a certain skin, or some skin files are installed along with the plugin. In this case, when there is a certain skin support offered by the plugin, there is need for user interaction or the skin files are deployed at installation time to some predefined folders, which not necessarily have to match the preferred skin.
The result is the same in either way: you might want to drop the skin or the plugin.
Now my idea is this, there should also be a way for the plugin to deliver skin support. In detail:
+ the necessary XML files can be stored in the plugin DLL as a string resource
+ missing XML files can be deployed at load time
+ by using naming conventions for the resources, XML files can be deployed according to the current skin and in the correct folder
+ there is a possibility to deploy some "default" skin when the current skin is not explicitly supported (predefined screen resolutions, or perhaps dynamically scaled)
I see a possible benefit here, because flexibility is increased and the use of new skins and plugins could be encouraged.
Kind regards,
splatterpop
I would like to share some thoughts on plugins and the necessary skin support. I have seen a situation quite often when a plugin that I want to use is not supported by my favourite skin, and I have to switch back to some other skin to be able to execute that plugin.
Sometimes, I notice that plugin developers deliver some xml files to support a certain skin, or some skin files are installed along with the plugin. In this case, when there is a certain skin support offered by the plugin, there is need for user interaction or the skin files are deployed at installation time to some predefined folders, which not necessarily have to match the preferred skin.
The result is the same in either way: you might want to drop the skin or the plugin.
Now my idea is this, there should also be a way for the plugin to deliver skin support. In detail:
+ the necessary XML files can be stored in the plugin DLL as a string resource
+ missing XML files can be deployed at load time
+ by using naming conventions for the resources, XML files can be deployed according to the current skin and in the correct folder
+ there is a possibility to deploy some "default" skin when the current skin is not explicitly supported (predefined screen resolutions, or perhaps dynamically scaled)
I see a possible benefit here, because flexibility is increased and the use of new skins and plugins could be encouraged.
Kind regards,
splatterpop