| Summary: | Support for event-driven scripting | ||
|---|---|---|---|
| Product: | [Applications] konversation | Reporter: | Boris Kavod <kavod> |
| Component: | general | Assignee: | Konversation Developers <konversation-devel> |
| Status: | CONFIRMED --- | ||
| Severity: | wishlist | CC: | ao, bugs.kde.org, hein, heri+kde, larvid, sgeoster, tj.trevelyan, TubaSoldier, zxiiro |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Bug Depends on: | 192524 | ||
| Bug Blocks: | |||
|
Description
Boris Kavod
2005-10-11 20:56:07 UTC
Just as a side note, for next time: please make one wish per Bugzilla entry. ok, sorry, it was my first bugzila submition. > - You declare your page "XHTML W3C Valid" but it is not. It's bad ;) Fixed Others will have to wait until we fix bug #114119 *** Bug 112141 has been marked as a duplicate of this bug. *** *** Bug 135299 has been marked as a duplicate of this bug. *** Any news on that topic meanwhile? That would be very useful. ;) *** Bug 123815 has been marked as a duplicate of this bug. *** *** Bug 200349 has been marked as a duplicate of this bug. *** I am eagerly awaiting this functionality as well. I would like to also wish for this feature. I have writen a perl script for xchat that takes incoming text and translates it (Using the google translate json api). It then prints the translated text under every line of none translated text. I would love to implement the same for konversation. There seem to be two different classes of bug that have been merged into this as duplicates:
a) internal scripting: allow a lot of things to be done and provide event-driven scripting with things such as onJoin, onPart, onOp, (onStatusChange, onModeChange etc) as well as the same sort of scripting that can be currently done through dcop (e.g. /weather; /exec getnickback; /uptime from the examples)
b) improved external scripting API: via (dcop)/dbus that is not event driven but still allows a lot to be done. There are currently very few calls that return information -- they are mostly about remote control of the irc session (setAway, say("now playing") etc). Providing a few more functions that return data would solve a lot of this. A few that I've recently wished I had are:
isOp(server, channel, nick) // return true/fase
userModes(server, nick) // return +eRo
userModes(server, channel, nick) // return +b (maybe?)
channelModes(server, channel) // return +tncPLlfJ 945
userHostmask(server, nick) // return n=username@unaffiliated/cloak or user@127.0.0.1 etc
channelLogFile(server, channel) // return /path/to/logfile
isChannelLogged(server, channel)
listChannels(server)
(not all of these are necessary; there's some level of overlap between them)
(a) is hard; (b) looks much easier and will achieve many of the same goals for a lot of scripting problems.
Food for thought...
I would also like to see event-based scripting in Konversation, and I have an idea on how one could implement this. Each time that an event occurs (for example a PRIVMSG is recieved), Konversation will execute a corresponding bash/sh script (for example ~/.kde4/share/apps/konversation/events/privmsg). The parameters sent to this script would in the case of PRIVMSGs be: server, target channel/user, the user who sent the message, and the message itself. The script can return either true or false (0 or 1). If false is returned, it will block the default action (which in the case of PRIVMSGs would be to print the message, eventually highlight the message and/or notify the user, etc). To make this a bit more useful, there should be a few more D-Bus methods, such as a method to print out a string on the screen as just another message, but without sending anything to the server like say does. We currently plan to use Kross for scripting, however there's still a fair amount of rearchitecturing work to be done beforehand. |