I think it could be done using a "show-invisible" property in the plugin tree view.

Johannes, could you be more explicit about how you want to make use of invisible plugins? Because I'm thinking "show-invisible" and "invisible" are sucky names... (how can you show something invisible?) At the end they are just regular plugins that you can't control.

Totem's use of invisible plugins is for "builtin" parts of the UI, ie those plugins are automatically loaded on startup and can't be disabled.

If anjuta plans to use them the same way, we could just do this:
- rename the invisible property to "builtin" and have a "show-builtin" prop in
  the manager.
- automatically load the "builtin" plugins when the engine is started (that could
  go along with the planned gsettings support for plugins)

Alternatively we could have both a "invisible" and a "autoload" property in the .plugin file, and totem's "builtin" would be an alias for invisible=yes;autoload=yes (anjuta could then just not set invisible=yes and the manager would be left unchanged)

Anjuta currently uses a "UserActivatable" property. When it is set to no the plugin may be loaded automatically on demand (not necessarily on startup) and the user cannot activate it himself. It is shown in inactive (grey) color in the plugin manager when the "Show non-user activatable plugins" checkbox is checked, otherwise they aren't shown at all.

So, this is a bit similar to builtin but it is possible that external components (for example a language-support plugin or an alternative editor) is non-user activatable while builtin would really fit their in my opinion.

I personally like the naming "user-activatable" as it describes relatively exactly what happens without making assumptions on the technical details or how things are presented to the user.

An "autoload" property is something that sounds useful in general but different from the idea discussed here. But this could probably replace parts of the current default session management in anjuta. Anyway, that's another story.

While I am on it: Anjuta also has a way for the user to choose (and remember) which plugin he wants to use when more than one plugin implements the same interface. Don't know if this is useful in other applications, too. It can be implemented on top of libpeas so it's nothing that is critical in any way.

> So, this is a bit similar to builtin but it is possible that external
> components (for example a language-support plugin or an alternative editor) is
> non-user activatable while builtin would really fit their in my opinion.

Should be
"while "builtin" wouldn't really fit there in my opinion"

Created attachment 165850 [details] [review]
Replaced invisible plugins with builtin plugins

Ok so basically in Garrett's patch here, the idea is the following one:

"Visible" plugins are replaced by "builtin" ones. The "builtin" value is read from the plugin info file.

A builtin plugin has the same behaviour as previous invisible plugins: they cannot be enabled or disabled by the user, and they are hidden in the plugin manager. The application can still do what it wants with builtin plugins, as libpeas doesn't handle autoloading them.

It means that totem can drop the "set visibility" code and just load the plugin straight away when a "builtin" plugin is found. It also means that anjuta can handle loading and unloading them as required.

Patch in bug 624309 introduces a "show-builtins" property in the plugin manager, effectively implementing what this bug suggests.

What do you think?

Yeah, that's basically what I suggested as it doesn't force the developer into any model of plugin usage. Thanks! +1 from me (also for bug 624309).

Attachment 165850 [details] pushed as 7d4e464 - Replaced invisible plugins with builtin plugins