Re: [anjuta-devel] Adding some filtering mechanism for plugin

[Johannes Schmid <jhs jsschmid de>]

Hi Sébastien!
  
(I am skipping the technical part of the profile manager here because I
basically agree with your implementation ideas.) 

> I'm not sure we really need to hide some plugins. I think it's useful 
> but perhaps not mandatory and it can be an issue. By example what's 
> happen if you open an anjuta project needing an hidden plugin, should we

> display an error message?
>
> Moreover, we need to tune some already existing plugin. I have thought 
> about adding a plugin just for this. But perhaps it would be better to 
> extend the profile file format to be able to define value for some 
> plugins properties in this file. In this case, the GNOME IDE could be 
> just a special profile file, which is loading by default some particular

> plugins and is setting some attributes of other ones.

Perhaps we should completely rethink the plugin idea a bit in Anjuta
because currently we have two completely different things we call plugins
because they technically use the same mechanism:

* Components (or core plugins)
All the stuff that the user cannot really activate on it's own or that is
normally loaded by the profile manager. It could be useful to hide the
plugin character of those completely and also don't list them in the
preferences (in the GNOME IDE case).

* Additional plugins
This is what you would traditionally call plugins or addons in other
environments like firefox for example. Those should always be activatable,
even in the GNOME IDE case.

I agree that we shouldn't ever display an error message when the user
opens a project file. Even the GNOME IDE should basically behave like a
normal anjuta instance in that case. We should only be careful that it
returns to a sane state when the project is closes and that some plugins
(especially the project-wizard) don't suddenly change their appearance just
because you opened another (full anjuta) project. So somewhere in the
background every plugin should be able to identify that it should stay in
the "GNOME" state.

Other than that I would really limited the default set of plugins loaded
in the GNOME IDE version. In the non-C-version we could even deactivate the
debugger as it's not useful and probably we could disable the file-manager
if the project-manager is able to handle everything that's needed for
managing the project.

Regards,
Johannes