It would realy kick ass if Quassel would be in some way to be scriptable.
#3 Updated by Sputnick over 11 years ago
The problem is not to support any given language, but to decide how to / which interfaces to export and how to (maybe) allow core-side plugins without users being able to risk other's stability. Just client-side plugins would probably be much easier (and we might do that first), but still require a sane strategy to be able to hook into Quassel.
Once we have designed a plugin/scripting interface (aka, one or more QObjects exposing methods, signals and slots), adding arbitrary language wrappers on top of that is not going to be a huge problem at all.
Currently on the list are python, perl, dbus, possibly QtScript.
#5 Updated by stdin almost 11 years ago
With KDE integration Kross support could be added, that way all the languages Kross supports can be used. The only issue would be the case where the user decided to use the pure Qt client Kross will not be available.
There's also the option of exporting interfaces over the DBus protocol, but I don't know how portable (cross-platform) that is currently.
#7 Updated by LameBMX over 9 years ago
Just adding another vote for scripting support in both core and client. i would rank core over client though to get more IRC chan/network ops to give it a try. Modular plugin would be preferred and /etc/conf.d/quasselcore.
- Uncomment scripting modules to load into core
- Define scripts to load
- use cat script to load scripts to enable single scripts, or user can make script dir and it will load all scripts in dir ***
while client side scripts are nice, the real NEED for scripting would be core side. so an oper would not need to keep client connected to core to perform duties. and before people call this bloat or turning it into a bot, are newbs that have never oper'd a channel or network. with time, i think quassel will get its strongest and most stable userbase with operators.
#8 Updated by slime almost 7 years ago
Is there any further comments on this?
A scripting language implementation would be awesome. I see that there was mention of it on the main page: "This is more or less a complete rewrite of how the IRC protocol is handled, and the first major step towards full scripting support!" However, a year later, and there still doesn't appear to be anything in version .9 about scripting.
:~$ quasselcore --version
Quassel IRC: v0.9-pre (unknown rev)
:~$ quasselclient --version
KDE Development Platform: 4.9.5
Quassel IRC: v0.9-pre (unknown rev)
#10 Updated by SynrG almost 6 years ago
There is a lot in this report discussing various potential implementations but nothing about justification for the feature or relative importance to the Quassel users or developers. So here's my 2c:
For some segment of the user population (I can't really say how large, or how important we think it is to cater to), this is a serious usability issue, not just a "support my silly scripts" wishlist (see /slap script quip in http://www.quassel-irc.org/faq/2#t2n44). Being a member of a team of chanops on a large (1500+ users) channel, the administrative burden on us is such that we need scripts to effectively manage the channel. That's just one way that scripts make irc users more productive. I'm sure there are others.
So discussing solutions before asking "is this something the Quassel devs think is important to do?" is putting the cart before the horse. For me, Quassel looks like it could be the best way to keep a 24/7 presence via a variety of devices, some of them with touch interfaces, but to do that for sophisticated users, it needs to be extensible. As such a user, for example, if I need to intervene as an op, I have to leave the comfort of my touch interface and connect back to a system with irssi running on it in order to do so. This diminishes my effectiveness in this role, and would be a source of aggravation for other Quassel users for whom supporting scripts is a matter of staying productive, while enjoying the comforts of Quassel.
As for implementations, please make sure, whatever you choose, not to forget Quasseldroid users.
#11 Updated by SynrG almost 6 years ago
By the way, I didn't mean, of course, to make this bug about modifications to Quasseldroid. For that, I have filed a separate bug https://github.com/sandsmark/QuasselDroid/issues/179 mutually cross-referenced with this one. But as I said there, if a remote quassel-core could execute plugins on behalf of the quassel clients, then we wouldn't have to worry about plugin implementations per client.