If you are on Linux/OSX, the plugin talks in the terminal window if you start Gimp from one. On Windows it produces a log (in the root directory of your Gimp profile).

For some reason the brush manager stopped loading and unloading brushes, so I started having a look around to see if I could find the problem. One attempt was to disable the python file and then re-enable it. That didn't fix the brush manager problem but what it did do was to make all of the other mangers appear under the help tab, pallets, gradients the lot.
What I think must have happened is that when I first set this up it was only for scripts and brushes and for reasons I don't understand the python file doesn't update itself when more managers are added to the .ini file. So the fix is to disable and then re-enable the python file whenever a new manager is added in the .ini file.
And the brush manger had stopped working because I had deleted a set of brushes from my user profile that were still loaded into Gimp and the brush manager didn't seem to like that too much. A quick fix was to delete the .active file in my brushes folder and then fire up the brush manager, problem solved.

My humble opinion is:
whenever you want to delete some entry from folders which are active under the "manager", it's better to launch first gimp, un-check what you are willing to modify (this removes those entries from gimp "normal" folders), then modify whatever you want, then re-check the folders modified to get them again active.
Otherwise your solution is also applicable: remove from .active the folder you already modified, remove the correspondent entries from the standard gimp folder and re-check the folder under the manager list

Read the README file... Gimp doesn't check all the plugins on startup, only those that are newer that the last time they were registered. When you update the .INI, this changes the necessary registration but since the python file is left unchanged Gimp doesn't give it a chance to re-register. Disabling/enabling is a solution, but you have to start Gimp twice, once to make Gimp forget it, and once to make Gimp aware of it again. To achieve this in one operation, you can either bump the last change date(*) of the python file ("touch" command on Linux, or, what is equivalent, set back the timestamps in the pluginrc file or remove the registration entries int that file altogether), or rename the file (and the .ini...).

When you disable a set, the manager get the list of files in the source folder and removes them from the active folder. In other words, enable and disable start the same, but when enable copies files, disables delete the destination files(*)

(*) when you are in "copy" mode of course, like you are in Windows or if you use ZIP files on Linux/OSX.

Err yeah, I sort off forgot to read the bit where it says "Warning" Could have saved myself a lot of time if I'd read it properly.



Thanks for the info. Normally I would remove the brushes from Gimp before deleting the file. Basically I need to improve my rather haphazard approach to working with files and then I might not get in such a mess.

- only add stuff in the off-line location,
- enable the set to put it online. If the set is already enabled, disable/enable it.

Didn't work for me
I am trying in Gimpainter (onkel hatti build)that support Py plugin, but no joy

Maybe the problem is to call from a context right click menu, tons of programs hack the right click menu and maybe that is the culprit, anyway i tried to right click everywhere to make it show up , no joy !...i never saw its gui, if installed it doesn't show up.

More detail with screenshot on HOW to call it , maybe will solve for me

I hope you may help me to solve i badly need it
-----------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------------------------
But in any case i have a enhancement request regarding its accessibility:

Access from the context menu is very ergonomic, may be a time saver BUT is far to be intuitive.
So it is a useful option to preserve but would be much better offer additionally a more intuitive alternative
...in few words i would love the script modified to create a entry also in the standard menu as in :

Image window/Edit/Manage Add-on

And/or

in the Help menu ,just below the plugin and procedure browser , like

Image window/Edit/Help/Add-on Browser & Manager

The script either produces a log file (Windows) or outputs to the terminal, so let's first try to get this to see if it even runs its registration code (speaking of which, read the warning in the README about updating the INI file and getting Gimp to acknowledge the changes).

You can change the menu location, this is also described in the README.

checking now , loading gimp with --verbose flag to see if the plugin is loaded or give errors

BTW i don't have any .ini file , neither i saw anything related to the ini file (how and where should be ...) in the README.
..the only reference about the ini file seems a line saying that is not strictly needed

It is really hard follow a topic of so many pages that is also a spin off of previous topics also of many pages,

maybe will be better summarize everything again as this was a brand new script , usable even without knowledge or practice of previous versions

This is the very purpose of the README file, that devotes 70 lines to the configuration file, starting at line 43. Here is the whole thing again:

If you use .GPL palettes add .gpl .GPL to, 'addonCollectionManager.py'.

If you use a configuration file add .gpl .GPL to, 'addonCollectionManager.ini' as well.

[EDIT]
I was not originally using an 'addonCollectionManager.ini' file so I edited, 'addonCollectionManager.py'.
The best way to go is leave 'addonCollectionManager.py' as is.
Any changes (in this case .gpl .GPL) only need to be added to an 'addonCollectionManager.ini' file to take affect.

I rewrote this script solely to avoid users putting their dirty and mildly incompetent fingers in the code(*). There is the config file for this.

If you edit the code, it becomes yours, so be prepared to answer yourself all questions you can have about it.

Asking the author to update the script to support useful defaults is however highly recommended.

(*) they usually break the script because they don't know how picky Python is with tabs.

'The great unwashed'?
Yup, I'm guilty!

Eventually got around documenting the script on the Sourceforge site...

I don't really understand the problem:

• The add-on manager works within a given Gimp profile, so if your other instance is using a different profile there should be no interaction.
• If you use the same profile with both instances and one instance activates/deactivates something, then of course the dialog won't be updated. But to determine what should be activated/deactivated when you click OK, the code computes the delta between the zips/directories you checked in the dialog and the .active it reads at that very moment, so you should always end up with what you asked for, even if the other instance has activated/deactivated things on its own. But of course if both instances are using the same Gimp profile then both instances will see the same add-ons activated (that may require a manual refresh in the second one).

If you want all you Gimp to use the same add-ones, either use the same profile for all... or in each Gimp profile, use the preferences to add a specific directory for the add-ons, and tell the add-on manager to use that directory when activating add-ons (this is the "addons_active" setting).