linuxdcpp-team team mailing list archive

[Steven Sheehy <steven.sheehy@xxxxxxxxx>]

On Tue, 2010-06-01 at 09:08 +0000, Crise wrote:
> The functions which don't follow camel-case are not for the core to use,
> but for plugins, well one of them is called from MainWindow but that's
> an exception because the hook in question does not need any preparatory
> work so it would be a waste to make another on* function in
> pluginmanager for it (StrConv is explained below, MemAlloc further
> down).

Regardless of what your naming standards are, those are not the naming
standards of DC++.

> As for CONV_ACP_TO_UTF8 / CONV_UTF8_TO_ACP / CONV_UTF8_TO_WIDE /
> CONV_WIDE_TO_UTF, 8, they are just as compatible with unix as the
> functions they call in DC++ core I would think. They are just wrappers,
> and yes thus plugins could rewrite them for themselves but I simply fail
> to see any benefit in having plugins replicate functions we have
> perfectly good ones we can supply (especially since what is need for
> windows and unix is different, ie. by providing them in the API we ease
> portability of plugins).

They are not compatible with unix, as I stated. I wrote the text
conversion support for unix inside DC++. ACP has no concept in unix
systems, it is Windows specific (side note: ANSI Code Page is a
misnomer, it should be called Windows Code Page). In fact, you will not
see Text::*acp* functions called by the core; they are only to be called
by the Windows GUI. If you need conversion support, you need to use
Text::fromUtf8 and Text::toUtf8 or the generic Text::convert functions.

> As for the onOutgoingChat. I had it calling from core before but that
> resulted in some "issues" with plugins that try to add /commands and the
> SEND_UNKNOWN_COMMANDS option (Once again the way around this is to have
> plugin command use different leading character, but that is hardly
> practical since / has been as good as reserved for client side
> commands).

Sounds like you ran into bugs and implemented a workaround instead of
fixing the original, more logical design.

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