linuxdcpp-team team mailing list archive

[Crise <587597@xxxxxxxxxxxxxxxxxx>]

I'll first answer about the dcptr_t objects, plugins don't use them...
think of them as "handles". They could even be obfuscated instead of
being direct pointers to dcpp objects.

The object members of the structs are simply something the party which
implements callbacks use (unless otherwise stated) ie. they are link to
what is assumed to implement the functionality of what the pod type used
by the plugin represents (hence why callbacks use the object member of
the structs as a frequent argument).

Note: when I use the term callback above I refer to inbound hooks (from
dcpp perspective), you probably referred to outbound hooks, which I
simply refer to as hooks. Read the top of PluginDefs,h for some
clarification.

About extracting all useful elements from the object  being pointed to
and sending them as pod types in the structs...  isn't this done for
quite a bit of data already? (well we aren't making copies but taking
advantage that f.ex. getHubUrl() returns a reference, so c_str() is
fine), but callbacks need something to trigger actions such as sending a
chat message.

About less powerful and safer plugin api... I can understand your
reasoning for wanting this, however, if we go down that path we
shouldn't load a plugin to begin with. At least in windows simply
loading a dll can allow it to do various things even without using an
API provided. (see msdn: http://msdn.microsoft.com/en-
us/library/ms632589%28VS.85%29.aspx) For example a loaded dll can with
relative ease hijack the host processes entire window procedure. For
instance various addons built for apps that don't have public api
probably use similar techniques to this.

About UI and the patch here, the only way plugins with this could affect
the UI in any drastic manner is by using OS specific methods such as the
one presented above, the only thing that we provide about the UI (aside
from the few choice chat related events) is a notification about the UI
being created which has platform/implementation specific argument.

We also don't have any UI specific callbacks to do things such as adding
menu items etc. which is a severe limitation, because the lack of these
will lead plugin authors to research into other hackish methods to
accomplish them, because I have no doubt they would want to do things
like add a menu item for their plugins.

I have intentionally not provided API's for the UI stuff, with this
patch, though because they would need more code to be inserted into the
UI side (nor do I have any idea how to abstract UI events in OS/UI
independant fashion, if that is even possible, if only dcpp was using a
common UI for all operating systems things here would be bit different).

I had something else... but maybe it will come back to me later.

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