[Gambas-user] Question: Is it possible to build 'plugins/add ons' for Gambas applications
Fabien Bodard
gambas.fr at ...626...
Wed Oct 3 14:23:19 CEST 2012
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 ?
>
> --
> 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
More information about the User
mailing list