[Gambas-user] How to create a plugin system for your Gambas project

[olivier coquet]

Hello Benoit and the others,

First of all thank you for your interest in the plugin system, I 
wouldn't have imagined that it could interest anyone else than me :)

For the points you mention:

0) It seems to me that a guide-line would be appropriate for plugins to 
be easily recognized.

1) I don't agree with absolutepath, I prefer by far my system that loads 
plugins in the components directory. This way their installation is 
simple (installation package) and this directory is kept up to date in 
the gambas system without uncertain manipulation.

3) The I disagree with you, what you describe is a component, by nature 
a plugin acts on the main program but it is unknown to it. Said in 
another way, the main program cannot/must not access the functions and 
procedures of the plugin except for the initialization procedure which 
must be identical in all plugins.
PS: For someone who hasn't read the current thread, did the name main() 
suddenly appear to you? :)

4) same as for #4, no need to have the list of exported classes, the 
main program doesn't need to know them.

To sum up, this is what I expect from a plugin and what I realized in 
the recently posted example:

A plugin must not disrupt the operation of a stable main program.
A plugin must be able to "hijack" some of the functions of the main program.
A plugin should be able to change the appearance of the windows of the 
main program in order to improve them or to add functions to them.
Last but not least: The main program must be able to work correctly if 
the plugin is absent and this without specific detection code (which 
argues in favour of my remark on point n° 3).

In my mind, a plugin is an additional, different or improved function 
added to the main program after the main program has been designed. 
These additional functions and improvements could not be foreseen at the 
time of the creation of the main program.

If you want a concrete example, I advise you to take a look at the 
example I posted here which illustrates 100% what I'm talking about.

friendship
Olivier C.

Translated with www.DeepL.com/Translator (free version)

Le 17/02/2021 à 18:27, Benoît Minisini a écrit :
> Hi,
>
> I saw the thread about plugin management system, but didn't actually
> read it in detail.
>
> So I decided to start a new thread about that, and concerned people will
> tell me if it helps them, if they already did that way, and so on...
>
> Regards,
>
> ------------------------------------------------------------------------
>
> (0) HOW TO CREATE A PLUGIN SYSTEM IN GAMBAS ?
>
> First, there is (almost) no technical difference between a project
> executable and an executable library.
>
> So let's suppose our main project is named "MainProject", and that we
> want to develop a plugin for that main project, from another project
> named "MyPlugin".
>
> ------------------------------------------------------------------------
>
> (1) LOADING THE PLUGIN FROM THE MAIN PROJECT
>
> You must know the absolute path of the executable of the plugin, and you
> load it by doing:
>
>   Component.Load(PluginAbsolutePath)
>
> So your plugin becames a component for the project. The name of that
> component is the name of the plugin executable file without the
> extension. So, in our case, "MyPlugin".
>
> *Note: you cannot unload a component, this is not supported by Gambas 
> at the moment.*
>
> ------------------------------------------------------------------------
>
> (2) TO KNOW IF THE PLUGIN IS ALREADY LOADED
>
> Just do that:
>
>   If Component.IsLoaded("MyPlugin") Then ...
>
> ------------------------------------------------------------------------
>
> (3) COMMUNICATION BETWEEN THE MAIN PROJECT AND THE PLUGIN AT RUNTIME
>
> This must be done by using exported classes.
>
> The plugin can call any class exported by the main project.
>
> The main project can call any class exported by the plugin project.
>
> Why? Because there is one symbol table per project, that is private
> except for exported classes, and one global symbol table for all
> exported classes of all projects.
>
> This is the way for components (native components, components written in
> Gambas, libraries, any executable) to share things (i.e. classes).
>
> *NOTE: Any piece of code can call any public method of any class as soon
> as it as a reference on an object of that class, so exported class is
> not the only way of share things between projects. But using exported
> classes make things explicit and clear.*
>
> That means that you must be careful with the name of your exported
> classes (no namespace, only one global symbol table!).
>
> Usually, you will define a common public interface for all your plugins.
>
> One exported class may be enough for that. As said before, the name of
> that exported class must be unique, so you should put inside the name of
> the plugin.
>
> For example, you can decide that all plugins must export a class named
> "MainProjectPlugin_<NameOfThePlugin>" or something better than that.
> Then you will have a public function in that class ("Main"?) that will
> be called by the main project to initialize the plugin.
>
> ------------------------------------------------------------------------
>
> (4) HOW TO GET THE EXPORTED CLASSES OF THE MAIN PROJECT DURING PLUGIN
> DEVELOPMENT
>
> To let the IDE know which exported classes your project can use, you
> must go the "Libraries" tab of the plugin project property dialog.
>
> Then you can add to the "Additional references" list the path of your
> main project executable.
>
> Each exported classes of each executable in that list will be available
> to your project (with automatic completion) without raising "unknown
> identifier" errors.
>