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

Sebastian Kulesz sebikul at ...626...
Wed Oct 3 17:38:44 CEST 2012


On Wed, Oct 3, 2012 at 9:23 AM, Fabien Bodard <gambas.fr at ...626...> wrote:
> 2012/10/3 Benoît Minisini <gambas at ...1...>:
>> 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.
> Yes i think it is needed
>>
>> 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...
> DBUS ?

DBus IS the way to go. A plugin could be any class that depends on
DBusObject. When a plugin is loaded (simply executed, even from a
shell), a Main function is executed which registers the object and
enters in to an infinite loop.  It can expose an Exit() method to
quit, etc. It requires no additional work! what do you think?

>>
>> --
>> Benoît Minisini
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> Gambas-user mailing list
>> Gambas-user at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gambas-user
>
>
>
> --
> Fabien Bodard
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user




More information about the User mailing list