While writing this, I'm just asking myself how Roundcube does handle this: As we can't know which skin our users will be using, we need to activate compose_addressbook in the config for the Classic users. Can't this create a conflict with the Larry users, as they would now have a core function AND a plugin with pretty much the same functionality...?
This is not a problem, as my plugin makes sure it only runs with the classic skin.
I was aware that it runs only with the classic skin, but I'm being curious: How does this all work internally?
I mean, does the code of the plugin get loaded first, then the skin is being checked, and then the code gets unloaded again (if Larry is the active skin)?
If you turn on a plugin in the main config, it gets loaded no matter what. So you decide to load it or not. Early in the loading process of roundcube it checks the list of plugins, and calls the init() function in all plugins. This happens regardless of skin. My plugin checks the user's skin inside the init function, and if it's classic it will not do anything. You can easily see this yourself in the source :)
Normally a plugin with UI elements will have it's own skin directories, where you can load files based on skin. So you can have different images, icons, css, whatever, based on the skin setting.
And what happens if the user is switching back and forth between skins during a session...?
Then after switching the skin, the user will click on compose, and see above.
Cor