[Gambas-user] Question: Is it possible to build 'plugins/add ons' for Gambas applications

[Willy Raets]

On Wed, 2012-10-03 at 13:47 +0200, Benoît Minisini wrote:
> Technically, even if it is strange, plugins are not really necessary 
> with Gambas.
> 
> As plugins usually depends on the main program version, you can put all 
> plugins in the main program. Anyway, the Gambas interpreter will load 
> the plugin code only if it is used.
> 
> The only problem is when many different people work on different plugins 
> located in the same source code.
> 
> If the version requirement is strong enough (like Gambas with its main 
> component), it is not a big deal.
> 
> Otherwise, if you really want people to develop their plugins 
> independently, you have to create components or libraries.
> 
> Libraries are actually the good way: you put them in the same directory 
> than the main executable so that it can find them, and that's all.
> 
> I think you can load them at runtime with Component.Load(), just check. 

Component.Load() does not load libraries, at least not on my machine.
It gives no error either, nothing happens, thats all.

> Otherwise you are doomed - But I will fix that, this is the goal. And 
> maybe we should be able to put plugins in their own directory somewhere, 
> but then I have to modify Component.Load() to deal with absolute paths.
> 
> Now, to create a plugin API :
> 
> 1) Having everything in the main program is the easier path. You can do 
> what you want. A shared module, using inheritance, and so on. I think 
> you should try to do that as much as possible. Note that there is less 
> security problems, as the control is done at the source code level. And 
> fixing the problem is fast when everything is at the same place.
> 
> 2) If the plugin is a library : that's the problem. It is not easy at 
> all, but it is an IDE problem : the library (plugin) project should be 
> able to use the main project as if it is a component or a library, so 
> that if the plugin interface is an exported class of the main program, 
> then the plugin can use it directly with no compilation error. I must 
> think a litle about that...

The Add Ons in my case are normal gambas applications.
For now I tested with the executables and it works just fine.
All info the Add Ons might need from the main application will be passed
through a preferences file (simple text file).

I get it running by starting the normal applications using shell.
This gives me the option to work with any path I like.

This is the routine I use to run the add on

1. On FMain this is code for menu:

Public Sub mnuShowCase_Click()

  AddOns.Run("Gambas3ShowCase.gambas")

End

2. In module AddOns this runs the Add On

Public Sub Run(AddOnName As String)
  
  Dim sPath As String
  Dim hProcess As Process
  sPath = AddOnPath & "/" & AddOnName
  hProcess = Shell sPath Wait
  hProcess.Kill
  
End

Note that AddOnPath is set to:
User.Home &  "/.AddOns"

Nice thing here is I can't close the main application before closing the
add on.
This works very smoothly.

Also tried with installed normal applications without gambas extension.
All matter of adapting name in AddOns.Run() and leave .gambas away and
change the AddOn path as installed applications are  always located
in /usr/bin/

I think I'll opt for the executable as this gives me possibility to
collect the add ons in one folder other than /usr/bin/

Willy