Plugin API

[PatrickDattilio]

Add hooks for enabling/disabling plugins from a dropdown menu.
Add a listener group to receive packets pre/post printing. (Ex: A Think chatbox that "steals" only think messages, prevents them from appearing in the game)

[marshall-davis]

My idea for this was a zMUD/tintin++ pre-processor script thing. A rule parser that allows for things to be done much like send/receive hooks.

I am a little worried about throwing this in there, as it borders on really pissing the powers that be off.

[PatrickDattilio]

If you think this might piss them off, you definitely shouldn't look at my other repository

[marshall-davis]

😆 👍

Well, that's certainly interesting.

I suppose we could publish a "legal-ish" version and a "use at own risk" version. This is definitely something I was going to add to the version I use, anyway. Certainly not going to deny its inclusion.

[PatrickDattilio]

I'm thinking of doing something like https://lkubuntu.wordpress.com/2012/10/02/writing-a-python-plugin-api/ for pluguins? I'm open to any ideas/frameworks you have

[marshall-davis]

👍

I've thought about it since. I'm for providing the means of making the client extensible via plugins or scripts or what have you. I won't publicly provide said plugins though, especially not those that may go against the game rules.

Long story short, plugin functionality good, actual plugins probably bad.

[marshall-davis]

As for implementation that seems simple enough. Issues would be very little safety from the plugin doing something unintentional, so if it comes up we'll have to catch plugin errors and handle them gracefully rather than seemingly like the client crashing because of a third part.

[PatrickDattilio]

Agreed. I was planning on developing actual plugins in a separate repository.

I'd really like to see some sort of collapsible debug/plugin window, maybe expanding off the side of the client window?

[marshall-davis]

I think there's a few ways to handle that. It could operate like the preferences dialog and any plugin that needs a UI would draw its own. The base client could make the original frame available to these plugins so size and child elements can be arranged to make room. This may be needed to do the individual additional windows as well. Also, this was my original intention, to have the input, output, status and other client UI elements be their own "widget" to move around the screen in a windowless fashion. The plugins or course could also use the input buffer I did for log in credentials to create a textual interface as well. Not sure how many visual elements you want in a plugin.