Reply to thread

Message: <blockquote data-quote="tomtom21000" data-source="post: 24422" data-attributes="member: 10287">I think it is an excellent idea.For now, most plugins are delivered in the basic package. With dsl you do not really care if mp is a 30 mb package or 40 mb.this is the easiest way to ensure that the plugin works with new releases and with all skins.but the number of plugins grows.the new user might not even realize about all the suberb plugins, just because they are not activated in the standard setup. DonÂ´t think you are asked for which plugins you would like to activate.----------------------------------------------------So, some things for your design:1)  how can you assure that only plugins, working with the release version of the user can be installed?options: # plugin is not updated/compiled against the latest version and does not work with latest version# as before, but it still works # plugin is for latest mp version, but user still uses an older versiona version number had to cover all options2) how can you assure, that the plugin supports all standard skins?2a) how can you assure, that a plugin can be used with a skin not in the standard package - this is a general potential problem3) how could you avoid, that the strings.xml is overwritten. Imagin user installs plugin A and plugin B. With the strings.xml that comes with plugin B he will loose the strings of plugin A. How would you solve this for the available foreign languages?4) If you manage all this, I think about a plugin description in MP + screenshot + featurelist + install yes/no would be absolutely cool.I know 1)-4) problems already exist the way plugins are handled now. But I think it is harder to code this than a forum solution.mmmh. sounds a bit negative, but it is not ment this way. I really like your idea.tomtom</blockquote>

Verification