Version: (using KDE KDE 3.3.2)
Installed from: Debian testing/unstable Packages
This one is a classic, can be used for whatever purpose. I myself currently need it to do some automatic latin/cyrillic transliterations.
You can do this with KNotify already, to an extent.
Settings -> Configure Notifications -> More Options. Click the 'Whats This' icon and then click the input box beside 'Execute a program'. The '%s' field in Kopete contains the message data.
Note that this doesn't have RTF and other fancy things.
There were a perl plugin at a time.
But i think it has been removed because it was not maintained anymore.
This thing with KNotify either doesn't work, or I am doing something wrong :) First, %s is the notification text (eg. "Outgoing message sent"), not the message being sent, and second, the stdout of the external program has nothing to do with Kopete.
Oh I see.... I misunderstood the bug. You can use KNotify to get data *out* of Kopete, but no, it won't let you send results back into it.
You want a way to pipe a message through an external process to modify it before it gets to the chat window.
This could be done very, very easily, by outputting the XML format of the message to a program's stdin via KProcIO, and reading in the XML format of the new message from the program's stdout. Since we now have an XSD for the message (see http://kopete.kde.org/files/kopetemessage.xsd), we can verify the result and if valid, walk the DOM tree and replace the message attributes where different. If it is invalid, you do nothing (well, maybe error to the user somehow that their script is not valid. Maybe the config dialog where you specify these scripts has a test XML to run on them with a 'Validate' button).
I am going to mark this as a JJ, since I basically just described above exactly how to write it.
> This could be done very, very easily [...]
I was kind of hoping it was like that...
> I am going to mark this as a JJ, since I basically just described above
> exactly how to write it.
*** Bug 119181 has been marked as a duplicate of this bug. ***
I would like to see a plugin that for example when you tipe /command it exectes a certain script you assigned to it. This would be very nice, take for instance the example of Konversation, the IRC client, it has a very nice way to integrate external scrips. It executes the sript and posts the output, thats what I nead at least.
And I already know :
Will Stephenson 2006-11-05 23:22: " While you are just as individual and special to us as all the other Kopete users, your suggestion is not :). "
It's just a suggestion, I can't figure out anything that's been said in the previous posts.
I will attempt to implement this plugin. A quick question for Jason: I have to assemble the message into XML myself, right? (I know that's probably yes, but it can't hurt to ask).
The scripting plugin http://websvn.kde.org/trunk/extragear/network/kopete-scripting/ for Kopete on KDE4 does allow this.
Sebastian: No, it doesn't quite do the same thing. It allows one to write a script specifically for your plugin which can intercept messages. A pipe mechanism (as I'm sure you're aware) is more generic, and can allow for the use of any program (or script) in the pipe. As a Linux program, it only makes sense to support pipes, and not require special scripts, so that any executable prog/script that can understand XML can be used.
Charles; well, if you add a script that contains only following both lines;
message.setPlainBody("RECEIVED %s" % message.plainBody())
then a receiving message could be easy manipulated. If there is a desire to have it more generic, then probably something like;
from subprocess import *
p = Popen(['tr','T','B'],bufsize=1024,stdin=PIPE,stdout=PIPE,close_fds=True)
can be used to redirect it to an external prog. But reading it again, is it about manipulating the xml/xhtml/html displayed in the khtmlpart?
An unreviewed version of this plugin is now available at http://websvn.kde.org/trunk/playground/network/kopete/plugins/pipes/. I won't close the bug until it gets moved to extragear or trunk, which won't happen until we unfreeze.
This is now in trunk. Closing bug.