linuxdcpp-team team mailing list archive

[Crise <587597@xxxxxxxxxxxxxxxxxx>]

Ok, few comments in response to the points brought up in dcdev chat:

1. Regarding the types of id'ing used... and the differentiation between different groups. The meaning between generic vs dcpp is very much obvious as stated; other than that the ids can be described as: 
[generic|dcpp].[something relevant].[interface struct|event name].

Basically the middle bit is there just to add another level of
uniqueness to the names (as i felt using windows type guid as a bad
idea, if for nothing else for the sake of debugging plugin calls).
Plugins should generally use a full random guid (such as a low collision
hash) to identify themselves though: so the above could also be
interpreted as, [guid].[something relevant].[interface struct|event
name]. DC++ doesn't have a guid though being the host hence the use of
dcpp). The "something relevant" bit can also be used to link events and
interfaces together somewhat. Generally speaking the guids used by the
system can be anything so long as the definition of "globally unique" is
met at least in the small universe that is DC & Plugins (I chose human
readable naming for my own convenience as noted, but the logic doesn't
require it, granted I see possibilities for plugins to take advantage of
it).

2. Versioning: I ended up going with each interface having an
independent version (mostly) which is represented by single int, all
interfaces under this versioning are considered backwards compatible
indefinitely (however, the version of DCCore can naturally be used to
eliminate very old plugins from being loaded, if necessary).

3. UI hook(ing): this is somewhat of a hairy subject because properly
abstracting controlled ui hooks without essentially either forcing
people to re-implement a processing structure of certain ui lib or os is
just near impossible (or then we would have to go with "make it equally
difficult for everyone" and come up with independent schematics for
those hooks). If you ask me the most clean way we can implement ui
hooking is to piggyback on the user commands system the protocol
defines. Of course this has pretty severe limitations, but it can be
done... ie. plugin feeds the core a self generated user command then
when it comes in (or out, technically) through the protocol interface
block and act on it.

Outside abusing the user commands I don't see it as practical to
implement many ui hooks... notepad++ does ui and plugins in a fairly
decent manner (ie. give them a "Plugins" top level menu, then under it
an item for each plugin, that requests it, that it can then customize).
This is something that can be looked into but for now it is more
important to get the first "final" version in. If we go more in depth
with the ui hooks we will only invite a nightmare on the ui code (if the
ui supported say, skins through xml or some other independent form of
defining ui elements then ui could be hooked into simply by letting
plugins modify these "blueprints" the ui is based on but alas that is
not the case).

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

Title:
  Plugins support

Status in DC++:
  In Progress

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dcplusplus/+bug/587597/+subscriptions