Bug 114237 - Support for event-driven scripting
Summary: Support for event-driven scripting
Status: CONFIRMED
Alias: None
Product: konversation
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konversation Developers
URL:
Keywords:
: 112141 123815 135299 200349 (view as bug list)
Depends on: 192524
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-11 20:56 UTC by Boris Kavod
Modified: 2013-04-14 23:24 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Boris Kavod 2005-10-11 20:56:07 UTC
Version:           0.18 (using KDE KDE 3.4.1)
Installed from:    Gentoo Packages
Compiler:          gcc 3.3.6 Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8
OS:                Linux

(sorry for my bad English, I'm French)

I would like to file several wishes for the futur konversation versions.

- On my last IRC clients (mIRC then Xchat), I could make scripts which is executed on events (like on sending messages). I used it to develop a script which allowed me to write in red. The scripts based on dcop are very great, but I miss this fonctionality.

- It can be great defining nickserv password for each nickname we used. For example, I have a first nickname which is "Boris_Kavod" and another "Boris[away]". When I become away, Konversation rename me "Boris[away]" which is protected by a nickname password. It can be interesting to autolog with a registered password like on connection.

- You declare your page "XHTML W3C Valid" but it is not. It's bad ;)

Congratulation for the rest, I have switch from Xchat with pleasure !
Comment 1 Thiago Macieira 2005-10-12 07:07:19 UTC
Just as a side note, for next time: please make one wish per Bugzilla entry.
Comment 2 Boris Kavod 2005-10-12 07:32:43 UTC
ok, sorry, it was my first bugzila submition.
Comment 3 Ismail Donmez 2005-10-12 14:29:17 UTC
> - 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
Comment 4 Eike Hein 2006-10-08 20:52:53 UTC
*** Bug 112141 has been marked as a duplicate of this bug. ***
Comment 5 Eike Hein 2006-10-08 20:53:02 UTC
*** Bug 135299 has been marked as a duplicate of this bug. ***
Comment 6 Johannes Studt 2008-03-30 14:13:31 UTC
Any news on that topic meanwhile? That would be very useful. ;)
Comment 7 Eike Hein 2008-05-01 13:25:00 UTC
*** Bug 123815 has been marked as a duplicate of this bug. ***
Comment 8 Eike Hein 2009-07-17 19:14:26 UTC
*** Bug 200349 has been marked as a duplicate of this bug. ***
Comment 9 zxiiro 2009-07-17 19:43:02 UTC
I am eagerly awaiting this functionality as well.
Comment 10 Thorben 2009-08-06 12:22:35 UTC
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.
Comment 11 Stuart Prescott 2009-09-09 19:31:55 UTC
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...
Comment 12 larvid 2009-10-30 00:38:26 UTC
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.
Comment 13 Eike Hein 2009-10-30 14:40:27 UTC
We currently plan to use Kross for scripting, however there's still a fair amount of rearchitecturing work to be done beforehand.