linuxdcpp-team team mailing list archive

[Crise <587597@xxxxxxxxxxxxxxxxxx>]

The calls to pluginmanager return if they are true, because that implies
plugin handled that event for us, ie. we don't want core doing anything
about that particular instance of it anymore.

I agree that the plugins should not be given the possibility to put the
core into an unsafe state, however, if we prevent that what can plugin
do at that point anymore?

Take a simple example... if plugin wants to do something when user
writes "/foo arg .... narg" to some chat... we can't have the core let
it send the original text user inputted anymore, especially if the
command invoked chat related action. It's really a simple catch and
block (filter) based system.

About extensibility, there is registerMessage, registerRange and
seekMessage to use... and you can also add constants to plugindefs enums
below the *_USER values, provided they don't interfere with existing
ones (also the *_USER constants do not have to be the same for all
implementations, ie. they can be moved out of the way, since plugins
shouldn't really use them directly they are just base values for the
aforementioned message register functions). The createHook, destroyHook,
setHook unHook and callHook (now in PluginApiImpl) are also usable by
the plugin host just as they are to a plugin.

So to add a hook you would do something like:
id = PluginApiImpl::registerMessage(HOOK_ID, "ldcpp.DummyHook")
hook = PluginApiImpl::createHook(id, HOOK_EVENT, ...);
PluginApiImpl::callHook(id, ....);

And for plugin to subscribe to this:
id = dcpp->seek_message("ldcpp.DummyHook");
hook = dcpp->set_hook(id,...);

(Above written on the spot, so mistakes possible, error checking
omitted)

About the plugin events being asynchronous, and listeners... it already
uses some listeners when feasible, ie. plugin doesn't need to be able
block the event. And suffice to say it is already causing me a headache
as it is when it comes to creating a plugin... since dcpp thinks it is
ok to call ClientDisconnected to clients when ClientConnected hasn't
necessarily been fired for that client... and it is not ideal for a
plugin.

To be continued...

-- 
Plugins support
https://bugs.launchpad.net/bugs/587597
You received this bug notification because you are a member of
Dcplusplus-team, which is subscribed to DC++.

Status in DC++: New

Bug description:
Ok, I'll leave out the sales pitch... here is a potential patch for adding support for plugins to DC++, compiles cleanly (ie. shouldn't generate any warnings) under mingw and visual studio of course and has been tested and working.

The code itself has been in ApexDC++ for a while so it has gotten real life use as well, of course migrating it to clean DC++ needed a few changes here and there but nothing major.

Should also compile and work on linux as it is... but this I have not had chance to test at all so that is just on paper for now.

The major difference between this patch and what's in ApexDC++ is that it does not include a full settings page for plugins which ApexDC++ has. This is simply because I don't know a squat about DWT. Instead this patch has set of chat commands added, so you can play around with the plugins, but if this gets accepted then I certainly hope someone is willing to invest into a settings page for usability sake.

Oh and few changes to the code come directly from bcdcpp, you'll spot them I am sure :).

As for the plugins currently three exists.. a pure C sample that (you guessed it) really doesn't do anything productive and then a plugin version of bcdcpp's lua (this one is pretty direct port, so it is C++).

The third one is not so impressive... it adds support for various media player chat announces (spam is too negative of a word), although primarily I created it to proof that it is possible to make a plugin that modifies the GUI, even though the API itself has little to no support for such plugin (on windows anyways),

The first two plugins can be compiled with both mingw and visual studio and are also hopefully linux friendly, the third not so much.

Oh and you can mix plugins... so mingw compiled dcpp will cope just fine with visual studio compiled plugins or vice versa (obviously this also means that the stl's used can be different). In theory you should also be able to create plugins with languages such as VB and Delphi but this very much theoretical.

Well do what you want with it... it's posted now.