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

Benoît Minisini gambas at ...1...
Wed Oct 3 13:47:17 CEST 2012


Le 03/10/2012 12:22, Ron a écrit :
> On 3-10-2012 2:58, Willy Raets wrote:
>> On Wed, 2012-10-03 at 08:26 +0930, Bruce wrote:
>>> On Tue, 2012-10-02 at 23:03 +0200, Willy Raets wrote:
>>>> Hi.
>>>>
>>>> I recently had a request of someone if it is possible to build a
>>>> plugin/add on for my existing Gambas application.
>>>>
>>>> I like the idea, as it would give extra function to my application.
>>>>
>>>> So would it be possible to write applications that, once installed, add
>>>> something to my application, like the add ons for Firefox for example.
>>>>
>>>> Would this be possible with Gambas?
>>>> If so, how to set up the main application to except these plugins/add
>>>> ons?
>>>>
>>>> I anyone could point me into the good direction it would be much
>>>> appreciated.
>>>>
>>>> Willy
>>>>
>>>> P.S. Would it be possible to have plugins/add ons written in for example
>>>> Java added to a Gambas application? Or am I going to far in my mind :)
>>>>
>>> Hi Willy,
>>>
>>> The concept is feasible, but requires some effort on your part to
>>> implement the following:
>>> 1) a plug in manager for your app to let the user register and start the
>>> plug in.
>> That is what I kind of figured out :)
>>
>>> 2) an object model for your app data that safely exposes the data in
>>> some way:
>>>     a) dbus?
>>>     b) directly passing the data to the plug-in?
>>>     c) using interface files?
>>> 3) if you want to allow the plug in to modify the data, then some sort
>>> of interface to recognize modification requests and apply them
>>> (judiciously of course).  Again, gb.dbus messaging and gb.signal look
>>> the most sophisticated approach.
>> Seems I'll have to dive into gb.dbus
>>
>>> Some weeks ago I proposed adding such functionality to the IDE itself.
>>> In that post there is a mocked up proof of concept for step 1.  I didn't
>>> take it any further as there was little interest expressed.  We have
>>> added it to our local gambas installation and taken it further.
>>> However, no data that is within the IDE is exposed to the add-ins (as I
>>> didn't want or need to do that).  Our IDE add-ins work outside the IDE
>>> to provide some developer aids and at the most add new files to the
>>> project.  Some examples are: a "class-builder" that reads a UML xmi file
>>> and creates a new class with the majority of the property handling code
>>> already implemented; a "installer" that installs an automake package of
>>> the project with little user intervention; a "todo list " manager that
>>> goes far beyond the IDE tasks panel to manage to-dos, bugs, ideas, etc;
>>> and a stockview type of icon/image manager that previews any/all of our
>>> icon libraries and allows importing of icons into the project directory.
>>> So, nothing that actually modifies the active code within the IDE, the
>>> only data that is passed to the add-ins is the project path. Other than
>>> adding files to the project the only other back interface is via the
>>> clipboard. For example, the stock viewer copies the path of the clicked
>>> icon onto the clipboard in the format needed for a Picture["path"]
>>> command.
>>>
>>> If you want to look at the POC search the mail archives for "Proposal" -
>>> it was some time in August.  I don't think we have an archive of it, but
>>> if you can't find the post then pm me and I'll have a look though system
>>> backups for it.
>> Ok I found your post about it and downloaded the archives. Archives
>> won't open somehow :(
>>
>> Reason it gives:
>> tar: This does not look like a tar archive
>> tar: Skipping to next header
>> tar: Exiting with failure status due to previous errors
>>
>> So I hope you still have them lying around somewhere.
>> Their names where (might help retrieving them):
>> addinmeta1-0.0.6.tar.gz
>> paddys-hill-runterm_simple-0.0.2.tar.gz
>>
>> Very curious about this...
>>> I'd say that dbus would be the way to go for part 2 as it is a
>>> convenient way to encapsulate and expose your object data model.
>> If I get part 1 done (guess your example will come in helpfull to get me
>> going) I'll have a good look at dbus and it's possibilities.
>>
>>> regards
>>> Bruce
>>>
>> Thanks again..
>> You are always very helpful and seem to be thinking and doing a lot I'm
>> thinking and trying to do :)
>>
>> Willy
>>
>> BTW, I like your idea of being able to add plugins to the IDE as you
>> suggested. I can think of some useful additions off my own that would
>> speed up some routine tasks often needed during development.
>>
>>
>>
> Willy,
>
> Search for the file names online, download the files from the found list
> archive and open them with 7zip (windows, yuk) right click choose "open
> archive".
> Then click on the files until you see the list of contents, you can then
> drag them to a folder.
> Simply unpacking directly indeed results in one strange text file with
> all files concatenated in it.
>
> I'm also looking at some way of creating plugins/define an api for my
> project! (domotiga)
> So people can code a plugin as a gambas component, place it in a
> directory (plugins) and the main software will scan/find and register it.
>
> I looked at this info also...
> http://www.gambasforge.org/code-55-application-modulaire--des-plugins-pour-votre-appli.html
> but haven't got it to work just yet the way I want it.
> So keep me posted if you want, when you succeed in creating a POC ;)
>
> Regards,
> Ron.
>

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. 
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...

-- 
Benoît Minisini




More information about the User mailing list