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

[seb sfo free fr]

Hi,

> > * In the profile file, you can add a filter element to keep only plugins 
> > matching some attributes. If you don't have any filter element in your 
> > profile file, by default all plugins are enabled. It looks like the 
> > following:
> > <?xml version="1.0"?>
> > <anjuta>
> >      <plugin name="File Loader" url="http://anjuta.org/plugins/";>
> >          <require group="Anjuta Plugin" attribute="Interfaces" 
> > value="IAnjutaFileLoader"/>
> >      </plugin>
> >      <plugin name="Document Manager" url="http://anjuta.org/plugins/";>
> >          <require group="Anjuta Plugin" attribute="Interfaces" 
> > value="IAnjutaDocumentManager"/>
> >      </plugin>
> >      <filter>
> >          <require group="Anjuta Profile" attribute="Editor" value="yes"/>
> >      </filter>
> > </anjuta>
> > With such profile, only the plugins containing Editor=yes in the group 
> > Anjuta Profile in their description will be used. And at least both the 
> > file loader and the document manager need it.

> Sorry, I don't fully get this. Which plugins are loaded with this
> profile?

With such profile, you load the file loader and the document manager
plugin but they have to define the attribute Editor=yes in the
Anjuta Profile section else they are not loaded which can be an error
if you set them as mandatory too.

I think it's the best solution because each plugin element could
corresponds to several plugins and in this case, it is useful to
load only the plugin having the right attribute.

The filter is valid afterward, so if you load a project only the
project plugin having the Editor=yes attribute will be loaded.
In the same way, when Anjuta looks for a plugin (to open a new
file by example), it will get only the plugins with the attribute
Editor=yes. Obviously only these plugins are displayed in
the preference dialog.



> > * All this requires some changes in libanjuta and it will probably break 
> > the backward compatibility.

> Version numbering is more about API and ABI stability - we provide none
> of the currently for libanjuta. But we could if we want...

Currently, we haven't done much change in the API so it's stable. I think
the only user we have is gtkpod but perhaps there are others. At least
I think it would be useful to add a version number allowing users to
use an older version.


> I might be useful to restrict the set of plugins that can be loaded to
> some group using the filter element. Explicitly removing loaded plugins
> doesn't sound very useful to me.

Ok


> > Do you think, I need to keep the backward compatibility in libanjuta?

> No :)

I have already asked gtkpod developpers, they don't see this as an big
issue neither. So fine, it will be easier for me.


Regards,

Sébastien