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

[Sébastien Granjoux <seb sfo free fr>]

Hi,


I have just committed some changes to allow running anjuta with a 
different set of plugins. As almost every features are provided by 
plugins, you can get a quite different program just by changing the 
initial plugin set.

The initial goal was to be able to use Anjuta as an IDE customized for 
GNOME application. To check my changes, I have added a profile allowing 
to use Anjuta as a simple text editor.

In order to implement this, I have done several changes in libanjuta and 
I haven't kept the backward compatibility. I have changed quite core 
functions, so I hope most programs using libanjuta are still working. 
But this needs to be checked. If it is an issue, we will probably have 
to manage libanjuta version number separately from Anjuta.



In more details, there is now the following features.

* You can select a system profile on the command line using the switch 
-P followed by the profile name. Anjuta will search for a file in 
$(prefix)/share/anjuta/profiles with this name and the extension 
.profile. All plugins listed here will be loaded and never unloaded.


* In the profile file, you can use the keyword filter to select only a 
subset of the available plugins. Those plugins will not be activated but 
will be the only ones those could be activated later.

By example:
  <plugin name="File Loader">
    <require group="Anjuta Plugin" attribute="Interfaces" 
value="IAnjutaFileLoader"/>
  </plugin>
  <plugin name="Document Manager">
    <require group="Anjuta Plugin" attribute="Interfaces" 
value="IAnjutaDocumentManager"/>
  </plugin>
  <filter>
    <require group="Anjuta Profile" attribute="Editor" value="yes"/>
  </filter>

The profile above means, load the file loader and document manager 
plugin and keep only the plugins having the value "yes" for the key 
"Editor" in the group "Anjuta Profile". All other plugins cannot be 
activated and are hidden to the user.


* In the profile file, you can use the keyword set to add a new key in a 
plugin description. This description can be read in the plugin code, 
allowing to customize it based on the profile. This keyword can be used 
inside a plugin or a filter block and will be applied on all matching 
plugins.

By example
  <plugin name="Document Manager">
    <require group="Anjuta Plugin" attribute="Interfaces" 
value="IAnjutaDocumentManager"/>
    <set group="Configuration" attribute="Standalone" value="yes"/>
  </plugin>

The profile above will set the key "Standalone" in the group 
"Configuration" of the document manager plugin to "yes". I have checked 
this key to automatically open a new document on startup. This is not 
done in Anjuta which has the starter plugin.



This is only an initial implementation. If we want to make it really 
useful, we have to add more flexibility to our current plugins. I means 
they should be able to run even if some parts are missing, by example 
the project manager or the symbol-db plugin. In some cases, we could 
have to add some configuration defined by the profile file.

Another issue is that currently all profiles share almost all settings 
perhaps it could be useful to have independent settings depending on the 
profile.



Then, I'm now planning to spend some time on GDL, trying to make it 
works a bit better.


Regards,

Sébastien