Enabling/Disabling Mala Plugins

[slsimon]

Loadman, I did not see an easy way besides removing the Mala plugin files as to enable or disable a specific plugin.  I think it would be a nice addition, especially for troubleshooting to have an easy way to do this.  If someone has a handful of plugins installed, a plugin update comes out or a new plugin that may need to be tested, I personally would disable all other plugins but the one at hand for testing purposes.  Can this option be added to the plugin tab in Mala or maybe I looked over that option if it is already there ... 

Just a suggestion...  Looking forward to the new releases.  Thanks, Shane

[loadman]

Loadman, I did not see an easy way besides removing the Mala plugin files as to enable or disable a specific plugin.  I think it would be a nice addition, especially for troubleshooting to have an easy way to do this.  If someone has a handful of plugins installed, a plugin update comes out or a new plugin that may need to be tested, I personally would disable all other plugins but the one at hand for testing purposes.  Can this option be added to the plugin tab in Mala or maybe I looked over that option if it is already there ... 

Just a suggestion...  Looking forward to the new releases.  Thanks, Shane

Believe me I thought of that for the last version, as it a cool idea. 

I use that in UncleT's Jukebox.

The reason I did not add that feature is some existing plug-ins would not work or crash as they may not cope with creating and destroying it's own objects. I can elaborate if you don't understand but basically the existing plugins assume they will get a minimum amount of messages. EG MaLa Start, List change, Emu change and MaLa Quit and if the plug-in was enable/disabled after mala starts the results could be unpredictable.

So the issue really is how to make them backward compatible.

One idea I thought is could just make it work for future or updated plugins using a flag I suppose but that does not help you with all the existing ones unless they were all modified by the various authors.

Ideally you need to add this feature from day one.

If I want to disable a plugin I just move the *.mplugin file to a sub folder 

[TheShanMan]

Maybe a middle ground: Allow enabling/disabling, but for plugins that don't support it directly (by implementing an "enable" function), state to the user that it will require a restart of mala. If all plugins support it, then it works without restart.

[loadman]

Maybe a middle ground: Allow enabling/disabling, but for plugins that don't support it directly (by implementing an "enable" function), state to the user that it will require a restart of mala. If all plugins support it, then it works without restart.

hmmm sorta

That would mean that for the old Plug-ins Mala would need to somehow keep track of what Plug-ins are enabled and what are not. If someone changes the plug-in version underneath it it could get in a mess. 

Getting there I think 

I dunno, I feel kinda if you have to quit mala then you might as well just drag and drop the plugin out of the folder.

[TheShanMan]

You have to keep track of it anyway, since you're not enabling or disabling ALL plugins together. And why would updating a disabled plugin present a problem?

I'm not sure I'd ever use the feature personally - I'm just throwing out an idea.

[loadman]

You have to keep track of it anyway, since you're not enabling or disabling ALL plugins together. And why would updating a disabled plugin present a problem?

I'm not sure I'd ever use the feature personally - I'm just throwing out an idea.

No I value your input  and support  

I would probably use this feature a lot as it would be handy.

Yes I would have to keep track of it you are right (sipping my morning Coffee turning my Brain on) I guess as part of mala.ini. The status could be as simple as just matching the file name I guess.

I am just not that excited about having to manage two types of plug-ins but the more I think about this idea it might not be such a pain to implement....

[Space Fractal]

In MultiFE I just save it to a config which plugin with the pluginfile which is enabled and disable. If plugins dosent support it, the disable/enable should first have a effect when you restart Mala, so plugin never have a chance if it got loaded or not. You can notice the user restart Mala is required to take effect.

in Mala.ini example this could do the job:

[plugins]
pluginname=false
pluginname2=true

etc

[loadman]

In MultiFE I just save it to a config which plugin with the pluginfile which is enabled and disable. If plugins dosent support it, the disable/enable should first have a effect when you restart Mala, so plugin never have a chance if it got loaded or not. You can notice the user restart Mala is required to take effect.

in Mala.ini example this could do the job:

[plugins]
pluginname=false
pluginname2=true

etc

Cool 

[Neverending Project]

Just another suggestion here... In a two-step approach, you could allow enabling/disabling plug-ins for future releases of plug-ins, making sure the developers add the necessary support in future updates. Then for existing plug-ins, have Mala warn the user that the current plug-in is not capable of enable/disable - maybe even offer them the choice to move it to a disabled folder for them (maybe requires a restart)?

In case I am not clear, here is what I am picturing... in the plug-ins section, there is a checkbox next to each plug-in. If I click on a supported plug-in, it simply disables it. If I click on an older version (hence not quick enable/disable supported) a dialog pops up telling me that this plug-in can't be disabled unless I restart Mala. If I choose to continue, it moves the plug-in to a disabled plug-ins folder, and on restart I see the plug-in without a check next to it.

I feel kinda if you have to quit mala then you might as well just drag and drop the plugin out of the folder.

For me, it seems if the software can handle it's own file/folder structure that is less work I need to do, and less that I need to know. Maybe akin to a program editing it's own configuration file vs. my needing to manually change a text file.

Just my opinion. Sorry if I'm not very coherent. I'm off to get my second cup now...

[loadman]

Just another suggestion here... In a two-step approach, you could allow enabling/disabling plug-ins for future releases of plug-ins, making sure the developers add the necessary support in future updates. Then for existing plug-ins, have Mala warn the user that the current plug-in is not capable of enable/disable - maybe even offer them the choice to move it to a disabled folder for them (maybe requires a restart)?

In case I am not clear, here is what I am picturing... in the plug-ins section, there is a checkbox next to each plug-in. If I click on a supported plug-in, it simply disables it. If I click on an older version (hence not quick enable/disable supported) a dialog pops up telling me that this plug-in can't be disabled unless I restart Mala. If I choose to continue, it moves the plug-in to a disabled plug-ins folder, and on restart I see the plug-in without a check next to it.

I feel kinda if you have to quit mala then you might as well just drag and drop the plugin out of the folder.

For me, it seems if the software can handle it's own file/folder structure that is less work I need to do, and less that I need to know. Maybe akin to a program editing it's own configuration file vs. my needing to manually change a text file.

Just my opinion. Sorry if I'm not very coherent. I'm off to get my second cup now...

Thanks for the input 

Yes the checkbox is the way to go. A bit like UncleT's Jukebox options (see attached picture)

Not sure about moving the plug-in files around part for older plug-ins

Sure it's easy enough to do but then that adds a another layer of file management.

I am thinking that just keeping track of what plug-ins are enabled/disabled in the mala.ini file is the way to go. For the old plug-ins it won't be enabled /disabled until mala restarts.